From owner-freebsd-hackers Sun Jan 21 1:42: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by hub.freebsd.org (Postfix) with ESMTP id A94E437B400; Sun, 21 Jan 2001 01:41:46 -0800 (PST) Received: from fwd02.sul.t-online.com by mailout06.sul.t-online.com with smtp id 14KH0I-0005K5-01; Sun, 21 Jan 2001 10:41:42 +0100 Received: from frolic.no-support.loc (520094253176-0001@[217.80.111.50]) by fmrl02.sul.t-online.com with esmtp id 14KH08-05zm7cC; Sun, 21 Jan 2001 10:41:32 +0100 Received: (from bjoern@localhost) by frolic.no-support.loc (8.11.1/8.9.3) id f0L9XPG01498; Sun, 21 Jan 2001 10:33:25 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Sun, 21 Jan 2001 10:33:24 +0100 To: Roelof Osinga Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MAIL set by whom? Message-ID: <20010121103324.A297@frolic.no-support.loc> References: <3A6A50F3.307C9E06@nisser.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6A50F3.307C9E06@nisser.com>; from roelof@nisser.com on Sun, Jan 21, 2001 at 04:01:07AM +0100 X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > But what I need is /home/{$USER}/Maildir/ in order for Mutt to > work with Maildirs. The above /etc/login.conf parts don't do the > trick and other occurrences of MAIL I can't find. > > So what gives? (IOW please help! :) You can set MAIL via /etc/login.conf, all applications that use either login(1) or setusercontext(3) should work. Beware of ssh! The OpenSSH client, that is part of FreeBSD is completey buggy here: It sets MAIL to /var/mail/$USER, this is hardcoded. I have a dirty fix, maybe I'll clean it up and send it as a PR or to Kris (Kris, are you still ssh maintainer?) This whole stuff of initial user environment and friends has to be cleaned up to be consistent for all login methods: login(1), xdm, rsh, rlogin, ssh, telnet. I would volunteer(sic!) for a in detail analysis of this issue if I get feedback on this. (i.e. looking for inconsistencies, where to put on solutions (e.g. a pam module that evals /etc/login.conf via setusercontext(3)). To fiddle with user's .bash{rc,_profile}, .tcshrc, .whateverrc is the wrong way. Some rc files are not evaluated for non login shells, so you put it into .bashrc or whatever get executed for non login shells; if you do this you parameters will be overwritten each time you start a new shell (e.g. xterm). The user should have a minimal reasonable environment (even without shell rc files, if you want to go that far), that he/she may optionally extend or adapt. /etc/login.conf, maybe in combination with pam, is the right thing for doing this. Bjoern -- -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 2:14:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 866F137B400 for ; Sun, 21 Jan 2001 02:14:11 -0800 (PST) Received: from nsouch by smtp.alcove.fr with local (Exim 3.12 #1 (Debian)) id 14KHVa-0002ef-00; Sun, 21 Jan 2001 11:14:02 +0100 Date: Sun, 21 Jan 2001 11:14:01 +0100 From: Nicolas Souchu To: trim-your-headers@loopback.net Cc: freebsd-hackers@freebsd.org Subject: Re: more info about: odd result of pci_read_config Message-ID: <20010121111401.A10148@ontario.alcove-int> References: <20010120161834.B20753@ontario.alcove-int> <20010121004349.A27198@ontario.alcove-int> <14954.24548.925891.707424@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <14954.24548.925891.707424@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Sat, Jan 20, 2001 at 11:11:39PM -0500 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 20, 2001 at 11:11:39PM -0500, Andrew Gallatin wrote: > > Nicolas Souchu writes: > <...> > > What is the hose field? > > It is for server-class alphas. Alphas do their peer PCI buses a > little differently. Rather than have a ppb between "peer" pci buses, > each different peer bus (or hose) is rooted separately at the nexus. > So you can have two PCI buses labeled "0" with no ppb between them, > for example. Platform support code needs to know which hose a bus is > on so that it can diddle with the correct set of registers to access > memory, i/o and pci config spaces. Thanks. > > > cfg.hose = -1; > > If you need to set this, please set it to zero so that it and any code > derived from it will have at least a fighting chance of working on > alpha, where this field is not ignored.. Ok, but this how it is initialized by pci_ioctl in R4.2, and this is not i386 MD code... Nicholas -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 2:19:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 409D937B401; Sun, 21 Jan 2001 02:19:05 -0800 (PST) Received: from nsouch by smtp.alcove.fr with local (Exim 3.12 #1 (Debian)) id 14KHaR-0002f4-00; Sun, 21 Jan 2001 11:19:03 +0100 Date: Sun, 21 Jan 2001 11:19:03 +0100 From: Nicolas Souchu To: John Baldwin Cc: "Donald J . Maddox" , freebsd-hackers@FreeBSD.org Subject: Re: more info about: odd result of pci_read_config Message-ID: <20010121111903.B10148@ontario.alcove-int> References: <20010120192739.A2127@cae88-102-101.sc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: ; from jhb@FreeBSD.org on Sat, Jan 20, 2001 at 04:35:11PM -0800 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 20, 2001 at 04:35:11PM -0800, John Baldwin wrote: > Look in /sys/compile/ after compiling a kernel, it should be in pci_if.* > It's a function that ues kobj to lookup the pci_read_config method in the > parent bus. Look in the PCI code to find the real pci_read_config... > > >From sys/dev/pci/pci.c: > > DEVMETHOD(pci_read_config, pci_read_config_method), > > static u_int32_t > pci_read_config_method(device_t dev, device_t child, int reg, int width) > { > struct pci_devinfo *dinfo = device_get_ivars(child); > pcicfgregs *cfg = &dinfo->cfg; > > return PCIB_READ_CONFIG(device_get_parent(dev), > cfg->bus, cfg->slot, cfg->func, > reg, width); > } On -stable, it calls directly pci_cfgread() with the cfg. My viapm driver is a kmodule. Could it be that PCI_READ_CONFIG is not correctly resolved and returns ENXIO which is 0x6? I'll try to wire it in the kernel. Nicholas -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 7:46:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nisser.com (c0039.upc-c.chello.nl [212.187.0.39]) by hub.freebsd.org (Postfix) with ESMTP id DC4C137B402; Sun, 21 Jan 2001 07:45:53 -0800 (PST) Received: from nisser.com (roelof [10.0.0.2]) by nisser.com (8.9.3/8.9.2) with ESMTP id QAA93365; Sun, 21 Jan 2001 16:45:50 +0100 (CET) (envelope-from roelof@nisser.com) Message-ID: <3A6B042E.659C716D@nisser.com> Date: Sun, 21 Jan 2001 16:45:50 +0100 From: Roelof Osinga Organization: Nisser - Nr. 1 in Veiligheid X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Bjoern Fischer Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MAIL set by whom? References: <3A6A50F3.307C9E06@nisser.com> <20010121103324.A297@frolic.no-support.loc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bjoern Fischer wrote: > > > ... > > So what gives? (IOW please help! :) > > You can set MAIL via /etc/login.conf, all applications that use > either login(1) or setusercontext(3) should work. > > Beware of ssh! The OpenSSH client, that is part of FreeBSD is > completey buggy here: It sets MAIL to /var/mail/$USER, this is > hardcoded. I have a dirty fix, maybe I'll clean it up and > send it as a PR or to Kris (Kris, are you still ssh maintainer?) And guess what I'm using ;). But that explains it. Thanks for reminding me. > This whole stuff of initial user environment and friends has > to be cleaned up to be consistent for all login methods: login(1), > xdm, rsh, rlogin, ssh, telnet. I would volunteer(sic!) for a in detail > analysis of this issue if I get feedback on this. (i.e. looking for > inconsistencies, where to put on solutions (e.g. a pam module > that evals /etc/login.conf via setusercontext(3)). Grand gesture. Laudable even. Yeah, that PAM sure seems to've become popular. The Courier IMAP port also insisted upon its installation. Insisted in that fiddling with the makefile only resulted in failure to configure. But that's a whole different story. > To fiddle with user's .bash{rc,_profile}, .tcshrc, .whateverrc > is the wrong way. Some rc files are not evaluated for non login shells, > so you put it into .bashrc or whatever get executed for non login > shells; if you do this you parameters will be overwritten each time > you start a new shell (e.g. xterm). Sure, but it does the trick for now. > The user should have a minimal reasonable environment (even without > shell rc files, if you want to go that far), that he/she may optionally > extend or adapt. /etc/login.conf, maybe in combination with pam, is > the right thing for doing this. Mebbe. But just like there's PAM, there's also LDAP and let us not forget Kerberos. Played with them, once upon a time, but not enough to have a feel for their possible impacts. Just be careful with what you volunteer for! ;). Roelof -- Home is where the (@) http://eboa.com/ is. Nisser home -- http://www.Nisser.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 8: 6:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from lisa.darkworld.prv (pD902BD7C.dip.t-dialin.net [217.2.189.124]) by hub.freebsd.org (Postfix) with ESMTP id 565C437B401 for ; Sun, 21 Jan 2001 08:06:20 -0800 (PST) Received: from blade (blade.darkworld.prv [192.168.1.2]) by lisa.darkworld.prv (8.11.0/8.11.0) with SMTP id f0LG6Aq00366 for ; Sun, 21 Jan 2001 17:06:19 +0100 (CET) (envelope-from d_f0rce@gmx.de) From: "Alex" To: Subject: Problems attaching an interrupt handler Date: Sun, 21 Jan 2001 17:10:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C083CD.0EB2B120" 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.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C083CD.0EB2B120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I started experimenting with kernel hacking to write an infrared device driver. Therfore I read Alexander Langer's article on DaemonNews and started modifying the led.c example code. Unfortunately I can't get my interrupt handler working. Could anyone please have a short look on my code. On loading the module the first time everything stays stable and vmstat -i shows 1 INT on my device. After unloading the module and reloading it the kernel crashes on the next incoming interrupt. Any ideas? Alex ------=_NextPart_000_0000_01C083CD.0EB2B120 Content-Type: application/octet-stream; name="mydev.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mydev.c" /*=0A= * Copyright (c) 2000. M. Warner Losh. All Rights Reserved.=0A= *=0A= * "THE BEER-WARE LICENSE" (Revision 42):=0A= * wrote this file. As long as you retain this notice = you=0A= * can do whatever you want with this stuff. If we meet some day, and = you think=0A= * this stuff is worth it, you can buy me a beer in return. M. Warner = Losh=0A= */=0A= =0A= /*=0A= * Simple driver for the I-Opener LED, but likely could be adapted=0A= * to any led driver. This is intended to be a thought excersize=0A= * as well as a useful sample driver. Since I don't have a hackable=0A= * iopener around to test it out on.=0A= *=0A= * The LED is located at 0x404c on the iopener. Likely we should find = this=0A= * in the pci space, and then do stuff from tehre. However, it appears = to=0A= * be controlled in some way by acpi, so I'm going to try to write this = driver=0A= * to not interfere with that.=0A= *=0A= * the lower two bits of this register control the state of the LED. = The left=0A= * led, with the mail ICON, is controlled by bit 0. The phone led is=0A= * controlled by bit 1.=0A= *=0A= * This is a bog simple ISA driver... Would make a useful example, imho.=0A= *=0A= * Since I'm lazy, I have only a write interface. The characters = recieved=0A= * by the driver are masked and the results sent to these gpios. This=0A= * allows things like '1' to turn on the led and '0' to turn off the led.=0A= * There is a minor number for each led controlled.=0A= *=0A= * The read interface returns 1 character ('0' off '1' on) for the state =0A= * of the led.=0A= *=0A= * thanks to "roastbeef" who posted technical information about this to = the=0A= * I-Opener BBS web site.=0A= */=0A= =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= =0A= =0A= struct ir_softc =0A= {=0A= bus_space_tag_t bst;=0A= bus_space_handle_t bsh;=0A= dev_t dev0;=0A= dev_t dev1;=0A= u_int32_t open_mask;=0A= u_int32_t read_mask;=0A= struct resource *res;=0A= int rid;=0A= struct resource *irq;=0A= void *ih;=0A= int irqid;=0A= };=0A= =0A= static devclass_t ir_devclass;=0A= =0A= #define IR_IOADDR 0x3f8=0A= =0A= static void ir_intr( void *p );=0A= void get_sio_status( struct ir_softc *sc );=0A= =0A= =0A= static void=0A= ir_identify (driver_t *driver, device_t parent)=0A= {=0A= devclass_t dc;=0A= device_t child;=0A= =0A= dc =3D devclass_find("ir");=0A= if (devclass_get_device(dc, 0) =3D=3D NULL) {=0A= child =3D BUS_ADD_CHILD(parent, 0, "ir", -1);=0A= bus_set_resource(child, SYS_RES_IOPORT, 0, IR_IOADDR, 7);=0A= bus_set_resource(child, SYS_RES_IRQ, 0, 4, 1);=0A= }=0A= uprintf("IR Ident\n");=0A= }=0A= =0A= static int=0A= ir_probe(device_t dev)=0A= {=0A= if (device_get_unit(dev) !=3D 0)=0A= return (ENXIO);=0A= if (bus_get_resource_start(dev, SYS_RES_IOPORT, 0) =3D=3D 0)=0A= return (ENXIO);=0A= =0A= uprintf("IR Probe\n");=0A= return (0);=0A= }=0A= =0A= static int=0A= ir_attach(device_t dev)=0A= {=0A= struct ir_softc *sc;=0A= u_int8_t old;=0A= =0A= sc =3D (struct ir_softc *) device_get_softc(dev);=0A= sc->rid =3D 0;=0A= sc->res =3D bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->rid, 0ul, = ~0ul, 7,=0A= RF_ACTIVE);=0A= if (sc->res =3D=3D NULL)=0A= return ENXIO;=0A= sc->bst =3D rman_get_bustag(sc->res);=0A= sc->bsh =3D rman_get_bushandle(sc->res);=0A= sc->open_mask =3D 0;=0A= sc->read_mask =3D 0;=0A= =0A= uprintf("IR Attach\nTrying to access device ....\n");=0A= =0A= get_sio_status( sc );=0A= =0A= /* FIFO Puffer aktivieren */=0A= bus_space_write_1(sc->bst, sc->bsh,2,(u_int8_t) 7);=0A= /* keine Kontrolle, da IIR fuer FIFO-Operation write only */=0A= =0A= /* LCR Bit 7 auf 0 */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,3);=0A= old &=3D ~128; /* Bit 7 ausnullen */=0A= bus_space_write_1(sc->bst, sc->bsh,3,(u_int8_t) old);=0A= =0A= /* IER setzen, um Interrupt bei Modem Status Aenderung auszuloesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,1);=0A= old &=3D ~1; /* Bit 0 ausnullen =3D> kein INT ausloesen, sobald ein = neues Zeichen im RBR */=0A= old &=3D ~2; /* Bit 1 ausnullen =3D> kein INT sobald THR leer */=0A= old &=3D ~4; /* Bit 2 ausnullen =3D> kein INT sobald Aenderung im LSR */=0A= old |=3D 8; /* Bit 3 setzen =3D> INT bei Aenderung im MSR */=0A= bus_space_write_1(sc->bst, sc->bsh,1,(u_int8_t) old);=0A= =0A= /* RTS im MCR auf high setzen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,4);=0A= old |=3D 1; /* Bit 0 setzen - DTR auf 0 -> PC bereit */=0A= old |=3D 2; /* Bit 1 setzen - RTS auf 0 -> PC will senden */=0A= old |=3D 8; /* Bit 3 setzen - UART loest INTs gemaess den = Einstellungen im IER aus */=0A= old &=3D ~16; /* Bit 4 ausnullen =3D> Selbsttest aus. */=0A= bus_space_write_1(sc->bst, sc->bsh,4,(u_int8_t) old);=0A= =0A= get_sio_status( sc );=0A= =0A= /* Interrupt Handler */=0A= sc->irqid=3D0;=0A= sc->irq =3D bus_alloc_resource( dev, SYS_RES_IRQ, &sc->irqid, 0ul, = ~0ul, 1, RF_SHAREABLE | RF_ACTIVE );=0A= uprintf("IRQID: %d\n",sc->irqid);=0A= if( !sc->irq )=0A= return ENXIO;=0A= if( BUS_SETUP_INTR(device_get_parent(dev), dev, sc->irq, = INTR_TYPE_MISC, ir_intr, sc, &sc->ih) !=3D 0){=0A= uprintf("Failed to init INT\n");=0A= }=0A= return 0;=0A= }=0A= =0A= static int=0A= ir_detach(device_t dev)=0A= {=0A= struct ir_softc *sc;=0A= =0A= sc =3D (struct ir_softc *) device_get_softc(dev);=0A= /* deactivate Interrupt Handler */=0A= bus_teardown_intr(dev, sc->irq, sc->ih) !=3D 0 );=0A= bus_release_resource(dev, SYS_RES_IRQ, sc->irqid, sc->irq);=0A= =0A= =0A= /* release resources */=0A= bus_release_resource(dev, SYS_RES_IOPORT, sc->rid, sc->res);=0A= uprintf("IR Detach\n");=0A= return 0;=0A= }=0A= =0A= static device_method_t ir_methods[] =3D {=0A= /* Device interface */=0A= DEVMETHOD(device_identify, ir_identify),=0A= DEVMETHOD(device_probe, ir_probe),=0A= DEVMETHOD(device_attach, ir_attach),=0A= DEVMETHOD(device_detach, ir_detach),=0A= =0A= { 0, 0 }=0A= };=0A= =0A= static driver_t ir_driver =3D {=0A= "ir",=0A= ir_methods,=0A= sizeof(struct ir_softc),=0A= };=0A= =0A= static void ir_intr( void *p ){=0A= uprintf("GOT INTERUPT!\n");=0A= }=0A= =0A= void get_sio_status( struct ir_softc *sc ){=0A= u_int8_t old;=0A= =0A= uprintf("--------------------------------\n");=0A= /* Erstmal Bit 7 im LCR auf 0 um alle Register auszulesen,=0A= die dieses Bit auf 0 verlangen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,3);=0A= old &=3D ~128; /* Bit 7 ausnullen */=0A= bus_space_write_1(sc->bst, sc->bsh,3,(u_int8_t) old);=0A= =0A= /* RBR auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,0);=0A= uprintf("RBR: %d\n", old);=0A= =0A= /* IER auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,1);=0A= uprintf("IER: %d\n", old);=0A= =0A= /* Bit 7 im LCR wieder setzen, um Register abzufragen, die=0A= dieses Bit auf 1 brauchen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,3);=0A= old |=3D 128; /* Bit 7 setzen */=0A= bus_space_write_1(sc->bst, sc->bsh,3,(u_int8_t) old);=0A= =0A= /* DLL Register auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,0);=0A= uprintf("DLL: %d\n", old);=0A= =0A= /* DLM Register auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,1);=0A= uprintf("DLM: %d\n", old);=0A= =0A= /* Jetzt noch die Register, denen das Bit 7 wurscht ist. */=0A= /* IIR Register auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,2);=0A= uprintf("IIR: %d\n", old);=0A= =0A= /* LCR Register auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,3);=0A= uprintf("LCR: %d\n", old);=0A= =0A= /* MCR Register auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,4);=0A= uprintf("MCR: %d\n", old);=0A= =0A= /* LSR Register auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,5);=0A= uprintf("LSR: %d\n", old);=0A= =0A= /* DLM Register auslesen */=0A= old =3D bus_space_read_1(sc->bst, sc->bsh,6);=0A= uprintf("MSR: %d\n", old);=0A= uprintf("--------------------------------\n");=0A= }=0A= =0A= DRIVER_MODULE(ir, isa, ir_driver, ir_devclass, 0, 0);=0A= =0A= ------=_NextPart_000_0000_01C083CD.0EB2B120-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 8:54:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from atlas.snet.co.uk (atlas.snet.co.uk [212.87.76.6]) by hub.freebsd.org (Postfix) with ESMTP id 9914337B400 for ; Sun, 21 Jan 2001 08:54:32 -0800 (PST) Received: from 212.87.76.6 (host213-122-234-168.btinternet.com [213.122.234.168]) by atlas.snet.co.uk (8.11.0/8.11.0) with SMTP id f0LHHu151307 for ; Sun, 21 Jan 2001 17:17:56 GMT Date: Sun, 21 Jan 2001 17:06:16 +0000 From: Jamie Heckford To: freebsd-hackers@freebsd.org Subject: [MAILER-DAEMON: Returned mail: see transcript for details] Message-ID: <20010121170616.C821@freefire.psi-domain.co.uk> Reply-To: heckfordj@psi-domain.co.uk References: <200101211701.f0LH1WQ00813@freefire.psi-domain.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <200101211701.f0LH1WQ00813@freefire.psi-domain.co.uk>; from MAILER-DAEMON on Sun, Jan 21, 2001 at 17:01:32 +0000 X-Mailer: Balsa 1.0.0 Lines: 45 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, Sorry if this is the wrong place to post this, but I think it needs attention. Could someone from FreeBSD contact them to get the prob resolved ? This MX is nowhere near me, about 15 hops away! Thanks Jamie On 2001.01.21 17:01:32 +0000 Mail Delivery Subsystem wrote: The original message was received at Sun, 21 Jan 2001 17:01:13 GMT from root@localhost ----- The following addresses had permanent fatal errors ----- FreeBSD-gnats-submit@freebsd.org (reason: 554 Service unavailable; [213.122.234.168] blocked using dul.maps.vix.com, reason: See ) ----- Transcript of session follows ----- .. while talking to hub.freebsd.org.: >>> RCPT To: <<< 554 Service unavailable; [213.122.234.168] blocked using dul.maps.vix.com, reason: See 554 5.0.0 FreeBSD-gnats-submit@freebsd.org... Service unavailable -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. ===================================== email: heckfordj@psi-domain.co.uk web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile: +44 (0)7866 724 224 ===================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 9: 0:25 2001 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 65BF737B400 for ; Sun, 21 Jan 2001 09:00:08 -0800 (PST) Received: by peitho.fxp.org (Postfix, from userid 1501) id 9F21F1360C; Sun, 21 Jan 2001 12:00:04 -0500 (EST) Date: Sun, 21 Jan 2001 12:00:04 -0500 From: Chris Faulhaber To: Jamie Heckford Cc: freebsd-hackers@freebsd.org Subject: Re: [MAILER-DAEMON: Returned mail: see transcript for details] Message-ID: <20010121120004.A66974@peitho.fxp.org> Mail-Followup-To: Chris Faulhaber , Jamie Heckford , freebsd-hackers@freebsd.org References: <200101211701.f0LH1WQ00813@freefire.psi-domain.co.uk> <20010121170616.C821@freefire.psi-domain.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: <20010121170616.C821@freefire.psi-domain.co.uk>; from heckfordj@psi-domain.co.uk on Sun, Jan 21, 2001 at 05:06:16PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 05:06:16PM +0000, Jamie Heckford wrote: > Hi all, > > Sorry if this is the wrong place to post this, but > I think it needs attention. > > Could someone from FreeBSD contact them to get the prob > resolved ? > > This MX is nowhere near me, about 15 hops away! > FreeBSD has nothing to do with DUL. This means that the IP address that connected to hub is listed in DUL (i.e. a dial-up IP), which are not allowed to connect (prevents a huge amount of spam). In other words, use your ISP's mail server, not a dialup box. -- 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 Sun Jan 21 9:57:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 7CF2437B401 for ; Sun, 21 Jan 2001 09:57:36 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G7IXVF01.WSJ; Sun, 21 Jan 2001 12:57:15 -0500 Message-ID: <009201c083d3$d0054bc0$1f90c918@jehovah> From: "Bosko Milekic" To: "Alex" , References: Subject: Re: Problems attaching an interrupt handler Date: Sun, 21 Jan 2001 12:58:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This: bus_teardown_intr(dev, sc->irq, sc->ih) != 0 ); looks pretty odd. See your ir_detach(). Alex wrote: > Hi, > > I started experimenting with kernel hacking to write an > infrared device driver. Therfore I read Alexander Langer's > article on DaemonNews and started modifying the led.c > example code. > > Unfortunately I can't get my interrupt handler working. > > Could anyone please have a short look on my code. > > On loading the module the first time everything stays > stable and vmstat -i shows 1 INT on my device. After > unloading the module and reloading it the kernel > crashes on the next incoming interrupt. > > Any ideas? > > Alex > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 9:59:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from roaming.cacheboy.net (roaming.cacheboy.net [203.56.168.69]) by hub.freebsd.org (Postfix) with ESMTP id 8F30437B401 for ; Sun, 21 Jan 2001 09:59:08 -0800 (PST) Received: (from adrian@localhost) by roaming.cacheboy.net (8.11.0/8.11.0) id f0LI07i39584 for freebsd-hackers@freebsd.org; Sun, 21 Jan 2001 19:00:07 +0100 (CET) (envelope-from adrian) Date: Sun, 21 Jan 2001 19:00:07 +0100 From: Adrian Chadd To: freebsd-hackers@freebsd.org Subject: linux_connect() is broken Message-ID: <20010121190007.A39518@roaming.cacheboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Martin Blapp (mbr@imp.ch) and I have been poking at a seemingly broken linux_connect() in the linux emulation suite. Now I'm actually curious, because there's a little voodoo going on which I don't quite understand and I'd appreciate some clued people explaining it. * inside a syscall, if I return (value); what happens? * inside a syscall, if I set p->p_retval[0] to something, and then return (value); what happens ? * Does this logic also apply to the Linux syscall stuff in the kernel? Take a look at http://www.attic.ch/patches/linux-connect.txt . This describes the problem with staroffice, and a couple of patches mbr has been playing with. Since I don't know anything about the syscall stuff I can't say whether his patches are correct or not. Some clue would be appreciated here, so things like Linux Staroffice can work properly, and some syscall clue can be gleaned. Thanks! Adrian -- Adrian Chadd "Programming is like sex: One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 10:18:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 504C137B400; Sun, 21 Jan 2001 10:18:00 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id f0LIHwa85133; Sun, 21 Jan 2001 19:17:59 +0100 (CET) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 21 Jan 2001 19:24:15 +0100 (CET) From: Martin Blapp To: freebsd-hackers@freebsd.org Cc: Adrian Chadd Subject: RE: linux_connect() is broken 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 Also have a look at: http://www.FreeBSD.org/cgi/cvsweb.cgi/syssrc/sys/compat/ linux/common/linux_socket.c?rev=1.21.2.2 &content-type=text/x-cvsweb-markup&cvsroot=netbsd (Add these three lines together) There is a comment form linux_connect(): */ * We should only let this call succeed once per * non-blocking connect; however we don't have * a convenient place to keep that state.. */ But - that's happening now exactly with patch1 (also included below) kernel: LINUX: linux_connect( s(36), name(2ac40590), namelen(16) )=0; kernel: LINUX: linux_send( s(36), buf(bc1fead0), len(30), flags(00000000) )=0; kernel: LINUX: linux_to_bsd_msg_flags( ret_flags(00000000) ); kernel: LINUX: linux_to_bsd_msg_flags( flags(00000000) ); kernel: LINUX: linux_recvfrom( s(36), buf(bc1ff768), len(1024), flags(00000000), from(bc1fe89c), fromlenaddr(bc1fe884) )=0; kernel: LINUX: linux_socket( protocol(0), type(1), domain(2) )=0; kernel: LINUX: linux_connect( s(36), name(08536880), namelen(16) )=36; kernel: LINUX: linux_connect( s(36), name(085368d8), namelen(16) )=56; First connect() succeeds, second gets EINPROGRESS, third gets EISCONN and Staroffice works as it should with this patch. --- sys/compat/linux/linux_socket.c Sun Jan 21 03:10:45 2001 +++ sys/compat/linux/linux_socket.c Sun Jan 21 02:59:44 2001 @@ -454,7 +454,7 @@ return (error); p->p_retval[0] = stat; - return (0); + return (EISCONN); } } Martin Martin Blapp, mb@imp.ch ------------------------------------------------ Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 ------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 10:42: 4 2001 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 6041737B400 for ; Sun, 21 Jan 2001 10:41:46 -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 f0LIfiq05771 for ; Sun, 21 Jan 2001 19:41:44 +0100 (MET) Received: from deathstar (t-27-92.athome.tue.nl [131.155.228.92]) by hermes.tue.nl (Postfix) with ESMTP id 43ADE2E802 for ; Sun, 21 Jan 2001 19:41:44 +0100 (CET) From: "Marco van de Voort" To: freebsd-hackers@freebsd.org Date: Sun, 21 Jan 2001 19:41:54 +0100 Subject: direct ports access from userland. Message-ID: <3A6B3B82.15538.103246@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As mentioned often before ( :-) ) I'm porting a compiler. Currently, I'm working on the last bits, and one of the things left is the possibility to do port-access as root from userland under Linux. Does FreeBSD have any possibility to this? 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 Sun Jan 21 11:15:46 2001 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 0E03737B401; Sun, 21 Jan 2001 11:15:29 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id UAA66787; Sun, 21 Jan 2001 20:15:27 +0100 (CET) (envelope-from 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: Adrian Chadd Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: linux_connect() is broken References: <20010121190007.A39518@roaming.cacheboy.net> From: Dag-Erling Smorgrav Date: 21 Jan 2001 20:15:26 +0100 In-Reply-To: Adrian Chadd's message of "Sun, 21 Jan 2001 19:00:07 +0100" Message-ID: Lines: 19 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 Adrian Chadd writes: > * inside a syscall, if I return (value); what happens? errno gets set to that value, and if it's non-zero, the userland syscall code returns -1 to the caller. > * inside a syscall, if I set p->p_retval[0] to something, and then > return (value); what happens ? If the value you return is non-zero, see above. If it's zero, the userland syscall code returns p->p_retval[0] to the caller. > * Does this logic also apply to the Linux syscall stuff in the kernel? I think so. Marcel would be better placed to answer that. 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 Sun Jan 21 11:36:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hyperreal.org (taz.hyperreal.org [209.133.83.16]) by hub.freebsd.org (Postfix) with SMTP id F2F9637B401 for ; Sun, 21 Jan 2001 11:36:33 -0800 (PST) Received: (qmail 16439 invoked by uid 12); 21 Jan 2001 19:36:33 -0000 Message-ID: <20010121193633.16438.qmail@hyperreal.org> From: mike@hyperreal.org Subject: Re: MAIL set by whom? To: bfischer@Techfak.Uni-Bielefeld.DE Date: Sun, 21 Jan 2001 11:36:33 -0800 (PST) Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL60 (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 Someone forwarded me Bjorn's post. > You can set MAIL via /etc/login.conf, all applications that use > either login(1) or setusercontext(3) should work. > > Beware of ssh! The OpenSSH client, that is part of FreeBSD is > completey buggy here: It sets MAIL to /var/mail/$USER, this is > hardcoded. I have a dirty fix, maybe I'll clean it up and > send it as a PR or to Kris (Kris, are you still ssh maintainer?) (FYI) On Jan 11 I posted to the freebsd-questions and openssh-unix-dev lists the following. I received no replies. This is just a workaround, not a solution, really. ----- Forwarded message (env-from mike) ----- From mike Thu Jan 11 20:17:02 2001 Subject: login.conf MAIL environment weirdness solved To: freebsd-questions@freebsd.org Date: Thu, 11 Jan 2001 20:17:02 -0800 (PST) CC: openssh-unix-dev@mindrot.org X-Mailer: ELM [version 2.4ME+ PL60 (25)] Content-Length: 1797 A while back, I posted to the freebsd-questions list about a problem I was having getting custom MAIL environment variable settings in /etc/login.conf to take. Something had happened between FreeBSD 3.3 and 4.2 that caused MAIL to always be set to /var/mail/$USER. It turns out this was a problem with the sshd configuration. The problem was apparently related to the fact OpenSSH's sshd is now configured by default with "UseLogin no", meaning it will not invoke the system's login(1) after authentication. I changed this to "UseLogin yes" and sent a HUP signal to sshd, and all is well; MAIL is now whatever I set it to in /etc/login.conf (and /etc/login.conf.db). The version of OpenSSH that comes with FreeBSD 4.2, if "UseLogin no" is set or is undefined, will seem to process *other* environment variables defined in /etc/login.conf, but always leaves MAIL as the default value which is compiled into sshd. This was very a confusing situation and made the problem difficult to diagnose. More recent snapshots of OpenSSH do not seem to acknowledge environment changes in /etc/login.conf at all, when UseLogin was no. So like I said, the solution was "UseLogin yes" in sshd_config. Now I have some questions: 1. What risks are there in having "UseLogin yes"? 2. Is the current sshd behaving as intended (not doing anything to cause /etc/login.conf.db to be processed at all)? 3. Why was the older version picking up the login.conf environment settings, aside from MAIL, even if "UseLogin no" was set? - Mike ________________________________________________________________________ Mike Brown / Hyperreal | Hyperreal http://music.hyperreal.org/ PO Box 61334 | XML & XSL http://skew.org/xml/ Denver CO 80206-8334 USA | personal http://www.hyperreal.org/~mike/ ----- End of forwarded message (env-from mike) ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 11:51:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id AD5CB37B401 for ; Sun, 21 Jan 2001 11:51:10 -0800 (PST) Received: from bellatlantic.net (client-151-198-135-29.nnj.dialup.bellatlantic.net [151.198.135.29]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id OAA20002; Sun, 21 Jan 2001 14:50:30 -0500 (EST) Message-ID: <3A6B3D85.9773C9ED@bellatlantic.net> Date: Sun, 21 Jan 2001 14:50:29 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Neil Blakey-Milner Cc: Matt Dillon , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.ORG, gjb@gbch.net Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neil Blakey-Milner wrote: > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > All, > > > > I've committed these changes for cron to support DST change > > to -current (see PR bin/24494 for description of my tests). > > Everyone is welcome to test them out. > > Please let me know if you encounter any problems caused by them > > (and better do that before these changes would be MFCed to -stable > > in a few weeks). > > I do believe this is premature. There really should at least be an > option for the old behaviour, and there is a good argument for making > the new behaviour optional dependent on a variable with the old Let me ask a simple question: Why ? What are the benefits of preserving the old behavior ? As far as I've watched this thread nobody had explained it. So could you please elaborate ? On the other hand I clearly see the benefits of avoiding loss or duplication of once-a-day (or even more rare) cron jobs. If some job is scheduled once a day (or even once a week or once a month) then it's probably a rather heavy job. So running two of them at once is not a good thing even if they would not mess up each other but just slow down the machine. Skipping such a job seems to me as an almost equally bad thing. (Yes, I'm speaking from my personal experience as sysadmin as well). > behaviour default. _Especially_ if you intend to MFC this, since > changing this behaviour in a minor release, without a way to have the > old behaviour, is almost certainly wrong. That's why I asked for comments. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 11:59: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tao.org.uk (genesis.tao.org.uk [194.242.131.94]) by hub.freebsd.org (Postfix) with ESMTP id 4AE0137B400; Sun, 21 Jan 2001 11:58:41 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id 988D43174; Sun, 21 Jan 2001 19:58:39 +0000 (GMT) Date: Sun, 21 Jan 2001 19:58:39 +0000 From: Josef Karthauser To: Luigi Rizzo Cc: freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Does anyone know how to let fd0.1720 be bootable? Message-ID: <20010121195839.C6250@tao.org.uk> Mail-Followup-To: Josef Karthauser , Luigi Rizzo , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG References: <20010120103431.D12408@cae88-102-101.sc.rr.com> <200101202119.f0KLJHK19494@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101202119.f0KLJHK19494@iguana.aciri.org>; from rizzo@aciri.org on Sat, Jan 20, 2001 at 01:19:17PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 20, 2001 at 01:19:17PM -0800, Luigi Rizzo wrote: > > I think this is a BIOS issue. I don't think any BIOS will let you > > boot from arbitrarily-formatted floppies :) > > the 1480 format works. Have you got this working now - or was it the larger size that didn't work? Joe > > luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 12: 7:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mink01.tirloni.co.uk (200-191-83-228-as.acessonet.com.br [200.191.83.228]) by hub.freebsd.org (Postfix) with ESMTP id 266C637B401 for ; Sun, 21 Jan 2001 12:07:35 -0800 (PST) Received: from mink01 (mink01 [127.0.0.1]) by mink01.tirloni.co.uk (8.11.1/8.9.3) with ESMTP id f0LJqTR00587 for ; Sun, 21 Jan 2001 17:52:30 -0200 (BRST) (envelope-from tirloni@techie.com) Date: Sun, 21 Jan 2001 17:52:29 -0200 (BRST) From: "Giovanni P. Tirloni" X-Sender: tirloni@mink01.tirloni.co.uk To: freebsd-hackers@FreeBSD.org Subject: Securelevel idea 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 Hello, I was thinking about securelevels this afternoon and my brain came up with an idea: what about if we could set fine-grained securelevels? Like, each securelevel could have its own set of prohibitons and that could only be changed setting some option in the kernel and compiling a new one. The general idea is to give the machine's admin enough power so he/she can change it to his/her needs. Can anyone comment my idea ? Thanks in advance, Giovanni P. Tirloni tirloni@techie.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 12:22:23 2001 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 49D0537B400 for ; Sun, 21 Jan 2001 12:22:03 -0800 (PST) Received: (qmail 42013 invoked by uid 1001); 22 Jan 2001 06:21:52 +1000 X-Posted-By: GJB-Post 2.11 18-Jan-2001 X-Operating-System: FreeBSD 4.1-RELEASE i386 X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Mon, 22 Jan 2001 06:21:51 +1000 From: Greg Black To: Sergey Babkin Cc: Neil Blakey-Milner , Matt Dillon , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> In-reply-to: <3A6B3D85.9773C9ED@bellatlantic.net> of Sun, 21 Jan 2001 14:50:29 EST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergey Babkin wrote: > Neil Blakey-Milner wrote: > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > All, > > > > > > I've committed these changes for cron to support DST change > > > to -current (see PR bin/24494 for description of my tests). > > > Everyone is welcome to test them out. > > > Please let me know if you encounter any problems caused by them > > > (and better do that before these changes would be MFCed to -stable > > > in a few weeks). > > > > I do believe this is premature. There really should at least be an > > option for the old behaviour, and there is a good argument for making > > the new behaviour optional dependent on a variable with the old > > Let me ask a simple question: Why ? What are the benefits of > preserving the old behavior ? As far as I've watched this thread > nobody had explained it. So could you please elaborate ? You have not been paying attention. Please go back and /read/ the archives on this topic which has been thrashed out in great detail here. We did not reach agreement about the desired behaviour because the nature of this issue is that different people desire different behaviour. What was agreed by those who contributed was clearly that the old behaviour was to be preserved by default and that new behaviour was to be enabled by a command-line option, which could be set in rc.conf. You have shown no reason not to go with the solution that was agreed, so please don't just jump in with your big boots on insisting that you know best. Nobody knows best about this. > > behaviour default. _Especially_ if you intend to MFC this, since > > changing this behaviour in a minor release, without a way to have the > > old behaviour, is almost certainly wrong. > > That's why I asked for comments. You should have read the thread more carefully. But you have been given comments now. Take heed of them and don't push ahead with this plan. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 12:31:18 2001 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 CC73837B402 for ; Sun, 21 Jan 2001 12:30:57 -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 MAA64566; Sun, 21 Jan 2001 12:30:23 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3A6B46DF.7BE84F45@FreeBSD.org> Date: Sun, 21 Jan 2001 12:30:23 -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: Sergey Babkin Cc: Neil Blakey-Milner , Matt Dillon , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.org, gjb@gbch.net Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergey Babkin wrote: > > Neil Blakey-Milner wrote: > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > All, > > > > > > I've committed these changes for cron to support DST change > > > to -current (see PR bin/24494 for description of my tests). > > > Everyone is welcome to test them out. > > > Please let me know if you encounter any problems caused by them > > > (and better do that before these changes would be MFCed to -stable > > > in a few weeks). > > > > I do believe this is premature. There really should at least be an > > option for the old behaviour, and there is a good argument for making > > the new behaviour optional dependent on a variable with the old > > Let me ask a simple question: Why ? What are the benefits of > preserving the old behavior ? As far as I've watched this thread > nobody had explained it. So could you please elaborate ? The fact that you do not understand, or do not accept the many salient points that have been made in opposition to this change does not mean that they do not exist. > On the other hand I clearly see the benefits of avoiding loss > or duplication of once-a-day (or even more rare) cron jobs. > If some job is scheduled once a day (or even once a week or > once a month) then it's probably a rather heavy job. So running > two of them at once is not a good thing even if they would not > mess up each other but just slow down the machine. Skipping > such a job seems to me as an almost equally bad thing. > (Yes, I'm speaking from my personal experience as sysadmin as well). > > > behaviour default. _Especially_ if you intend to MFC this, since > > changing this behaviour in a minor release, without a way to have the > > old behaviour, is almost certainly wrong. > > That's why I asked for comments. With changes of this magnitude we do not shoot first and ask questions later. Both the proponents and opponents of this change agreed that AT MINIMUM there should be a command line option to enable the new behavior. I was planning to commit Gerhard's rc patches to allow for specifying flags to cron during startup today (and still may get to it later) to make testing the change easier. Personally, I had a lot of sympathy with the idea of the proponents making a port of the new cron, but I could live with the idea of a command line option, defaulting to the old behavior. In either case, you need to back that commit out. Your actions were premature and indefensable. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" 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 Sun Jan 21 12:36:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 5071A37B400 for ; Sun, 21 Jan 2001 12:35:58 -0800 (PST) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id JAA19266; Mon, 22 Jan 2001 09:35:53 +1300 (NZDT) Message-Id: <200101212035.JAA19266@ducky.nz.freebsd.org> From: "Dan Langille" Organization: The FreeBSD Diary / FreshPorts To: Sergey Babkin Date: Mon, 22 Jan 2001 09:35:51 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Reply-To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: <3A6B3D85.9773C9ED@bellatlantic.net> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Jan 2001, at 14:50, Sergey Babkin wrote: > Neil Blakey-Milner wrote: > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > All, > > > > > > I've committed these changes for cron to support DST change > > > to -current (see PR bin/24494 for description of my tests). > > > Everyone is welcome to test them out. > > > Please let me know if you encounter any problems caused by them > > > (and better do that before these changes would be MFCed to -stable > > > in a few weeks). > > > > I do believe this is premature. There really should at least be an > > option for the old behaviour, and there is a good argument for making > > the new behaviour optional dependent on a variable with the old > > Let me ask a simple question: Why ? What are the benefits of > preserving the old behavior ? First, it's not "old" behaviour. It is existing behaviour. There is a difference. Because that's what was discussed and agreed to. On this list. > As far as I've watched this thread > nobody had explained it. So could you please elaborate ? Nobody explained it to your satisfaction but you still committed it? > On the other hand I clearly see the benefits of avoiding loss > or duplication of once-a-day (or even more rare) cron jobs. > If some job is scheduled once a day (or even once a week or > once a month) then it's probably a rather heavy job. So running > two of them at once is not a good thing even if they would not > mess up each other but just slow down the machine. Skipping > such a job seems to me as an almost equally bad thing. > (Yes, I'm speaking from my personal experience as sysadmin as well). People have asked for the existing behaviour because they want it. POLA has already been explained. Other reasons have been explained. I'm assuming you read what I read. > > behaviour default. _Especially_ if you intend to MFC this, since > > changing this behaviour in a minor release, without a way to have the > > old behaviour, is almost certainly wrong. > > That's why I asked for comments. You have pointed out the PR (24494). Does any documentation exist which describes how this change will affect existing systems? Details of the options for invoking the proposed new behaviour? Such things were marked as important during the discussions. It would be helpful to be able to read these things now that it has been commited. [before anyone suggestions, no, I'm not going to read the code to find out] -- Dan Langille pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 12:36:39 2001 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 3312F37B6A2 for ; Sun, 21 Jan 2001 12:36:20 -0800 (PST) Received: (qmail 42304 invoked by uid 1001); 22 Jan 2001 06:36:16 +1000 X-Posted-By: GJB-Post 2.11 18-Jan-2001 X-Operating-System: FreeBSD 4.1-RELEASE i386 X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Mon, 22 Jan 2001 06:36:16 +1000 From: Greg Black To: heckfordj@psi-domain.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: [MAILER-DAEMON: Returned mail: see transcript for details] References: <200101211701.f0LH1WQ00813@freefire.psi-domain.co.uk> <20010121170616.C821@freefire.psi-domain.co.uk> In-reply-to: <20010121170616.C821@freefire.psi-domain.co.uk> of Sun, 21 Jan 2001 17:06:16 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Heckford wrote: > Sorry if this is the wrong place to post this, but > I think it needs attention. It is the wrong place and the only attention it needs is from you. Read the message and understand it -- that should not be too hard for somebody who claims to be: > Chief Network Engineer > Psi-Domain - Innovative Linux Solutions. Ask Us How. Hint: use the same method of posting to the gnats address as you used to post this question -- via your friendly ISP, not direct from a dialup. Any further questions can be answered by reading the information at http://mail-abuse.org/dul/ or, if it's really necessary, by asking on the questions list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 13:14:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from icg.interactivate.com (icg.interactivate.com [207.110.42.216]) by hub.freebsd.org (Postfix) with ESMTP id 141C737B402 for ; Sun, 21 Jan 2001 13:14:12 -0800 (PST) Received: (from webmail@localhost) by icg.interactivate.com (8.11.1/8.11.1) id f0LLCkw12336; Sun, 21 Jan 2001 13:12:46 -0800 (PST) (envelope-from larry@interactivate.com) X-Authentication-Warning: icg.interactivate.com: webmail set sender to larry@interactivate.com using -f To: Sergey Babkin Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Message-ID: <980111565.3a6b50cded845@webmail.interactivate.com> Date: Sun, 21 Jan 2001 13:12:45 -0800 (PST) From: Lawrence Sica Cc: Matt Dillon , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.ORG, gjb@gbch.net References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> In-Reply-To: <3A6A059C.486F6237@bellatlantic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 24.20.227.61 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoting Sergey Babkin : > All, > > I've committed these changes for cron to support DST change > to -current (see PR bin/24494 for description of my tests). > Everyone is welcome to test them out. > Please let me know if you encounter any problems caused by them > (and better do that before these changes would be MFCed to -stable > in a few weeks). > I thought the consensus was to make it a command line feature and have the old behavior by default? Myself I get a little nervous when something as important as cron is changed without intensive testing and no way to go back to the older proven method. I'd feel alot more comfortable if these changes were made a command-line option as was discussed. I for one cannot afford cron to break on any production servers as this could literally cost my comapny thousands of dollars if scheduled tasks fail because of this change. Just my 2 cents.. --Larry > -SB > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Lawrence Sica ------------------------------------------------------------- Systems Administrator - Interactivate, Inc. larry@interactivate.com http://www.interactivate.com -------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 13:30:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 084D337B401 for ; Sun, 21 Jan 2001 13:30:27 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LLUM901851; Sun, 21 Jan 2001 14:30:23 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101212130.f0LLUM901851@harmony.village.org> To: "Alex" Subject: Re: Problems attaching an interrupt handler Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 17:10:30 +0100." References: Date: Sun, 21 Jan 2001 14:30:22 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Alex" writes: : This is a multi-part message in MIME format. : : ------=_NextPart_000_0000_01C083CD.0EB2B120 : Content-Type: text/plain; : charset="iso-8859-1" : Content-Transfer-Encoding: 7bit : : Hi, : : I started experimenting with kernel hacking to write an : infrared device driver. Therfore I read Alexander Langer's : article on DaemonNews and started modifying the led.c : example code. : : Unfortunately I can't get my interrupt handler working. : : Could anyone please have a short look on my code. : : On loading the module the first time everything stays : stable and vmstat -i shows 1 INT on my device. After : unloading the module and reloading it the kernel : crashes on the next incoming interrupt. : : Any ideas? : : Alex : : ------=_NextPart_000_0000_01C083CD.0EB2B120 : Content-Type: application/octet-stream; : name="mydev.c" : Content-Transfer-Encoding: quoted-printable : Content-Disposition: attachment; : filename="mydev.c" : : /*=0A= : * Copyright (c) 2000. M. Warner Losh. All Rights Reserved.=0A= : *=0A= : * "THE BEER-WARE LICENSE" (Revision 42):=0A= : * wrote this file. As long as you retain this notice = : you=0A= : * can do whatever you want with this stuff. If we meet some day, and = : you think=0A= : * this stuff is worth it, you can buy me a beer in return. M. Warner = : Losh=0A= : */=0A= : =0A= : /*=0A= : * Simple driver for the I-Opener LED, but likely could be adapted=0A= : * to any led driver. This is intended to be a thought excersize=0A= : * as well as a useful sample driver. Since I don't have a hackable=0A= : * iopener around to test it out on.=0A= : *=0A= : * The LED is located at 0x404c on the iopener. Likely we should find = : this=0A= : * in the pci space, and then do stuff from tehre. However, it appears = : to=0A= : * be controlled in some way by acpi, so I'm going to try to write this = : driver=0A= : * to not interfere with that.=0A= : *=0A= : * the lower two bits of this register control the state of the LED. = : The left=0A= : * led, with the mail ICON, is controlled by bit 0. The phone led is=0A= : * controlled by bit 1.=0A= : *=0A= : * This is a bog simple ISA driver... Would make a useful example, imho.=0A= : *=0A= : * Since I'm lazy, I have only a write interface. The characters = : recieved=0A= : * by the driver are masked and the results sent to these gpios. This=0A= : * allows things like '1' to turn on the led and '0' to turn off the led.=0A= : * There is a minor number for each led controlled.=0A= : *=0A= : * The read interface returns 1 character ('0' off '1' on) for the state =0A= : * of the led.=0A= : *=0A= : * thanks to "roastbeef" who posted technical information about this to = : the=0A= : * I-Opener BBS web site.=0A= : */=0A= : =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : #include =0A= : =0A= : =0A= : struct ir_softc =0A= : {=0A= : bus_space_tag_t bst;=0A= : bus_space_handle_t bsh;=0A= : dev_t dev0;=0A= : dev_t dev1;=0A= : u_int32_t open_mask;=0A= : u_int32_t read_mask;=0A= : struct resource *res;=0A= : int rid;=0A= : struct resource *irq;=0A= : void *ih;=0A= : int irqid;=0A= : };=0A= : =0A= : static devclass_t ir_devclass;=0A= : =0A= : #define IR_IOADDR 0x3f8=0A= : =0A= : static void ir_intr( void *p );=0A= : void get_sio_status( struct ir_softc *sc );=0A= : =0A= : =0A= : static void=0A= : ir_identify (driver_t *driver, device_t parent)=0A= : {=0A= : devclass_t dc;=0A= : device_t child;=0A= : =0A= : dc =3D devclass_find("ir");=0A= : if (devclass_get_device(dc, 0) =3D=3D NULL) {=0A= : child =3D BUS_ADD_CHILD(parent, 0, "ir", -1);=0A= : bus_set_resource(child, SYS_RES_IOPORT, 0, IR_IOADDR, 7);=0A= : bus_set_resource(child, SYS_RES_IRQ, 0, 4, 1);=0A= : }=0A= : uprintf("IR Ident\n");=0A= : }=0A= : =0A= : static int=0A= : ir_probe(device_t dev)=0A= : {=0A= : if (device_get_unit(dev) !=3D 0)=0A= : return (ENXIO);=0A= : if (bus_get_resource_start(dev, SYS_RES_IOPORT, 0) =3D=3D 0)=0A= : return (ENXIO);=0A= : =0A= : uprintf("IR Probe\n");=0A= : return (0);=0A= : }=0A= : =0A= : static int=0A= : ir_attach(device_t dev)=0A= : {=0A= : struct ir_softc *sc;=0A= : u_int8_t old;=0A= : =0A= : sc =3D (struct ir_softc *) device_get_softc(dev);=0A= : sc->rid =3D 0;=0A= : sc->res =3D bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->rid, 0ul, = : ~0ul, 7,=0A= : RF_ACTIVE);=0A= : if (sc->res =3D=3D NULL)=0A= : return ENXIO;=0A= : sc->bst =3D rman_get_bustag(sc->res);=0A= : sc->bsh =3D rman_get_bushandle(sc->res);=0A= : sc->open_mask =3D 0;=0A= : sc->read_mask =3D 0;=0A= : =0A= : uprintf("IR Attach\nTrying to access device ....\n");=0A= : =0A= : get_sio_status( sc );=0A= : =0A= : /* FIFO Puffer aktivieren */=0A= : bus_space_write_1(sc->bst, sc->bsh,2,(u_int8_t) 7);=0A= : /* keine Kontrolle, da IIR fuer FIFO-Operation write only */=0A= : =0A= : /* LCR Bit 7 auf 0 */=0A= : old =3D bus_space_read_1(sc->bst, sc->bsh,3);=0A= : old &=3D ~128; /* Bit 7 ausnullen */=0A= : bus_space_write_1(sc->bst, sc->bsh,3,(u_int8_t) old);=0A= : =0A= : /* IER setzen, um Interrupt bei Modem Status Aenderung auszuloesen */=0A= : old =3D bus_space_read_1(sc->bst, sc->bsh,1);=0A= : old &=3D ~1; /* Bit 0 ausnullen =3D> kein INT ausloesen, sobald ein = : neues Zeichen im RBR */=0A= : old &=3D ~2; /* Bit 1 ausnullen =3D> kein INT sobald THR leer */=0A= : old &=3D ~4; /* Bit 2 ausnullen =3D> kein INT sobald Aenderung im LSR */=0A= : old |=3D 8; /* Bit 3 setzen =3D> INT bei Aenderung im MSR */=0A= : bus_space_write_1(sc->bst, sc->bsh,1,(u_int8_t) old);=0A= : =0A= : /* RTS im MCR auf high setzen */=0A= : old =3D bus_space_read_1(sc->bst, sc->bsh,4);=0A= : old |=3D 1; /* Bit 0 setzen - DTR auf 0 -> PC bereit */=0A= : old |=3D 2; /* Bit 1 setzen - RTS auf 0 -> PC will senden */=0A= : old |=3D 8; /* Bit 3 setzen - UART loest INTs gemaess den = : Einstellungen im IER aus */=0A= : old &=3D ~16; /* Bit 4 ausnullen =3D> Selbsttest aus. */=0A= : bus_space_write_1(sc->bst, sc->bsh,4,(u_int8_t) old);=0A= : =0A= : get_sio_status( sc );=0A= : =0A= : /* Interrupt Handler */=0A= : sc->irqid=3D0;=0A= : static void ir_intr( void *p ){=0A= : uprintf("GOT INTERUPT!\n");=0A= : }=0A= Don't use uprintf in the interrupt handler. Have you set an irq hint for the device? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 13:31:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1B61637B402 for ; Sun, 21 Jan 2001 13:31:18 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LLVF901870; Sun, 21 Jan 2001 14:31:15 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101212131.f0LLVF901870@harmony.village.org> To: "Marco van de Voort" Subject: Re: direct ports access from userland. Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 19:41:54 +0100." <3A6B3B82.15538.103246@localhost> References: <3A6B3B82.15538.103246@localhost> Date: Sun, 21 Jan 2001 14:31:15 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A6B3B82.15538.103246@localhost> "Marco van de Voort" writes: : Does FreeBSD have any possibility to this? See /dev/io. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 13:32:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9FFCA37B402 for ; Sun, 21 Jan 2001 13:32:09 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LLW4901889; Sun, 21 Jan 2001 14:32:04 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101212132.f0LLW4901889@harmony.village.org> To: "Giovanni P. Tirloni" Subject: Re: Securelevel idea Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 17:52:29 -0200." References: Date: Sun, 21 Jan 2001 14:32:04 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Giovanni P. Tirloni" writes: : I was thinking about securelevels this afternoon and my brain came up : with an idea: what about if we could set fine-grained securelevels? Like, : each securelevel could have its own set of prohibitons and that could : only be changed setting some option in the kernel and compiling a new : one. Better to do this with sysctls. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 14:28:52 2001 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 4938037B402 for ; Sun, 21 Jan 2001 14:28:35 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA67700; Sun, 21 Jan 2001 23:28:27 +0100 (CET) (envelope-from 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: "Giovanni P. Tirloni" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Securelevel idea References: From: Dag-Erling Smorgrav Date: 21 Jan 2001 23:28:26 +0100 In-Reply-To: "Giovanni P. Tirloni"'s message of "Sun, 21 Jan 2001 17:52:29 -0200 (BRST)" 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 "Giovanni P. Tirloni" writes: > I was thinking about securelevels this afternoon and my brain came up > with an idea: what about if we could set fine-grained securelevels? Like, > each securelevel could have its own set of prohibitons and that could > only be changed setting some option in the kernel and compiling a new > one. Congratulations, you just invented capabilities! :) http://www.trustedbsd.org/ 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 Sun Jan 21 14:56:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 166D337B401 for ; Sun, 21 Jan 2001 14:56:05 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-231.nnj.dialup.bellatlantic.net [151.198.117.231]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id RAA21566; Sun, 21 Jan 2001 17:55:38 -0500 (EST) Message-ID: <3A6B68E9.278A6BBB@bellatlantic.net> Date: Sun, 21 Jan 2001 17:55:37 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Greg Black Cc: Neil Blakey-Milner , Matt Dillon , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Black wrote: > > Sergey Babkin wrote: > > > Neil Blakey-Milner wrote: > > > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > > All, > > > > > > > > I've committed these changes for cron to support DST change > > > > to -current (see PR bin/24494 for description of my tests). > > > > Everyone is welcome to test them out. > > > > Please let me know if you encounter any problems caused by them > > > > (and better do that before these changes would be MFCed to -stable > > > > in a few weeks). > > > > > > I do believe this is premature. There really should at least be an > > > option for the old behaviour, and there is a good argument for making > > > the new behaviour optional dependent on a variable with the old > > > > Let me ask a simple question: Why ? What are the benefits of > > preserving the old behavior ? As far as I've watched this thread > > nobody had explained it. So could you please elaborate ? > > You have not been paying attention. Please go back and /read/ > the archives on this topic which has been thrashed out in great > detail here. We did not reach agreement about the desired > behaviour because the nature of this issue is that different > people desire different behaviour. Actually, yes, I was paying not quite a close attention. But I went to the -hackers archive and re-read all the thread now. The end result is that I've seen exactly zero technical arguments on why changing the current behavior is bad. As well as zero real-life examples and only one imaginary example. That was one example of a job running at 2:30 and another job which depends on it running at 3:45. However with the current behavior if 2:30 disappears, the first job won't run anyway and thus the second job would not be able to work correctly as well. So this does not look like a quite compelling example. > What was agreed by those who contributed was clearly that the > old behaviour was to be preserved by default and that new > behaviour was to be enabled by a command-line option, which > could be set in rc.conf. You have shown no reason not to go > with the solution that was agreed, so please don't just jump in I did and if you re-read the thread you could see my e-mail on this. In short it is that a) this is what people normally expect (I agree, an arguable statement) b) practically all the commercial Unix implemenattions do support the DST changes in cron I'll comment more in answers to other e-mails. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 15:12:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 795BE37B400; Sun, 21 Jan 2001 15:12:12 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0LNC9u28668; Sun, 21 Jan 2001 15:12:09 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101212312.f0LNC9u28668@iguana.aciri.org> Subject: Re: Does anyone know how to let fd0.1720 be bootable? In-Reply-To: <20010121195839.C6250@tao.org.uk> from Josef Karthauser at "Jan 21, 2001 7:58:39 pm" To: joe@tao.org.uk (Josef Karthauser) Date: Sun, 21 Jan 2001 15:12:09 -0800 (PST) Cc: rizzo@aciri.org, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, Jan 20, 2001 at 01:19:17PM -0800, Luigi Rizzo wrote: > > > I think this is a BIOS issue. I don't think any BIOS will let you > > > boot from arbitrarily-formatted floppies :) > > > > the 1480 format works. > > Have you got this working now - or was it the larger size that didn't > work? 1480 always worked for me on the system i tried -- except on vmware. i it was the 1720k format where i had problems which i could not solve despite a number of different attempts at telling the bios that i was using 21 sectors/track. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 15:31:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 9845037B400; Sun, 21 Jan 2001 15:31:24 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-231.nnj.dialup.bellatlantic.net [151.198.117.231]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id SAA21863; Sun, 21 Jan 2001 18:31:20 -0500 (EST) Message-ID: <3A6B7148.C5446ECF@bellatlantic.net> Date: Sun, 21 Jan 2001 18:31:20 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Doug Barton Cc: cvs-committers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h References: <200101202128.f0KLSHR38414@freefall.freebsd.org> <3A6B4551.7341CAD8@FreeBSD.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Barton wrote: > > This needs to be backed out immediately. This isn't even close to what was > discussed in -hackers. After LONG, often pointless discussion, the > following points were agreed to there. Could you please look at the changes first ? The changes I committed are _not_ those from NetBSD. My changes do not try to cover all the cases of skipped minutes but are specifically for the change of DST and actually take many precautions to avoid messing with the other cases. On the points: > Gerhard Sittig wrote: > > I take notice of your (and Greg Black's) reservation / being > > opposed, respect it and conclude that the change will have to > > - default to the current behaviour (something quite usual for > > expanding changes) The behavior is quite close to the current one, differing for only the jobs running less frequently than every hour when of course they hit the DST change frame, and different in a rather safe way. It DOES NOT modify in any way the behavior of cron on an abrupt time change by date(1) or anything similar. > > - be well documented (something absolutely clear to all of us, > > strictly speaking it's way out of imagination for us how > > somebody could contribute undocumented stuff ... :) They are. See cron(8) for description and the PR text for examples and test cases. > > - yet be enabled easily for those interested in the change to > > work for them and free up some of their resources for more > > important tasks > > - maybe provide knobs (besides the on-off-switch) to customize > > behaviour in a more fine grained way All the discussion in the thread was about that sysadmins must not schedule jobs at 2:00-2:59 AM time (and actually 1:00-1:59 as well to avoid duplication though somehow nobody mentioned it). If no jobs are scheduled at this interval, then the behavior of the cron with my changes is absolutely identical to the old one. > I made the additional point that the options should be command line > options, instead of environment variables as someone else suggested. And I made the additional point that practically all the commercial Unixes do support intelligent handling of DST. Being different from them makes no good and is a lot of inconvenience. I also have a feeling that these agreed points were agreed only by the proponents of keeping the traditional behavior, practically ignoring anyone with a different opinion. > Your commit accomplishes none of that. In fact, the proponents of this I believe that it accomplishes if not perfectly all then practically all of that plus a very decent compatibility with the traditional behavior, without any need for command line or rc options. > change were seriously considering creating a new cron with their suggested _One_ proponent had proposed that. I can not find any record of anyone else supporting him. > changes and offering it as a port. It could also easily be argued that this > change should be discussed on -arch before going into the tree. I have sent the exact description of what I'm about to to do the -hackers list. The only response I got was from Matt Dillon and it was in support of these changes. That was after Gerhard Sittig tried out the NetBSD changes and found that they do not handle the DST changes as they are supposed to. I believe, this was exactly such a sort of discussion. > In any case, the current situation is entirely unacceptable, and I ask > that you revert your change asap. Could you please look at the changes and their description and after that confirm that you still want them backed out ? -SB > Sergey Babkin wrote: > > > > babkin 2001/01/20 13:28:17 PST > > > > Modified files: > > usr.sbin/cron/cron cron.8 cron.c cron.h > > Log: > > Added sensible handling of switch to and from daylight saving time > > for the jobs that fall into the disappearing or duplicated time > > interval. > > > > PR: bin/24494 > > > > Revision Changes Path > > 1.10 +28 -1 src/usr.sbin/cron/cron/cron.8 > > 1.10 +129 -6 src/usr.sbin/cron/cron/cron.c > > 1.12 +4 -1 src/usr.sbin/cron/cron/cron.h > > > > PR: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24494 > > > > http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.sbin/cron/cron/cron.8.diff?&r1=1.9&r2=1.10&f=h > > http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.sbin/cron/cron/cron.c.diff?&r1=1.9&r2=1.10&f=h > > http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.sbin/cron/cron/cron.h.diff?&r1=1.11&r2=1.12&f=h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 15:33:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3EB9537B401 for ; Sun, 21 Jan 2001 15:33:04 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0LNWun16287; Sun, 21 Jan 2001 15:32:56 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Jan 2001 15:32:56 -0800 (PST) From: Matt Dillon Message-Id: <200101212332.f0LNWun16287@earth.backplane.com> To: Sergey Babkin Cc: Greg Black , Neil Blakey-Milner , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> <3A6B68E9.278A6BBB@bellatlantic.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The problem here has nothing to do with whether changing the behavior is good or bad, and everything to do with the fact that cron is an absolutely critical core piece of software that runs on these machines and there is no guarentee that you haven't introduced one or many bugs with your rather large diff set. For better or for worse, people already know about the daylight savings shift problem. Thousands of people depend on cron to work, which means that when you make a major change like this it must be tested by a wider audience for a longer time before becoming the default. It needs to have some real-life operational experience behind it. So I have to say here that I agree with the calls to back it out... it needs to backed out, and then put back in as a command line option. Or you need to commit the command line option code ASAP and make the old behavior the default. Judging by the diffs, it should not be difficult for you to do this. Also, I've already found a problem with the code: + /* check for the daylight saving time change + * we support only change by +-1 hour happening at :00 minutes, + * those living in more strange timezones are out of luck + */ + if (last_time != 0 && tm->tm_isdst != lasttm.tm_isdst + && TargetTime > last_time /* exclude stepping back */) { This is broken. If you want to check for a DLS change there is only one right way to do it, and that is to compare the wall clock differential verses the GMT differential, and to not put in any silly restrictions like the change having to occur at the top of the hour or be a +-1 hour increment. I would rather see the code ripped completely out then to have a semi-broken DLS test. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 15:52:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 85AE037B400; Sun, 21 Jan 2001 15:52:09 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-231.nnj.dialup.bellatlantic.net [151.198.117.231]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id SAA22024; Sun, 21 Jan 2001 18:52:04 -0500 (EST) Message-ID: <3A6B7622.1158FA8E@bellatlantic.net> Date: Sun, 21 Jan 2001 18:52:02 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Doug Barton Cc: Neil Blakey-Milner , Matt Dillon , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.org, gjb@gbch.net Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> <3A6B46DF.7BE84F45@FreeBSD.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Barton wrote: > > Sergey Babkin wrote: > > > > Neil Blakey-Milner wrote: > > > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > > All, > > > > > > > > I've committed these changes for cron to support DST change > > > > to -current (see PR bin/24494 for description of my tests). > > > > Everyone is welcome to test them out. > > > > Please let me know if you encounter any problems caused by them > > > > (and better do that before these changes would be MFCed to -stable > > > > in a few weeks). > > > > > > I do believe this is premature. There really should at least be an > > > option for the old behaviour, and there is a good argument for making > > > the new behaviour optional dependent on a variable with the old > > > > Let me ask a simple question: Why ? What are the benefits of > > preserving the old behavior ? As far as I've watched this thread > > nobody had explained it. So could you please elaborate ? > > The fact that you do not understand, or do not accept the many salient > points that have been made in opposition to this change does not mean that > they do not exist. I'm sorry but the fact is not that I don't understand or don't accept some points, but that no technical points were ever mentioned. The discussion was very much on the emotional level, discussing the stupidity of people who schedule their cron jobs at 2am. Please do not misunderstand me: I do like conservatism and I do like the compatibility with previous releases. But sometimes these decisions mean incompatibility with the other Unix systems, so there is some sort of tradeoff. I think that I've found a reasonable solution that can let us have both sorts of compatibility at a quite good level. > > > behaviour default. _Especially_ if you intend to MFC this, since > > > changing this behaviour in a minor release, without a way to have the > > > old behaviour, is almost certainly wrong. > > > > That's why I asked for comments. > > With changes of this magnitude we do not shoot first and ask questions I'm sorry to ask this again and again but did you look at the changes ? > later. Both the proponents and opponents of this change agreed that AT > MINIMUM there should be a command line option to enable the new behavior. I I've proposed a solution which would implement the new option without significantly disturbing the old behavior. I had it discussed in -hackers and got only positive replies. > was planning to commit Gerhard's rc patches to allow for specifying flags My patches are different from Gerhard's. And Gerhard's test have shown that these patches do not quite solve the problem with DST support. > to cron during startup today (and still may get to it later) to make > testing the change easier. Personally, I had a lot of sympathy with the > idea of the proponents making a port of the new cron, but I could live with I do not have any sympathy to this idea. It brings linuxisation with scores of similar packages with subtle differences between them, making it difficult to predict the behavior of the typical installation and to get exactly the right package needed for a particular solution. Worse yet, making these packages coexist on one machine if too often quite a bit of trouble. > the idea of a command line option, defaulting to the old behavior. I agree with an idea of a command line option (again, nobody mentioned any technical argument why breaking minor compatibility aspect with the old behavior is unacceptable, but if people want this by a however irrational reason) but I think that making the changed behavior default is better. Simply because it hurts much less people. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 16: 8:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 1EA7937B402 for ; Sun, 21 Jan 2001 16:08:08 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-231.nnj.dialup.bellatlantic.net [151.198.117.231]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA22161; Sun, 21 Jan 2001 19:07:54 -0500 (EST) Message-ID: <3A6B79D9.119022FF@bellatlantic.net> Date: Sun, 21 Jan 2001 19:07:53 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Lawrence Sica Cc: Matt Dillon , John Gregor , Gerhard.Sittig@gmx.net, leifn@neland.dk, freebsd-hackers@FreeBSD.ORG, gjb@gbch.net Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <980111565.3a6b50cded845@webmail.interactivate.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lawrence Sica wrote: > > Quoting Sergey Babkin : > > > All, > > > > I've committed these changes for cron to support DST change > > to -current (see PR bin/24494 for description of my tests). > > Everyone is welcome to test them out. > > Please let me know if you encounter any problems caused by them > > (and better do that before these changes would be MFCed to -stable > > in a few weeks). > > > > I thought the consensus was to make it a command line feature and have the old > behavior by default? Myself I get a little nervous when something as important > as cron is changed without intensive testing and no way to go back to the older > proven method. Do you feel comfortable with the VM subsystem or SCSI subsystem changed with about the same amount of testing ? Yet these subsystems (as any core part of the kernel) are much more important than cron and much more complicated. I'd actually say that any part of the kernel used in a particular user's configuration is much more important than cron just because it can bring much bigger disaster. > I'd feel alot more comfortable if these changes were made a command-line option > as was discussed. I for one cannot afford cron to break on any production > servers as this could literally cost my comapny thousands of dollars if > scheduled tasks fail because of this change. You probably do not run -current on your production servers, do you ? The whole purpose of -current is to test the changes before they get into the production systems. And, speaking of production systems, you probably do not have any daily jobs scheduled between 1:00 and 2:59 AM ? Otherwise you'd already have problems by now. And my changes do not touch the other jobs. That's not to say that I'm against the option idea, just to show that this is not really a life-or-death issue. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 16:36:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs2.catv.ne.jp (cs2.catv.ne.jp [202.232.171.15]) by hub.freebsd.org (Postfix) with ESMTP id D103337B400 for ; Sun, 21 Jan 2001 16:36:42 -0800 (PST) Received: from keiichi by cs2.catv.ne.jp (8.9.1/3.7W) id JAA03059; Mon, 22 Jan 2001 09:35:40 +0900 (JST) Message-ID: <000d01c0840b$3fbf9240$43bb10ac@e5sc.catv.ne.jp> From: "Keiichi Ohmachi" To: References: Subject: Re: freebsd-hackers-digest V5 #9 Date: Mon, 22 Jan 2001 09:35:39 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 16:47:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id D2F4C37B400 for ; Sun, 21 Jan 2001 16:47:10 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-231.nnj.dialup.bellatlantic.net [151.198.117.231]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA22472; Sun, 21 Jan 2001 19:46:45 -0500 (EST) Message-ID: <3A6B82F5.43CA6A65@bellatlantic.net> Date: Sun, 21 Jan 2001 19:46:45 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Matt Dillon Cc: Greg Black , Neil Blakey-Milner , John Gregor , Gerhard.Sittig@gmx.net, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> <3A6B68E9.278A6BBB@bellatlantic.net> <200101212332.f0LNWun16287@earth.backplane.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > The problem here has nothing to do with whether changing the behavior > is good or bad, and everything to do with the fact that cron is an > absolutely critical core piece of software that runs on these machines > and there is no guarentee that you haven't introduced one or many bugs > with your rather large diff set. For better or for worse, people > already know about the daylight savings shift problem. Thousands > of people depend on cron to work, which means that when you > make a major change like this it must be tested by a wider audience > for a longer time before becoming the default. It needs to have some > real-life operational experience behind it. This can be applied to whole FreeBSD just as well. And IMHO cron is less critical than any part of the kernel, yet changes to the kernel don't usually bring such a strong reaction. > So I have to say here that I agree with the calls to back it out... > it needs to backed out, and then put back in as a command line option. > Or you need to commit the command line option code ASAP and make the > old behavior the default. Judging by the diffs, it should not be > difficult for you to do this. OK, I'll change it to a command line option. > Also, I've already found a problem with the code: > > + /* check for the daylight saving time change > + * we support only change by +-1 hour happening at :00 minutes, > + * those living in more strange timezones are out of luck > + */ > + if (last_time != 0 && tm->tm_isdst != lasttm.tm_isdst > + && TargetTime > last_time /* exclude stepping back */) { > > This is broken. If you want to check for a DLS change there is only > one right way to do it, and that is to compare the wall clock > differential verses the GMT differential, and to not put in any silly I disagree. Checking the difference from GMT creates a danger of misrecognition of a time zone change (for example, when a machine was physically moved) for a DST switch. So comparing is_dst is the only reliable way to tell if there actually was such a switch. > restrictions like the change having to occur at the top of the hour > or be a +-1 hour increment. I would rather see the code ripped completely > out then to have a semi-broken DLS test. This limitation stems from the way the Vixie cron works. Supporting other sorts of DST timing is either non-obvious or would require a complete rewrite of cron to make it work like in SVR4, by precalculating the time_t time of next run for each job in advance. Such a rewrite would nicely fix the problem of missed minutes under high load as well but will require significant effort to do and lots of testing. Anyway, the present limitation covers most of the globe nowadays except for Kirgizia and a few islands in Australasia (judging from the zoneinfo files). If the fix in its present form would be accepted then I guess adding more code around it for half-an-hour and arbitrary DST timing would be the next step. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 16:59: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id D43E237B401 for ; Sun, 21 Jan 2001 16:58:46 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-231.nnj.dialup.bellatlantic.net [151.198.117.231]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA22564; Sun, 21 Jan 2001 19:58:26 -0500 (EST) Message-ID: <3A6B85B2.3A10195C@bellatlantic.net> Date: Sun, 21 Jan 2001 19:58:26 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: dan@langille.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etccrontab) References: <200101212035.JAA19266@ducky.nz.freebsd.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Langille wrote: > > On 21 Jan 2001, at 14:50, Sergey Babkin wrote: > > > Let me ask a simple question: Why ? What are the benefits of > > preserving the old behavior ? > > First, it's not "old" behaviour. It is existing behaviour. There is a > difference. Because that's what was discussed and agreed to. On this > list. I believe this is just a difference of terminology. It's common to name the existing behavior "old" and the changed one as "new". > > As far as I've watched this thread > > nobody had explained it. So could you please elaborate ? > > Nobody explained it to your satisfaction but you still committed it? Nobody explained it to my satisfaction why I should not commit it. There is a subtle difference between these statements. > > On the other hand I clearly see the benefits of avoiding loss > > or duplication of once-a-day (or even more rare) cron jobs. > > If some job is scheduled once a day (or even once a week or > > once a month) then it's probably a rather heavy job. So running > > two of them at once is not a good thing even if they would not > > mess up each other but just slow down the machine. Skipping > > such a job seems to me as an almost equally bad thing. > > (Yes, I'm speaking from my personal experience as sysadmin as well). > > People have asked for the existing behaviour because they want it. > POLA has already been explained. Other reasons have been explained. > I'm assuming you read what I read. For me POLA means that the cron jobs must not disappear into nothing or be duplicated. So it's quite subjective and referring to such vague ideas as POLA is not a very technical reference. > > > behaviour default. _Especially_ if you intend to MFC this, since > > > changing this behaviour in a minor release, without a way to have the > > > old behaviour, is almost certainly wrong. > > > > That's why I asked for comments. > > You have pointed out the PR (24494). Does any documentation exist > which describes how this change will affect existing systems? Details Yes. In this PR and in a more detailed form in the change to the cron man page. The PR contains my test cases as well. > of the options for invoking the proposed new behaviour? Such things > were marked as important during the discussions. It would be helpful to > be able to read these things now that it has been commited. [before > anyone suggestions, no, I'm not going to read the code to find out] It still can be backed out. And because of the objections I'm going to add an option to enable the changed behavior in any case. Would there be any objections to the option name "-s" (from dSt) ? "-d" seems to be a bad idea because people would confuse it with the debugging option which is named "-x" in cron. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 17:22:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from arachna.com (dnai-216-15-61-88.cust.dnai.com [216.15.61.88]) by hub.freebsd.org (Postfix) with SMTP id EED0337B401 for ; Sun, 21 Jan 2001 17:22:11 -0800 (PST) Received: (qmail 7123 invoked by uid 1001); 22 Jan 2001 01:26:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Jan 2001 01:26:52 -0000 Date: Sun, 21 Jan 2001 17:26:52 -0800 (PST) From: Ian Kallen To: freebsd-hackers@freebsd.org Subject: Re: accessing an outside IP from inside a NAT net 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 Since I hate finding unanswered questions in the archive, I'm posting the resolution. The previous answers that suggested subnetting the internal network and setting up additional port diversions for the webserver in the firewall rules didn't do it, certainly not in combination. However, setting up another port diversion for natd on the internal network did the trick. The external net NIC is using the ed driver, the internal ep, so the firewall rules now simply have # wipe the slate /sbin/ipfw -f flush # outside net /sbin/ipfw add divert natd all from any to any via ed0 # inside net, this is what needed to be added /sbin/ipfw add divert natd all from any to any via ep0 # whatever other specific packet processing rules... /sbin/ipfw add pass all from any to any I had to poke around at natd and ipfw a whole lot to arrive at this conclusion, IMO the additional rule for the internal net should be in the example rc.firewall and/or in the /usr/share/examples/etc examples. cheers, -Ian -- Ian Kallen | AIM: iankallen | efax: (415) 354-3326 On Fri, 19 Jan 2001, Ian Kallen wrote: > > I'd like a hand figuring out how to access resources on the internal side > of a NAT net from within it without doing something kludgey with DNS. > i.e. suppose I run natd with a configuration like this: > > # begin /etc/natd.conf > use_sockets > same_ports > port 8668 > deny_incoming no > log > redirect_port tcp 10.0.0.128:80 206.169.18.10:80 > # end /etc/natd.conf > > Now if the DNS for the web server www.foo.com running on 10.0.0.128 > directs a browser on the 10.0.0.0 net to 206.169.18.10, it doesn't get > routed back to 10.0.0.128; it just hangs (I'm acutally not sure what's > happening there, the connction never succeeds). Is there a nice way to > handle this case without running a dummy DNS just for the 10.0.0.0 > internal net? > > thanks, > -Ian > > -- > Ian Kallen | AIM: iankallen | efax: (415) 354-3326 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 19:32:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nisser.com (c0039.upc-c.chello.nl [212.187.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 3173337B400 for ; Sun, 21 Jan 2001 19:31:55 -0800 (PST) Received: from nisser.com (roelof [10.0.0.2]) by nisser.com (8.9.3/8.9.2) with ESMTP id EAA96473; Mon, 22 Jan 2001 04:31:43 +0100 (CET) (envelope-from roelof@nisser.com) Message-ID: <3A6BA99F.FE0EECD1@nisser.com> Date: Mon, 22 Jan 2001 04:31:43 +0100 From: Roelof Osinga Organization: Nisser - Nr. 1 in Veiligheid X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mike@hyperreal.org Cc: bfischer@Techfak.Uni-Bielefeld.DE, freebsd-hackers@FreeBSD.ORG Subject: Re: MAIL set by whom? References: <20010121193633.16438.qmail@hyperreal.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG mike@hyperreal.org wrote: > > ... > So like I said, the solution was "UseLogin yes" in sshd_config. Patched it and signalled it. Waiting for the next user to come by. Another question to ask could be, why wasn't a patch completed? Roelof -- Home is where the (@) http://eboa.com/ is. Nisser home -- http://www.Nisser.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 19:34:15 2001 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 1F98437B400; Sun, 21 Jan 2001 19:33:46 -0800 (PST) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id TAA66695; Sun, 21 Jan 2001 19:33:43 -0800 (PST) (envelope-from DougB@gorean.org) Date: Sun, 21 Jan 2001 19:33:43 -0800 (PST) From: Doug Barton X-X-Sender: To: Sergey Babkin Cc: , Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h In-Reply-To: <3A6B7148.C5446ECF@bellatlantic.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 Sun, 21 Jan 2001, Sergey Babkin wrote: > Doug Barton wrote: > > > > This needs to be backed out immediately. This isn't even close to what was > > discussed in -hackers. After LONG, often pointless discussion, the > > following points were agreed to there. > > Could you please look at the changes first ? The changes I > committed are _not_ those from NetBSD. So instead of following what was agreed to on -hackers you went off on your own and committed something totally different? This is worse than I thought. > My changes do not try > to cover all the cases of skipped minutes but are specifically > for the change of DST and actually take many precautions to avoid > messing with the other cases. ... which makes the POLA violation worse instead of better. When we tell people that our cron handles DST changes, the people who live in areas where the change is not exactly one hour happening at :00 will not hear the disclaimer that they are, "out of luck," as you put it. > On the points: > > > Gerhard Sittig wrote: > > > I take notice of your (and Greg Black's) reservation / being > > > opposed, respect it and conclude that the change will have to > > > - default to the current behaviour (something quite usual for > > > expanding changes) > > The behavior is quite close to the current one, differing for > only the jobs running less frequently than every hour when of course they hit the DST change frame, and different in a rather safe way. For a definition of "safe" that is entirely inadequate. > It DOES NOT modify in any way the behavior of cron on an abrupt time > change by date(1) or anything similar. > > > - be well documented (something absolutely clear to all of us, > > > strictly speaking it's way out of imagination for us how > > > somebody could contribute undocumented stuff ... :) > > They are. See cron(8) for description and the PR text for > examples and test cases. I did read cron(8). Your changes are well described, this point is not at issue. > > > - yet be enabled easily for those interested in the change to > > > work for them and free up some of their resources for more > > > important tasks > > > - maybe provide knobs (besides the on-off-switch) to customize > > > behaviour in a more fine grained way > > All the discussion in the thread was about that sysadmins must > not schedule jobs at 2:00-2:59 AM time (and actually 1:00-1:59 > as well to avoid duplication though somehow nobody mentioned it). > If no jobs are scheduled at this interval, then the behavior > of the cron with my changes is absolutely identical to the > old one. That is certainly NOT the only discussion. I made the point several times that someone who schedules a time critical job during the DST change period will have a huge problem if their job is unexpectedly run without sufficient time to finish, or what is frequently worse their job is run twice. The proponents of the change responded by saying that you shouldn't schedule time critical jobs during this period, to which I replied that if you can solve the problem other ways then there is no need to modify cron. What I object to about making this the default is that you are effectively programming to the lowest common denominator, assuming from the start that people are too stupid to schedule their jobs properly, therefore we must fix them in ways that potentially break cron for people who expect the well established behavior. > > I made the additional point that the options should be command line > > options, instead of environment variables as someone else suggested. > > And I made the additional point that practically all the commercial > Unixes do support intelligent handling of DST. Being different > from them makes no good and is a lot of inconvenience. If you want to offer the option of making cron think for the user instead of following traditional behavior then it should be offered as a command line option, defaulting to off. Period. "We're not like everyone else" is not a compelling argument here. > I also have a feeling that these agreed points were agreed only by > the proponents of keeping the traditional behavior, practically > ignoring anyone with a different opinion. You are in fact 100% wrong. I was careful to quote the summary of agreed points from Gerhard Sittig's e-mail, who is the original proponent of the change in the first place. He asked for discussion on the change and agreed readily after several people spoke up saying that the new behavior should be an option. You need to back out your changes and let the people who are proposing a more complete solution which has been widely discussed and agreed to have time to finish their work and send it to -arch for more discussion. Your drive-by commit out of the blue of something that doesn't come close to what even the people who want the time-skewing behavior are proposing is wrong on many levels. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 21:19:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 1239737B404; Sun, 21 Jan 2001 21:18:57 -0800 (PST) Received: from [212.238.77.116] (helo=gateway.raggedclown.net) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 14KZNY-000Dtw-00; Mon, 22 Jan 2001 05:18:57 +0000 Received: from buffy.raggedclown.net (btvs.demon.nl [192.168.1.2]) by gateway.raggedclown.net (Postfix) with ESMTP id 8BD785DB2; Mon, 22 Jan 2001 06:17:39 +0100 (CET) Received: by buffy.raggedclown.net (Postfix on SuSE Linux 7.0 (i386), from userid 500) id 2DE7112C4D; Mon, 22 Jan 2001 05:43:31 +0100 (CET) Date: Mon, 22 Jan 2001 05:43:31 +0100 From: Cliff Sarginson To: Luigi Rizzo Cc: Josef Karthauser , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Does anyone know how to let fd0.1720 be bootable? Message-ID: <20010122054331.C1639@raggedclown.net> References: <20010121195839.C6250@tao.org.uk> <200101212312.f0LNC9u28668@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101212312.f0LNC9u28668@iguana.aciri.org>; from rizzo@aciri.org on Sun, Jan 21, 2001 at 03:12:09PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 03:12:09PM -0800, Luigi Rizzo wrote: > > On Sat, Jan 20, 2001 at 01:19:17PM -0800, Luigi Rizzo wrote: > > > > I think this is a BIOS issue. I don't think any BIOS will let you > > > > boot from arbitrarily-formatted floppies :) > 1480 always worked for me on the system i tried -- except on vmware. > i it was the 1720k format where i had problems which i could not For my Linux systems I have something called Tom's Root Boot, tomsrbt, which is a sort of emergency general purpose boot diskette for Linux. It is formatted to 1720, and boots on my ancient Pentium's without any BIOS adjustments... Cliff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 21:33:28 2001 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 E9C6637B400 for ; Sun, 21 Jan 2001 21:33:05 -0800 (PST) Received: (qmail 44366 invoked by uid 1001); 22 Jan 2001 15:33:01 +1000 X-Posted-By: GJB-Post 2.11 18-Jan-2001 X-Operating-System: FreeBSD 4.1-RELEASE i386 X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Mon, 22 Jan 2001 15:33:00 +1000 From: Greg Black To: Sergey Babkin Cc: dan@langille.org, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etccrontab) References: <200101212035.JAA19266@ducky.nz.freebsd.org> <3A6B85B2.3A10195C@bellatlantic.net> In-reply-to: <3A6B85B2.3A10195C@bellatlantic.net> of Sun, 21 Jan 2001 19:58:26 EST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergey Babkin wrote: > It still can be backed out. Well, what are you waiting for? Back it out. Listen to what people are saying and then maybe propose something that takes into account their concerns. To make this point a little more clearly -- the fact that Matt Dillon, who is no fool, and you have wildly divergent ideas on the appropriate/correct method to determine when to do things is further evidence (as if any were needed) that this is not a trivial thing to get right. First, people have to agree on what is right and we're not there yet. Please take note of what people are saying, stop the silly protests about your failure to be convinced by other people's arguments, and recognise that you don't have a special line to the One True Way. Finally, in reference to the confusion over POLA, get something straight: the people we must take most care not to astonish are current users of FreeBSD; after them, we can consider users who are migrating from other Unix variants. The fact that others may do things differently is not, of itself, an argument to take a wild jump into the darkness here. The continued, predictable, behaviour of cron is important to users and cannot be just played about with at your whim, and this is especially true when you don't even have support for the so-called solution you have proposed. Back it out. Do it now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 21:42: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by hub.freebsd.org (Postfix) with ESMTP id C094637B400; Sun, 21 Jan 2001 21:41:44 -0800 (PST) Received: from fwd02.sul.t-online.com by mailout00.sul.t-online.com with smtp id 14KZjb-0008Sv-00; Mon, 22 Jan 2001 06:41:43 +0100 Received: from frolic.no-support.loc (520094253176-0001@[217.80.111.105]) by fmrl02.sul.t-online.com with esmtp id 14KZjQ-1bi9XEC; Mon, 22 Jan 2001 06:41:32 +0100 Received: (from bjoern@localhost) by frolic.no-support.loc (8.11.1/8.9.3) id f0M5ai700537; Mon, 22 Jan 2001 06:36:44 +0100 (CET) (envelope-from bjoern) From: Bjoern Fischer Date: Mon, 22 Jan 2001 06:36:44 +0100 To: mike@hyperreal.org Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MAIL set by whom? Message-ID: <20010122063644.A273@frolic.no-support.loc> References: <20010121193633.16438.qmail@hyperreal.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121193633.16438.qmail@hyperreal.org>; from mike@hyperreal.org on Sun, Jan 21, 2001 at 11:36:33AM -0800 X-Sender: 520094253176-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So like I said, the solution was "UseLogin yes" in sshd_config. This only works for shh shell logins. If you want to start an application on the remote site without invoking your shell, the use of /bin/login is not possible. E.g. you want to start an xterm or a mail (x-)client on a remote machine with: ssh -f . Bjoern -- -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 21:43:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (ashto-0006.sjc.ca.bbnow.net [24.219.121.199]) by hub.freebsd.org (Postfix) with ESMTP id 6B0CE37B400 for ; Sun, 21 Jan 2001 21:43:27 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0M5ubD01966; Sun, 21 Jan 2001 21:56:38 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101220556.f0M5ubD01966@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Warner Losh Cc: "Marco van de Voort" , freebsd-hackers@FreeBSD.ORG Subject: Re: direct ports access from userland. In-reply-to: Your message of "Sun, 21 Jan 2001 14:31:15 MST." <200101212131.f0LLVF901870@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Jan 2001 21:56:37 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <3A6B3B82.15538.103246@localhost> "Marco van de Voort" writes: > : Does FreeBSD have any possibility to this? > > See /dev/io. Much better to use i386_get_ioperm/i386_set_ioperm. -- ... 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 Sun Jan 21 21:57:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from www.evil.2y.net (ip-216-23-53-20.adsl.one.net [216.23.53.20]) by hub.freebsd.org (Postfix) with ESMTP id 5E24A37B69B; Sun, 21 Jan 2001 21:57:02 -0800 (PST) Received: (from cokane@localhost) by www.evil.2y.net (8.11.1/8.11.1) id f0M69Cm02307; Mon, 22 Jan 2001 01:09:12 -0500 (EST) (envelope-from cokane) Date: Mon, 22 Jan 2001 01:09:11 -0500 From: Coleman Kane To: Luigi Rizzo Cc: Josef Karthauser , freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: Does anyone know how to let fd0.1720 be bootable? Message-ID: <20010122010910.A2151@cokane.yi.org> References: <20010121195839.C6250@tao.org.uk> <200101212312.f0LNC9u28668@iguana.aciri.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" X-Mailer: Mutt 1.0.1i In-Reply-To: <200101212312.f0LNC9u28668@iguana.aciri.org>; from rizzo@aciri.org on Sun, Jan 21, 2001 at 06:13:14PM -0500 X-Vim: vim:tw=70:ts=4:sw=4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I had issues with this when I was doing some bootsector ASM coding. Basical= ly, you have to set up the disk header (first 32 bytes of sector 1?) to tell the bios how many sectors your disk has. Many BIOSes will still only do 18 sect= ors anyway, though. I can't remember the exact layout of the disk header, but i= t is usually started with a JMP NEAR instruction past the info header (3 bytes), followed by a short OS signature (8 bytes?) and then the disk info that is typically passed in INT 13 calls. Luigi Rizzo had the audacity to say: >=20 > > On Sat, Jan 20, 2001 at 01:19:17PM -0800, Luigi Rizzo wrote: > > > > I think this is a BIOS issue. I don't think any BIOS will let you > > > > boot from arbitrarily-formatted floppies :) > > >=20 > > > the 1480 format works. > >=20 > > Have you got this working now - or was it the larger size that didn't > > work? >=20 > 1480 always worked for me on the system i tried -- except on vmware. > i it was the 1720k format where i had problems which i could not > solve despite a number of different attempts at telling the > bios that i was using 21 sectors/track. >=20 > cheers > luigi > ----------------------------------+--------------------------------------= --- > Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pi= sa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+--------------------------------------= --- >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6a86DERViMObJ880RAeJhAJ0XLozCA6C7Sh6okuSP/AAzqZWyBwCfZ7Yx U7kPhHnlYCL+2gzCCEBE9cs= =/fTz -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 22:36: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3510537B402 for ; Sun, 21 Jan 2001 22:35:44 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0M6ZbJ17648; Sun, 21 Jan 2001 22:35:37 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Jan 2001 22:35:37 -0800 (PST) From: Matt Dillon Message-Id: <200101220635.f0M6ZbJ17648@earth.backplane.com> To: Sergey Babkin Cc: Greg Black , Neil Blakey-Milner , John Gregor , Gerhard.Sittig@gmx.net, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> <3A6B68E9.278A6BBB@bellatlantic.net> <200101212332.f0LNWun16287@earth.backplane.com> <3A6B82F5.43CA6A65@bellatlantic.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> with your rather large diff set. For better or for worse, people :> already know about the daylight savings shift problem. Thousands :> of people depend on cron to work, which means that when you :> make a major change like this it must be tested by a wider audience :> for a longer time before becoming the default. It needs to have some :> real-life operational experience behind it. : :This can be applied to whole FreeBSD just as well. And IMHO :cron is less critical than any part of the kernel, yet changes :to the kernel don't usually bring such a strong reaction. I think you have a valid argument in regards to cron vs the kernel. But keep in mind that even though you are fixing a 'bug', it's a well known 'bug' so you are in fact creating an operational change to the code rather then just a bug fix or minor performance enhancement, etc... When I do major kernel work, it's usually tested by third parties for a week or two. The last three major commits I've done had been under test for three weeks (don't let the 2-5 day MFC fool you, I have to do all my work on -stable first, then forward port to -current, then MFC back to -stable). :> So I have to say here that I agree with the calls to back it out... :> it needs to backed out, and then put back in as a command line option. :> Or you need to commit the command line option code ASAP and make the :> old behavior the default. Judging by the diffs, it should not be :> difficult for you to do this. : :OK, I'll change it to a command line option. I sure would appreciate it. Thanks! :> This is broken. If you want to check for a DLS change there is only :> one right way to do it, and that is to compare the wall clock :> differential verses the GMT differential, and to not put in any silly : :I disagree. Checking the difference from GMT creates a danger :of misrecognition of a time zone change (for example, when :a machine was physically moved) for a DST switch. So comparing :is_dst is the only reliable way to tell if there actually was :such a switch. I don't consider someone changing the machine's /etc/localtime zone to be an issue, since it rarely if ever happens. And if a machine is moved, it's likely to be powered down anyway.... cron is not going to nor is it supposed to 'catch up' after downtime. Additionally, cron cannot detect a timezone change without being restarted, so the point is moot anyhow. -Matt :This limitation stems from the way the Vixie cron works. Supporting :other sorts of DST timing is either non-obvious or would require :a complete rewrite of cron to make it work like in SVR4, by :precalculating the time_t time of next run for each job in advance. :Such a rewrite would nicely fix the problem of missed minutes under :high load as well but will require significant effort to do :and lots of testing. : :Anyway, the present limitation covers most of the globe nowadays except :for Kirgizia and a few islands in Australasia (judging from the :zoneinfo files). If the fix in its present form would be accepted :then I guess adding more code around it for half-an-hour and arbitrary :DST timing would be the next step. : :-SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 21 23:45:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.189]) by hub.freebsd.org (Postfix) with SMTP id D9BFB37B401 for ; Sun, 21 Jan 2001 23:44:52 -0800 (PST) Received: (qmail 3166 invoked by uid 1000); 22 Jan 2001 07:43:27 -0000 Date: Mon, 22 Jan 2001 09:43:27 +0200 From: Peter Pentchev To: Doug Barton Cc: Sergey Babkin , cvs-committers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h Message-ID: <20010122094326.A623@ringworld.oblivion.bg> Mail-Followup-To: Doug Barton , Sergey Babkin , cvs-committers@FreeBSD.org, hackers@FreeBSD.org References: <3A6B7148.C5446ECF@bellatlantic.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 DougB@gorean.org on Sun, Jan 21, 2001 at 07:33:43PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 07:33:43PM -0800, Doug Barton wrote: > You need to back out your changes and let the people who are > proposing a more complete solution which has been widely discussed and > agreed to have time to finish their work and send it to -arch for more > discussion. Your drive-by commit out of the blue of something that doesn't > come close to what even the people who want the time-skewing behavior are > proposing is wrong on many levels. FWIW, although I did not participate in the -hackers thread, and I have not yet quite formed an opinion on the changes proposed by Gerhard Sittig, I tend to agree with Doug about this premature and not discussed at all commit. G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 0: 1: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id BF77B37B400 for ; Mon, 22 Jan 2001 00:00:49 -0800 (PST) Received: from mail.courts.govt.nz (xeon.unixathome.org [192.168.0.18]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with SMTP id VAA24729; Mon, 22 Jan 2001 21:00:44 +1300 (NZDT) Message-Id: <200101220800.VAA24729@ducky.nz.freebsd.org> To: Sergey Babkin Cc: freebsd-hackers@FreeBSD.ORG From: Dan Langille Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etccrontab) Date: Mon, 22 Jan 2001 08:00:45 GMT X-Mailer: Endymion MailMan Professional Edition v3.0.29 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergy wrote: > > > As far as I've watched this thread > > > nobody had explained it. So could you please elaborate ? > > > > Nobody explained it to your satisfaction but you still committed it? > > Nobody explained it to my satisfaction why I should not commit it. Ummm, well, that's a good reason to commit something which has generated a great deal of discussion. > It still can be backed out. After reading the points made by others urging you to back it out, I can only suggest that you back it out immediately. --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 0:11:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3F4A037B402; Mon, 22 Jan 2001 00:11:22 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0M8BF906529; Mon, 22 Jan 2001 01:11:15 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101220811.f0M8BF906529@harmony.village.org> To: Neil Blakey-Milner Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Cc: FreeBSD Current Users , Marcel Moolenaar In-reply-to: Your message of "Thu, 18 Jan 2001 10:13:15 +0200." <20010118101315.A10537@rapier.smartspace.co.za> References: <20010118101315.A10537@rapier.smartspace.co.za> Date: Mon, 22 Jan 2001 01:11:15 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010118101315.A10537@rapier.smartspace.co.za> Neil Blakey-Milner writes: : "make buildkernel" currently fails if a "make buildworld" has not I've committed this change, as threatened late last week, since no one said not to. buildworld is still required acorss major releases, when binutils change, and when config's version changes. if buildkernel fails, then do not complain unless you've also done a buildworld first and it still fails. This is a convenience for those people that know what they are doing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 1:10:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 8796D37B400 for ; Mon, 22 Jan 2001 01:10:35 -0800 (PST) Received: from wocker (wocker.int.nz.freebsd.org [192.168.0.99]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with ESMTP id WAA24873; Mon, 22 Jan 2001 22:10:28 +1300 (NZDT) Message-Id: <200101220910.WAA24873@ducky.nz.freebsd.org> From: "Dan Langille" Organization: The FreeBSD Diary / FreshPorts To: Warner Losh Date: Mon, 22 Jan 2001 22:10:28 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Reply-To: dan@langille.org Cc: FreeBSD Current Users In-reply-to: <200101220811.f0M8BF906529@harmony.village.org> References: Your message of "Thu, 18 Jan 2001 10:13:15 +0200." <20010118101315.A10537@rapier.smartspace.co.za> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22 Jan 2001, at 1:11, Warner Losh wrote: > In message <20010118101315.A10537@rapier.smartspace.co.za> Neil Blakey-Milner writes: > : "make buildkernel" currently fails if a "make buildworld" has not > > I've committed this change, as threatened late last week, since no one > said not to. > > buildworld is still required acorss major releases, when binutils > change, and when config's version changes. if buildkernel fails, then > do not complain unless you've also done a buildworld first and it > still fails. This is a convenience for those people that know what > they are doing. Thanks for that Warner. Please have a read of this URL for me and give me some suggestions as to how you think it should be updated: http://www.freebsd.org/handbook/kernelconfig-building.html ...and I'll submit a PR. cheers. -- Dan Langille pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 1:47:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from clove.rp.lan (unknown [212.74.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 7694137B400; Mon, 22 Jan 2001 01:47:11 -0800 (PST) Received: (from dom@localhost) by clove.rp.lan (8.9.3/8.8.7) id JAA08793; Mon, 22 Jan 2001 09:46:47 GMT X-Authentication-Warning: clove.rp.lan: dom set sender to dom@semantico.com using -f Date: Mon, 22 Jan 2001 09:46:47 +0000 From: Dominic Mitchell To: Roelof Osinga Cc: Bjoern Fischer , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: PAM (was: Re: MAIL set by whom?) Message-ID: <20010122094647.A7853@semantico.com> References: <3A6A50F3.307C9E06@nisser.com> <20010121103324.A297@frolic.no-support.loc> <3A6B042E.659C716D@nisser.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <3A6B042E.659C716D@nisser.com> X-Warning: Incoming message from The Big Giant Head! X-OS: Linux 2.2.13 i686 X-Uptime: 9:36am up 24 days, 20:56, 3 users, load average: 1.24, 0.72, 0.29 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 04:45:50PM +0100, Roelof Osinga wrote: > Grand gesture. Laudable even. Yeah, that PAM sure seems to've > become popular. The Courier IMAP port also insisted upon its > installation. Insisted in that fiddling with the makefile only > resulted in failure to configure. But that's a whole different > story. Would it be a good idea to start using /etc/pam.d ala RedHat, instead of the monolithic /etc/pam.conf? As far as I can see the support is already there, it's just not being used due to the presence of the /etc/pam.conf. This would make installing PAM entries far easier for the ports. -Dom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 1:55:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpout.ev1.net (smtpout.ev1.net [207.218.192.19]) by hub.freebsd.org (Postfix) with ESMTP id 6C64C37B400 for ; Mon, 22 Jan 2001 01:55:01 -0800 (PST) Received: from max [207.218.204.137] by smtpout.ev1.net (SMTPD32-6.05) id A36B93A000EC; Mon, 22 Jan 2001 03:54:51 -0600 Reply-To: From: "Steve Shoecraft" To: , "'Nicolas Souchu'" Cc: Subject: RE: more info about: odd result of pci_read_config Date: Mon, 22 Jan 2001 04:00:48 -0600 Message-ID: <001201c0845a$33089f20$89ccdacf@max.home.org> 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 8.5, Build 4.71.2173.0 In-Reply-To: <20010120192739.A2127@cae88-102-101.sc.rr.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nic - 0x6 is the return value from the error_method routine. > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Donald > J . Maddox > Sent: Saturday, January 20, 2001 6:28 PM > To: Nicolas Souchu > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: more info about: odd result of pci_read_config > > > Heh, this is pretty wierd :) > > I was intrigued by your little problem, so I started looking around. > In sys/dev/pci/pciar.h is: > > static __inline u_int32_t > pci_read_config(device_t dev, int reg, int width) > { > return PCI_READ_CONFIG(device_get_parent(dev), dev, reg, width); > } > > However, this is the only occurence of the string "PCI_READ_CONFIG" > that I can find in the whole damn source tree! Where is this defined? > > > On Sun, Jan 21, 2001 at 12:43:49AM +0100, Nicolas Souchu wrote: > > On Sat, Jan 20, 2001 at 04:18:35PM +0100, Nicolas Souchu wrote: > > > Hi folks, > > > > > > I have a problem with R4.2. The device driver I'm currently > > > writing can't retrieve correctly the value from a PCI > configuration > > > register. What is strange is that when using the pciconf > tool I get > > > the result I expect, not with pci_read_config(). > > > > > > pciconf -r pci0:7:3: 0x48 returns 0x00006001 > > > > > > but > > > > > > value = pci_read_config(dev, 0x48, 4); returns 0x6 !!! > > > > > > > Here is some more testing: > > > > Reading any configuration register gives 0x6! > > > > But > > > > when creating a cfg structure with bus=0, slot=7 and func=3 in the > > attach routine then pass it to pci_cfgread(), it works. Also, when > > querying the pci bus with BUS_READ_IVAR() for BUS, SLOT and FUNC, > > I get 0,7,3. > > > > What is the hose field? > > > > Note also that I had to return NULL on the detection of the device > > 0x30401106 in pcisupport.c pcib_match() because it has a > bridge class and the > > pcib driver was attached to it before viapm. > > > > Here is the piece of code: > > > > static int > > viapm_attach(device_t dev) > > { > > u_int32_t l, base_cfgreg; > > u_int16_t s; > > u_int8_t c; > > struct viapm_data *viapm; > > struct resource *res; > > device_t bitbang; > > pcicfgregs cfg; > > > > if (!(viapm = (struct viapm_data *)device_get_softc(dev))) > > return ENXIO; > > > > bzero(viapm, sizeof(struct viapm_data)); > > > > l = pci_read_config(dev, 0x8, 1); > > printf("%s: rev id 0x%x\n", __FUNCTION__, l); > > > > ## returns 0x6! Which is stupid > > > > switch (l) { > > case VIAPM_OEM_REV_E: > > base_cfgreg = VIAPM_CFG_3040E_BASE; > > > > /* Activate IO block access */ > > s = pci_read_config(dev, VIAPM_CFG_3040E_ACTIV, 2); > > pci_write_config(dev, VIAPM_CFG_3040F_ACTIV, > > s | VIAPM_ACTIV_E_MASK, 2); > > break; > > case VIAPM_OEM_REV_F: > > case VIAPM_PROD_REV_A: > > default: > > base_cfgreg = VIAPM_CFG_3040F_BASE; > > > > /* Activate IO block access */ > > c = pci_read_config(dev, VIAPM_CFG_3040F_ACTIV, 1); > > pci_write_config(dev, VIAPM_CFG_3040F_ACTIV, > > c | VIAPM_ACTIV_F_MASK, 1); > > break; > > } > > > > cfg.hose = -1; > > cfg.bus = 0; > > cfg.slot = 7; > > cfg.func = 3; > > l = pci_cfgread(&cfg, VIAPM_CFG_3040F_BASE, 4); > > printf("%s: base addr 0x%x\n", __FUNCTION__, l); > > > > ## return 0x6001! the correct value > > > > BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_BUS, &l); > > printf("bus=%d\n", l); > > BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_SLOT, &l); > > printf("slot=%d\n", l); > > BUS_READ_IVAR(device_get_parent(dev), dev, > PCI_IVAR_FUNCTION, &l); > > printf("func=%d\n", l); > > > > ## return 0,7,3 > > > > if (!(res = bus_alloc_resource(dev, SYS_RES_IOPORT, > &base_cfgreg, > > 0l, ~0l, 1, RF_ACTIVE))) { > > device_printf(dev, "could not allocate bus space\n"); > > return ENXIO; > > } > > viapm->st = rman_get_bustag(res); > > viapm->sh = rman_get_bushandle(res); > > > > printf("viapm: 0x%x and 0x%x\n", viapm->st, viapm->sh); > > > > VIAPM_OUTB(GPIO_DIR, VIAPM_INB(GPIO_DIR) | VIAPM_SCL | > VIAPM_SDA); > > > > device_printf(dev, "attaching bitbanging...\n"); > > > > /* add generic bit-banging code */ > > if (!(bitbang = device_add_child(dev, "iicbb", -1))) > > return ENXIO; > > > > return (device_probe_and_attach(bitbang)); > > } > > > > -- > > Nicolas.Souchu@alcove.fr > > Alcôve - Open Source Software Engineer - http://www.alcove.fr > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > 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 Jan 22 1:59:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp3.ev1.net (smtpout.ev1.net [207.218.192.47]) by hub.freebsd.org (Postfix) with ESMTP id 9108837B400; Mon, 22 Jan 2001 01:59:20 -0800 (PST) Received: from max [207.218.204.137] by smtp3.ev1.net (SMTPD32-6.05) id A48499C90110; Mon, 22 Jan 2001 03:59:32 -0600 Reply-To: From: "Steve Shoecraft" To: "'Nicolas Souchu'" , "'John Baldwin'" Cc: "'Donald J . Maddox'" , Subject: RE: more info about: odd result of pci_read_config Date: Mon, 22 Jan 2001 04:05:31 -0600 Message-ID: <001301c0845a$db047780$89ccdacf@max.home.org> 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 8.5, Build 4.71.2173.0 In-Reply-To: <20010121111903.B10148@ontario.alcove-int> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Nicolas Souchu > Sent: Sunday, January 21, 2001 4:19 AM > To: John Baldwin > Cc: Donald J . Maddox; freebsd-hackers@FreeBSD.org > Subject: Re: more info about: odd result of pci_read_config > > > On Sat, Jan 20, 2001 at 04:35:11PM -0800, John Baldwin wrote: > > Look in /sys/compile/ after compiling a kernel, it > should be in pci_if.* > > It's a function that ues kobj to lookup the pci_read_config > method in the > > parent bus. Look in the PCI code to find the real > pci_read_config... > > > > >From sys/dev/pci/pci.c: > > > > DEVMETHOD(pci_read_config, pci_read_config_method), > > > > static u_int32_t > > pci_read_config_method(device_t dev, device_t child, int > reg, int width) > > { > > struct pci_devinfo *dinfo = device_get_ivars(child); > > pcicfgregs *cfg = &dinfo->cfg; > > > > return PCIB_READ_CONFIG(device_get_parent(dev), > > cfg->bus, cfg->slot, cfg->func, > > reg, width); > > } > > On -stable, it calls directly pci_cfgread() with the cfg. > > My viapm driver is a kmodule. Could it be that PCI_READ_CONFIG is not > correctly resolved and returns ENXIO which is 0x6? That's exactly whats going on here. Have you turned on BUS_DEBUG (or mebbe DEBUG_BUS) in /kern/subr_bus.c ? Also, I have a userland app that loads and runs your kernel module - it makes it alot easier to debug this kinda stuff. Even does device file I/O. If you want, you can check it out. > > I'll try to wire it in the kernel. > > Nicholas > > -- > Nicolas.Souchu@alcove.fr > Alcôve - Open Source Software Engineer - http://www.alcove.fr > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 2: 7:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by hub.freebsd.org (Postfix) with ESMTP id 4F7F137B404; Mon, 22 Jan 2001 02:07:12 -0800 (PST) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.11.1/8.11.1) id f0MA6x970885; Mon, 22 Jan 2001 11:06:59 +0100 (CET) (envelope-from stijn) Date: Mon, 22 Jan 2001 11:06:59 +0100 From: Stijn Hoop To: Dominic Mitchell Cc: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PAM (was: Re: MAIL set by whom?) Message-ID: <20010122110659.F70055@pcwin002.win.tue.nl> References: <3A6A50F3.307C9E06@nisser.com> <20010121103324.A297@frolic.no-support.loc> <3A6B042E.659C716D@nisser.com> <20010122094647.A7853@semantico.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122094647.A7853@semantico.com>; from dom@semantico.com on Mon, Jan 22, 2001 at 09:46:47AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 09:46:47AM +0000, Dominic Mitchell wrote: > Would it be a good idea to start using /etc/pam.d ala RedHat, instead of > the monolithic /etc/pam.conf? > > As far as I can see the support is already there, it's just not being > used due to the presence of the /etc/pam.conf. > > This would make installing PAM entries far easier for the ports. Seconded. I don't see any reason *not* to do it this way. OTOH, ports are not supposed to install in /etc, so the best way would be to extend pam to support /usr/local/etc/pam.d *and* /etc/pam.d (if it doesn't already do this). No, I'm not sending patches, sorry :) --Stijn -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 2:39:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailsweeper.qdc-ec.co.za (gauntlet.mccarthy.co.za [196.26.24.1]) by hub.freebsd.org (Postfix) with ESMTP id E5C0637B402; Mon, 22 Jan 2001 02:39:14 -0800 (PST) Received: from ntzn2.rainbow.co.za (unverified) by mailsweeper.qdc-ec.co.za (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 22 Jan 2001 12:35:28 +0200 Received: by ntzn2-ip2.rainbow.co.za with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 12:31:45 +0200 Message-ID: From: "Niekie Myburgh (QData)" To: 'Stijn Hoop' Cc: "'freebsd-stable@freebsd.org'" , "'freebsd-hackers@freebsd.org'" Subject: RE: PAM (was: Re: MAIL set by whom?) Date: Mon, 22 Jan 2001 12:35:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0845F.1A079D00" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0845F.1A079D00 Content-Type: text/plain I posted a question about PAM & Passwd on 4.2. It seems that passwd "ignores" any passwd lines in pam.conf. I tried the pam.d thing (Run Linux compatibility, copy rc.d/* from Redhat 6.1 to BSD. When you try to log in, the login terminates, and syslog shows: /kernel: pid 22202 (login), uid 0: exited on siglan 10 (core dumped) Rename pam.d, and all is happy (which means I'm back to pam.conf). I have 300Mb swap (all unused) and 26Mb RAM inactive. I don't think that memory / out of swap space is the problem in this case. (I gather from what I could see on the net, that the main culprit for signal 10 seems to be swap space / memory) Can anyone give me an example line for the passwd entry in pam.conf (seems to be happier, although it seems to ignore my changes) I'm using the following: passwd password required pam_xxxxxxx options_options...... I tried pam_cracklib.so with it's options, as well as pam_passwdqc and it's options. I am being ignored. Regards. Niekie > -----Original Message----- > From: Stijn Hoop [SMTP:stijn@win.tue.nl] > Sent: Monday, January 22, 2001 12:07 PM > To: Dominic Mitchell > Cc: freebsd-stable@freebsd.org; freebsd-hackers@freebsd.org > Subject: Re: PAM (was: Re: MAIL set by whom?) > > On Mon, Jan 22, 2001 at 09:46:47AM +0000, Dominic Mitchell wrote: > > Would it be a good idea to start using /etc/pam.d ala RedHat, instead of > > the monolithic /etc/pam.conf? > > > > As far as I can see the support is already there, it's just not being > > used due to the presence of the /etc/pam.conf. > > > > This would make installing PAM entries far easier for the ports. > > Seconded. I don't see any reason *not* to do it this way. > > OTOH, ports are not supposed to install in /etc, so the best way would > be to extend pam to support /usr/local/etc/pam.d *and* /etc/pam.d > (if it doesn't already do this). > > No, I'm not sending patches, sorry :) > > --Stijn > > -- > Nostalgia ain't what it used to be. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message ------_=_NextPart_001_01C0845F.1A079D00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: PAM (was: Re: MAIL set by whom?)

I posted a question = about PAM & Passwd on 4.2.  It seems that passwd = "ignores" any passwd lines in pam.conf.  I tried the = pam.d thing (Run Linux compatibility, copy rc.d/* from Redhat 6.1 to = BSD.  When you try to log in, the login terminates, and syslog = shows:

/kernel: pid 22202 = (login), uid 0: exited on siglan 10 (core dumped)

Rename pam.d, and = all is happy (which means I'm back to pam.conf).

I have 300Mb swap = (all unused) and 26Mb RAM inactive.  I don't think that memory / = out of swap space is the problem in this case. (I gather from what I = could see on the net, that the main culprit for signal 10 seems to be = swap space / memory)

Can anyone give me = an example line for the passwd entry in pam.conf (seems to be happier, = although it seems to ignore my changes)

I'm using the = following:

passwd  =         = password        = required        =         pam_xxxxxxx = options_options......

I tried = pam_cracklib.so with it's options, as well as pam_passwdqc and it's = options.  I am being ignored.

Regards.

Niekie





    -----Original Message-----
    From:   Stijn Hoop [SMTP:stijn@win.tue.nl]
    Sent:   Monday, January 22, 2001 12:07 PM
    To:     Dominic Mitchell
    Cc:     freebsd-stable@freebsd.org; = freebsd-hackers@freebsd.org
    Subject:       = Re: PAM (was: Re: MAIL set by = whom?)

    On Mon, Jan 22, 2001 at 09:46:47AM = +0000, Dominic Mitchell wrote:
    > Would it be a good idea to start = using /etc/pam.d ala RedHat, instead of
    > the monolithic = /etc/pam.conf?
    >
    > As far as I can see the support = is already there, it's just not being
    > used due to the presence of the = /etc/pam.conf.
    >
    > This would make installing PAM = entries far easier for the ports.

    Seconded. I don't see any reason *not* = to do it this way.

    OTOH, ports are not supposed to = install in /etc, so the best way would
    be to extend pam to support = /usr/local/etc/pam.d *and* /etc/pam.d
    (if it doesn't already do = this).

    No, I'm not sending patches, sorry = :)

    --Stijn

    --
    Nostalgia ain't what it used to = be.


    To Unsubscribe: send mail to = majordomo@FreeBSD.org
    with "unsubscribe = freebsd-hackers" in the body of the message

------_=_NextPart_001_01C0845F.1A079D00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 3: 4: 5 2001 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 B60DF37B400 for ; Mon, 22 Jan 2001 03:03:45 -0800 (PST) Received: from newsguy.com (p08-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.137]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id UAA25651 for ; Mon, 22 Jan 2001 20:03:43 +0900 (JST) Message-ID: <3A6C12FB.8DDF9C6C@newsguy.com> Date: Mon, 22 Jan 2001 20:01: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: hackers@freebsd.org Subject: PPPoE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems I need the following parameters to get my PPPoE to work. Could we have these options, please? >> -f disc:sess >> The -f option sets the Ethernet frame types for >> PPPoE discovery and session frames. The types are >> specified as hexadecimal numbers separated by a >> colon. Standard PPPoE uses frame types 8863:8864. >> You should not use this option unless you are abso=A1 >> lutely sure the peer you are dealing with uses non- >> standard frame types. If your ISP uses non-stan=A1 >> dard frame types, complain! >> >> -S service_name >> Specifies the desired service name. pppoe will >> only initiate sessions with access concentrators >> which can provide the specified service. In most >> cases, you should not specify this option. Use it >> only if you know that there are multiple access >> concentrators or know that you need a specific ser=A1 >> vice name. -- = Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 5:26:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id 8B17737B400 for ; Mon, 22 Jan 2001 05:25:59 -0800 (PST) Received: from HSE-QCity-ppp94185.qc.sympatico.ca ([64.230.224.150]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010122132558.EGMF27935.tomts5-srv.bellnexxia.net@HSE-QCity-ppp94185.qc.sympatico.ca>; Mon, 22 Jan 2001 08:25:58 -0500 Date: Mon, 22 Jan 2001 08:30:03 -0500 (EST) From: Felix-Antoine Paradis To: "Daniel C. Sobral" Cc: Subject: Re: PPPoE In-Reply-To: <3A6C12FB.8DDF9C6C@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To get pppoe to work, just set the options in the kernel and use a good config (ppp.conf) and use pppd. On Mon, 22 Jan 2001, Daniel C. Sobral wrote: > It seems I need the following parameters to get my PPPoE to work. Could > we have these options, please? > > >> -f disc:sess > >> The -f option sets the Ethernet frame types for > >> PPPoE discovery and session frames. The types are > >> specified as hexadecimal numbers separated by a > >> colon. Standard PPPoE uses frame types 8863:8864. > >> You should not use this option unless you are abso=A1 > >> lutely sure the peer you are dealing with uses non- > >> standard frame types. If your ISP uses non-stan=A1 > >> dard frame types, complain! > >> > >> -S service_name > >> Specifies the desired service name. pppoe will > >> only initiate sessions with access concentrators > >> which can provide the specified service. In most > >> cases, you should not specify this option. Use it > >> only if you know that there are multiple access > >> concentrators or know that you need a specific ser=A1 > >> vice name. > > -- > Daniel C. Sobral=09=09=09(8-DCS) > dcs@newsguy.com > dcs@freebsd.org > capo@a.crazy.bsdconspiracy.net > > =09=09"There is no spoon." -- Kiki > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > =2E . . . . . . . . . . . . . . . . . . . . . . . . . . . . =2E Felix-Antoine Paradis . cell: 1-418-261-0865 . =2E IRC: reel @ DALnet . job: Idemnia Network . =2E Email: reel@sympatico.ca . *** www.FreeBSD.org *** . =2E . . . . . . . . . . . . . . . . . . . . . . . . . . . . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 5:37:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from star.rila.bg (star.rila.bg [212.39.75.32]) by hub.freebsd.org (Postfix) with ESMTP id 4902F37B400 for ; Mon, 22 Jan 2001 05:36:52 -0800 (PST) Received: from star.rila.bg (vlady@localhost [127.0.0.1]) by star.rila.bg (8.9.3/8.9.3) with ESMTP id PAA50188 for ; Mon, 22 Jan 2001 15:36:41 +0200 (EET) (envelope-from vlady@star.rila.bg) Message-Id: <200101221336.PAA50188@star.rila.bg> X-Mailer: exmh version 2.1.1 10/15/1999 To: freebsd-hackers@FreeBSD.ORG From: "Vladimir Terziev" Subject: Sablotron - 0.5 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 15:36:41 +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Hackers, I've tryed to install Sablotron XSLT Processor version 0.5 (the latest one), but the configure script said to me that there is no "wchar.h" file on my machine. I checked this and it is true. Can somebody tell me, what is the reason for this? regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 6:54:11 2001 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 8A7FB37B402 for ; Mon, 22 Jan 2001 06:53:51 -0800 (PST) Received: from newsguy.com (p33-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.98]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id XAA17139; Mon, 22 Jan 2001 23:53:42 +0900 (JST) Message-ID: <3A6C48E3.493F5161@newsguy.com> Date: Mon, 22 Jan 2001 23:51: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: Felix-Antoine Paradis Cc: hackers@FreeBSD.ORG Subject: Re: PPPoE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Felix-Antoine Paradis wrote: > > To get pppoe to work, just set the options in the kernel and use a good > config (ppp.conf) and use pppd. Kernel options are bad for a number of reasons, not the least of them the inability to do network installs (I mean, you have ADSL and get restricted to cd installs?). Anyway... what _are_ the kernel options? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 6:59:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.bna.bellsouth.net (mail2.bna.bellsouth.net [205.152.150.14]) by hub.freebsd.org (Postfix) with ESMTP id 506D537B401 for ; Mon, 22 Jan 2001 06:59:42 -0800 (PST) Received: from planetwe.com (adsl-20-109-209.bna.bellsouth.net [66.20.109.209]) by mail2.bna.bellsouth.net (3.3.5alt/0.75.2) with ESMTP id JAA26379; Mon, 22 Jan 2001 09:59:33 -0500 (EST) Message-ID: <3A6C4B09.3010301@planetwe.com> Date: Mon, 22 Jan 2001 09:00:25 -0600 From: Drew Sanford User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12 i386; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Felix-Antoine Paradis , hackers@FreeBSD.ORG Subject: Re: PPPoE References: <3A6C48E3.493F5161@newsguy.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It's been a while since I set up PPPoE on my box here, but if memory serves, the handbook covers it very well - I believe it calls for the addition of: options netgraph options netgraph_pppoe options netgraph_socket But you might actually check the handbook for that. Daniel C. Sobral wrote: > Felix-Antoine Paradis wrote: > >> To get pppoe to work, just set the options in the kernel and use a good >> config (ppp.conf) and use pppd. > > > Kernel options are bad for a number of reasons, not the least of them > the inability to do network installs (I mean, you have ADSL and get > restricted to cd installs?). Anyway... what _are_ the kernel options? -- Drew Sanford Systems Administrator drew@planetwe.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 7:10:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id 8E8A237B401 for ; Mon, 22 Jan 2001 07:10:27 -0800 (PST) Received: from thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) by thehousleys.net (8.11.1/8.11.1) with ESMTP id f0MFAF729230; Mon, 22 Jan 2001 10:10:15 -0500 (EST) (envelope-from jim@thehousleys.net) Message-ID: <3A6C4D57.19B1EBC2@thehousleys.net> Date: Mon, 22 Jan 2001 10:10:15 -0500 From: James Housley X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Drew Sanford Cc: "Daniel C. Sobral" , Felix-Antoine Paradis , hackers@FreeBSD.ORG Subject: Re: PPPoE References: <3A6C48E3.493F5161@newsguy.com> <3A6C4B09.3010301@planetwe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Drew Sanford wrote: > > It's been a while since I set up PPPoE on my box here, but if memory > serves, the handbook covers it very well - I believe it calls for the > addition of: > > options netgraph > options netgraph_pppoe > options netgraph_socket > Yes and all of these can be loaded at runtime as KLDs Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net --------------------------------------------------------------------- If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's windows. -- Luiz de Barros To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 7:12:40 2001 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 A855C37B402 for ; Mon, 22 Jan 2001 07:12:22 -0800 (PST) Received: from newsguy.com (p33-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.98]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA24735; Tue, 23 Jan 2001 00:12:11 +0900 (JST) Message-ID: <3A6C4D39.80CBC9CE@newsguy.com> Date: Tue, 23 Jan 2001 00:09:45 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Drew Sanford Cc: Felix-Antoine Paradis , hackers@FreeBSD.ORG Subject: Re: PPPoE References: <3A6C48E3.493F5161@newsguy.com> <3A6C4B09.3010301@planetwe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Drew Sanford wrote: > > It's been a while since I set up PPPoE on my box here, but if memory > serves, the handbook covers it very well - I believe it calls for the > addition of: > > options netgraph > options netgraph_pppoe > options netgraph_socket > > But you might actually check the handbook for that. The default frame type won't work. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 8:48:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 5FD4837B402; Mon, 22 Jan 2001 08:48:38 -0800 (PST) Received: from nsouch by smtp.alcove.fr with local (Exim 3.12 #1 (Debian)) id 14Kk8l-000870-00; Mon, 22 Jan 2001 17:48:23 +0100 Date: Mon, 22 Jan 2001 17:48:23 +0100 From: Nicolas Souchu To: Steve Shoecraft Cc: 'John Baldwin' , "'Donald J . Maddox'" , freebsd-hackers@FreeBSD.org Subject: Re: more info about: odd result of pci_read_config Message-ID: <20010122174822.D30873@ontario.alcove-int> References: <20010121111903.B10148@ontario.alcove-int> <001301c0845a$db047780$89ccdacf@max.home.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <001301c0845a$db047780$89ccdacf@max.home.org>; from sshoecraft@safepages.com on Mon, Jan 22, 2001 at 04:05:31AM -0600 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 04:05:31AM -0600, Steve Shoecraft wrote: > > My viapm driver is a kmodule. Could it be that PCI_READ_CONFIG is not > > correctly resolved and returns ENXIO which is 0x6? > > That's exactly whats going on here. Have you turned on BUS_DEBUG (or mebbe > DEBUG_BUS) in /kern/subr_bus.c ? Not yet. I will then. > > Also, I have a userland app that loads and runs your kernel module - it > makes it alot easier to debug this kinda stuff. Even does device file I/O. > If you want, you can check it out. Thanks, where? -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 9: 1:43 2001 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 9BE6A37B69B; Mon, 22 Jan 2001 09:01:23 -0800 (PST) Received: from portonovo-27.budapest.interware.hu ([195.70.60.91] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14KkL1-0003u3-00; Mon, 22 Jan 2001 18:01:07 +0100 Message-ID: <3A6C654C.F14FA457@elischer.org> Date: Mon, 22 Jan 2001 08:52:28 -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: Felix-Antoine Paradis Cc: "Daniel C. Sobral" , hackers@FreeBSD.ORG, brian@freebsd.org Subject: Re: PPPoE References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Felix-Antoine Paradis wrote: > > To get pppoe to work, just set the options in the kernel and use a good > config (ppp.conf) and use pppd. > > On Mon, 22 Jan 2001, Daniel C. Sobral wrote: > > > It seems I need the following parameters to get my PPPoE to work. Could > > we have these options, please? > > > > >> -f disc:sess > > >> The -f option sets the Ethernet frame types for > > >> PPPoE discovery and session frames. The types are > > >> specified as hexadecimal numbers separated by a > > >> colon. Standard PPPoE uses frame types 8863:8864. > > >> You should not use this option unless you are abso¡ > > >> lutely sure the peer you are dealing with uses non- > > >> standard frame types. If your ISP uses non-stan¡ > > >> dard frame types, complain! Definitly complain! This is equivalent to calling a protocol tcp/ip but using a first byte in the packet. I will look at a configuration message for the netgraph node but Brian will hav eto work out how to send it, and where the configuration parameter should be set to do this.. The other possibility is a sysctl. > > >> -S service_name > > >> Specifies the desired service name. pppoe will > > >> only initiate sessions with access concentrators > > >> which can provide the specified service. In most > > >> cases, you should not specify this option. Use it > > >> only if you know that there are multiple access > > >> concentrators or know that you need a specific ser¡ > > >> vice name. If you are talking about the netgraph based pppoe, then -xxx type flags are not how you configure it. I think you are talking about the (rather inefficient) userland ppp daemon. the service name requested is already an argument in the pppoe configuration. "If a PPPoE:iface[:provider] specification is given, ppp will at- tempt to create a PPP over Ethernet connection using the given iface interface by using netgraph(4). " In this case the "provider" is the service name. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, 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 Mon Jan 22 9: 3:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id C7D2537B69D for ; Mon, 22 Jan 2001 09:01:30 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id LAA11112 for freebsd-hackers@FreeBSD.ORG; Mon, 22 Jan 2001 11:06:42 -0600 (CST) Date: Mon, 22 Jan 2001 11:06:42 -0600 From: Robert Lipe To: freebsd-hackers@FreeBSD.ORG Subject: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122110642.B10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Gang. I know that anytime a message starts with a subject like this, the first reaction is to think that I've hosed the heap or am not freeing something. While it's possible, I really don't think I have. (I also know that everyone thinks that. :-) I'm on FreeBSD 4.1.1. I've not seen any flagrantly smoking guns since then in vm_page.c, although version 1.154 might be... I'm calling contigmalloc() with M_WAITOK. For every contigmalloc, I have a corresponding contigfree(). But after a few thousand cycles, contigmalloc() starts returning NULL. It self-destructs in about 3 minutes. I see the same behaviour with M_NOWAIT. As an aside, WAITOK's should never return NULL, right? They should be put to sleep and awakened when the resource is available. So I'm suspecting there are two problems (they may be problems in my understanding and not the code): One is that we leak something that makes it fail. The other is that M_WAITOK isn't honoured when it does fail. Fortunately, the allocations in question for my test have really simple constraints. I know that it's *really* calling contigmalloc with single byte alignment that can be located anywhere in 32-bit address space and I'm on a 32-bit host. If I replace contigmalloc/contigfree with malloc/free it runs fine for hours. Since all I did was replace the single call site of each, I really don't think I'm leaking it. While this is a cute special case (and presumably a potential optimization), it's also not typical of real hardware in real systems that have to have real constraints passed to contigmalloc. Looking at the callers of contigmalloc/contigfree in the tree, I don't see a lot of highly dynamic uses of them. For the most part, drivers are making a low number of calls at attachment time and a low number of releases at detachment time. Thus, it's possible that a problem here could have gone unnoticed. Any ideas? Is there something magic to contig management? Do I have to hold an elevated PL during calls to these to prevent corruption? Thanx, RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 9:45:53 2001 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 A956A37B698; Mon, 22 Jan 2001 09:45:30 -0800 (PST) Received: from newsguy.com (p33-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.98]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id CAA27607; Tue, 23 Jan 2001 02:45:08 +0900 (JST) Message-ID: <3A6C7111.80E5663F@newsguy.com> Date: Tue, 23 Jan 2001 02:42:41 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Dominic Mitchell Cc: Roelof Osinga , Bjoern Fischer , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: PAM (was: Re: MAIL set by whom?) References: <3A6A50F3.307C9E06@nisser.com> <20010121103324.A297@frolic.no-support.loc> <3A6B042E.659C716D@nisser.com> <20010122094647.A7853@semantico.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dominic Mitchell wrote: > > On Sun, Jan 21, 2001 at 04:45:50PM +0100, Roelof Osinga wrote: > > Grand gesture. Laudable even. Yeah, that PAM sure seems to've > > become popular. The Courier IMAP port also insisted upon its > > installation. Insisted in that fiddling with the makefile only > > resulted in failure to configure. But that's a whole different > > story. > > Would it be a good idea to start using /etc/pam.d ala RedHat, instead of > the monolithic /etc/pam.conf? > > As far as I can see the support is already there, it's just not being > used due to the presence of the /etc/pam.conf. > > This would make installing PAM entries far easier for the ports. Ports shouldn't touch /etc. Does the existance of /etc/pam.conf precludes /usr/local/etc/pam.d from working? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 10: 5:49 2001 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 8442E37B400 for ; Mon, 22 Jan 2001 10:05:26 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0MI5Pd24288; Mon, 22 Jan 2001 10:05:25 -0800 (PST) Date: Mon, 22 Jan 2001 10:05:24 -0800 From: Alfred Perlstein To: Robert Lipe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122100524.D7240@fw.wintelcom.net> References: <20010122110642.B10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122110642.B10504@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Jan 22, 2001 at 11:06:42AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Robert Lipe [010122 09:04] wrote: > Hi, Gang. > > I know that anytime a message starts with a subject like this, the > first reaction is to think that I've hosed the heap or am not freeing > something. While it's possible, I really don't think I have. (I also > know that everyone thinks that. :-) > > I'm on FreeBSD 4.1.1. I've not seen any flagrantly smoking guns since > then in vm_page.c, although version 1.154 might be... > > I'm calling contigmalloc() with M_WAITOK. For every contigmalloc, I > have a corresponding contigfree(). But after a few thousand cycles, > contigmalloc() starts returning NULL. It self-destructs in about 3 > minutes. I see the same behaviour with M_NOWAIT. As an aside, WAITOK's > should never return NULL, right? They should be put to sleep and > awakened when the resource is available. Making heavy use of contigmalloc is a bad idea, if you really need this contig allocations then allocate a fair number of them early and keep using them. Memory get's fragmented, there's not much you can do about it. I doubt that contigmalloc respects the WAITOK flag, there's a good chance that kernel memory has become so fragmented that your chances of successfully completing the contigmalloc are near zero, it's much better to return a temporary resource failure than block a kernel thread forever. This issue has come up before, and most everyone was able to either use a workaround (calling VTOPHYS? on each page) or pre-allocating the contig space and reuseing it instead of allocating and freeing it over and over. best of luck, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 10: 7:55 2001 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 A7BB137B400; Mon, 22 Jan 2001 10:07:30 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 1C3C4193E4; Mon, 22 Jan 2001 12:07:30 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id f0MI7UL93735; Mon, 22 Jan 2001 12:07:30 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Mon, 22 Jan 2001 12:07:30 -0600 From: "Jacques A. Vidrine" To: "Daniel C. Sobral" Cc: Dominic Mitchell , Roelof Osinga , Bjoern Fischer , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: PAM (was: Re: MAIL set by whom?) Message-ID: <20010122120729.B93660@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , "Daniel C. Sobral" , Dominic Mitchell , Roelof Osinga , Bjoern Fischer , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG References: <3A6A50F3.307C9E06@nisser.com> <20010121103324.A297@frolic.no-support.loc> <3A6B042E.659C716D@nisser.com> <20010122094647.A7853@semantico.com> <3A6C7111.80E5663F@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6C7111.80E5663F@newsguy.com>; from dcs@newsguy.com on Tue, Jan 23, 2001 at 02:42:41AM +0900 X-Url: http://www.nectar.com/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 02:42:41AM +0900, Daniel C. Sobral wrote: > Ports shouldn't touch /etc. > > Does the existance of /etc/pam.conf precludes /usr/local/etc/pam.d from > working? Other way around. From the man page (the last sentence is even underlined :-) Alternatively, the configuration can be set by individual configuration files located in the /etc/pam.d/ directory. The presence of this directory will cause PAM to ignore /etc/pam.conf. -- 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 Mon Jan 22 10:40:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 68C7837B401 for ; Mon, 22 Jan 2001 10:39:58 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id MAA11587; Mon, 22 Jan 2001 12:45:39 -0600 (CST) Date: Mon, 22 Jan 2001 12:45:39 -0600 From: Robert Lipe To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122124539.F10504@rjlhome.sco.com> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@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: <20010122100524.D7240@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jan 22, 2001 at 10:05:24AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Robert Lipe [010122 09:04] wrote: > > I'm calling contigmalloc() with M_WAITOK. For every contigmalloc, I > > have a corresponding contigfree(). But after a few thousand cycles, > > contigmalloc() starts returning NULL. It self-destructs in about 3 > > Making heavy use of contigmalloc is a bad idea, if you really need > this contig allocations then allocate a fair number of them early > and keep using them. I understand that and in a production system, these would indeed be cached. > Memory get's fragmented, there's not much you can do about it. I > doubt that contigmalloc respects the WAITOK flag, there's a good > chance that kernel memory has become so fragmented that your chances > of successfully completing the contigmalloc are near zero, If I were allocating something truly hard to get (like multiple contiguous pages with page alignment) I'd take that answer and move on. I've even given that answer before. :-) But this example requested *no* specified alignment and at any physaddr. So if there's memory in the system (and there must be or malloc couldn't find it) it should be able to find it, right? > it's much better to return a temporary resource failure than block a > kernel thread forever. In this case, the resource failure isn't temporary. Once it starts failing, it fails until the system is rebooted. Since this is on a dedicated thread, I could handle it if it really was temporary. Of course, putting me to sleep so that someone else (or even another of my own threads) could run around and free the resources would be ideal. As it stands, once I get the failure notice, I'm hosed. > This issue has come up before, and most everyone was able to either > use a workaround (calling VTOPHYS? on each page) Tell me more about this. You can't just replace contigmalloc with a malloc and a vtophys becuase you can't express hardware constraints that way. You can express a common subset of them. So there must be something else you're hinting at. > or pre-allocating the contig space and reuseing it instead of > allocating and freeing it over and over. Yes, I'll have a scheme like that that I'll need to implement for performance but I was hoping to defer that. > best of luck, Thanx much, RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 10:52:46 2001 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 B6B6B37B400 for ; Mon, 22 Jan 2001 10:52:28 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0MIqRM25899; Mon, 22 Jan 2001 10:52:27 -0800 (PST) Date: Mon, 22 Jan 2001 10:52:27 -0800 From: Alfred Perlstein To: Robert Lipe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122105227.E7240@fw.wintelcom.net> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122124539.F10504@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Jan 22, 2001 at 12:45:39PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Robert Lipe [010122 10:39] wrote: > Alfred Perlstein wrote: > > * Robert Lipe [010122 09:04] wrote: > > > Memory get's fragmented, there's not much you can do about it. I > > doubt that contigmalloc respects the WAITOK flag, there's a good > > chance that kernel memory has become so fragmented that your chances > > of successfully completing the contigmalloc are near zero, > > If I were allocating something truly hard to get (like multiple > contiguous pages with page alignment) I'd take that answer and move on. > I've even given that answer before. :-) But this example requested *no* > specified alignment and at any physaddr. So if there's memory in the > system (and there must be or malloc couldn't find it) it should be able > to find it, right? Yes, but it seems like there isn't any. :) > > it's much better to return a temporary resource failure than block a > > kernel thread forever. > > In this case, the resource failure isn't temporary. Once it starts > failing, it fails until the system is rebooted. Since this is on a > dedicated thread, I could handle it if it really was temporary. Of > course, putting me to sleep so that someone else (or even another of my > own threads) could run around and free the resources would be ideal. As > it stands, once I get the failure notice, I'm hosed. Yup, it's sort of the fault of the memory allocator, afaik except for allocations that are > (PAGE_SIZE/2), you can't free back to the kernel map, meaning that if you allocate several thousand < (PAGE_SIZE/2) chunks you've pretty much broken contigmalloc. > > This issue has come up before, and most everyone was able to either > > use a workaround (calling VTOPHYS? on each page) > > Tell me more about this. You can't just replace contigmalloc with a > malloc and a vtophys becuase you can't express hardware constraints > that way. You can express a common subset of them. So there must be > something else you're hinting at. Not hinting much, the only reason I can guess that you need contigmalloc is because you're allocating > PAGE_SIZE chunks and you don't want to tell your hardware to do scatter/gather IO and would rather point it at some physically contig memory and be done with it. This is possible (using contigmalloc) if you cache the contigmalloc'd chunks, but not if you keep discarding them and allow the kernel memory map to become more fragmented. > > or pre-allocating the contig space and reuseing it instead of > > allocating and freeing it over and over. > > Yes, I'll have a scheme like that that I'll need to implement for > performance but I was hoping to defer that. Best to do it now. My question is, why exactly do you need contigmalloc, is this some device you're trying to write a driver for? Can you explain it some? That would help me suggest a workaround. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 11:21:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 8E93937B400 for ; Mon, 22 Jan 2001 11:21:15 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id NAA11912; Mon, 22 Jan 2001 13:26:47 -0600 (CST) Date: Mon, 22 Jan 2001 13:26:47 -0600 From: Robert Lipe To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122132647.I10504@rjlhome.sco.com> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@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: <20010122105227.E7240@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jan 22, 2001 at 10:52:27AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > In this case, the resource failure isn't temporary. Once it starts > > failing, it fails until the system is rebooted. Since this is on a > > dedicated thread, I could handle it if it really was temporary. Of > > course, putting me to sleep so that someone else (or even another of my > > own threads) could run around and free the resources would be ideal. As > > it stands, once I get the failure notice, I'm hosed. > > Yup, it's sort of the fault of the memory allocator, afaik except > for allocations that are > (PAGE_SIZE/2), you can't free back to > the kernel map, meaning that if you allocate several thousand < > (PAGE_SIZE/2) chunks you've pretty much broken contigmalloc. Aaaah. There's a hint. Yes, by the time we get into trouble, I've allocated (and freed) several thousand chunks that are < PAGE_SIZE/2. This is happening in periods of a few dozen. (I don't know the number, but I think it's 48 or 64.) The test program allocates a few dozen tx buffers, fills them up, then the tx completion handler releases them. There are never very many of these outstanding at any time. All the allocs (in this specific case) are always the same size, and there are no intervening calls to contigmalloc. This should stack the deck pretty well for fragmentation. So if I sandbagged the allocs to be *larger* the KMA would behave more consistently with what I'd expect becuase it would then reclaim? I didn't see that one coming. :-) Would rounding them up to PAGE_SIZE/2 suffice, or did you really mean "> PAGE_SIZE/2"? > Not hinting much, the only reason I can guess that you need contigmalloc > is because you're allocating > PAGE_SIZE chunks and you don't want to > tell your hardware to do scatter/gather IO and would rather point it > at some physically contig memory and be done with it. Is there an s/g memory interface in FreeBSD? This was my first choice, but since I couldn't find a set of functions to build a list of buffers that satisfied a set of constraints, I fell back to contigmalloc to get things off the ground. I'd be delighted to use an interface to get me an s/g list with a given set of constraints that pointed to a list of buffers with a given set of constraints. > This is possible (using contigmalloc) if you cache the contigmalloc'd > chunks, but not if you keep discarding them and allow the kernel memory > map to become more fragmented. Implementing a cache for these is a few lines of code and will improve the robustness of what I have. I'm clearly going to have to do this. > My question is, why exactly do you need contigmalloc, is this some > device you're trying to write a driver for? Can you explain it some? > That would help me suggest a workaround. Sure. I'm trying to write a driver for arbitrary devices. :-) This is kinky, I know. UDI (www.projectudi.org) allows a driver writer to specify a very rich set of constraints on DMA objects. I'm implementing the piece of the UDI environment that provides this to the drivers. So while I know that the test program and driver I'm using right now don't *really* need contigmalloc, we'll eventually need the ability to ensure that DMA buffers for 32-bit PCI cards are in the bottom 32 bits, (or perhaps even not the bottom if you have intervening bus bridges) that stupid hardware providing 24 bits of addressing but bolted to a PCI controller gets allocated in the bottom 16Mb, etc. If I was trying to support a very specific piece of hardware, I could divine workarounds, but it's something I'm probably going to have to determine programmatically. Thanx again, RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 12: 9:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id D4DD037B6A6 for ; Mon, 22 Jan 2001 12:09:14 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0MKOU001092; Mon, 22 Jan 2001 12:24:30 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101222024.f0MKOU001092@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Lipe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. In-reply-to: Your message of "Mon, 22 Jan 2001 11:06:42 CST." <20010122110642.B10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 12:24:30 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm calling contigmalloc() with M_WAITOK. For every contigmalloc, I > have a corresponding contigfree(). But after a few thousand cycles, > contigmalloc() starts returning NULL. It self-destructs in about 3 > minutes. I see the same behaviour with M_NOWAIT. As an aside, WAITOK's > should never return NULL, right? They should be put to sleep and > awakened when the resource is available. No, contigmalloc will return NULL if physical memory space is fragmented to the point where it can't honour your request. You should avoid calling contigmalloc at any time other than when setting up your driver; there is no support in the kernel for defragmenting physical address space, so over time you'll run into the problem you're seeing. Allocate your space up front, and then leave it alone. Also, you should probably be using bus_dmamem_alloc() since the only real use for contiguous memory is for DMA purposes, and you'll be better served by allocating DMA'able buffers matching your device's characteristics than by assuming that you can DMA to/from all physical memory. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 12:10:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.speedera.com (unknown [64.242.144.230]) by hub.freebsd.org (Postfix) with ESMTP id 459DB37B6A7 for ; Mon, 22 Jan 2001 12:10:35 -0800 (PST) Received: from salesnb1 (ph-128.speedera.com [10.40.10.128]) by mail.speedera.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DK0VDAKH; Mon, 22 Jan 2001 12:05:39 -0800 Message-ID: <03da01c084b0$e6fe4d30$800a280a@speedera.com> From: "Ras-Sol" To: "Daniel C. Sobral" Cc: References: <3A6C12FB.8DDF9C6C@newsguy.com> Subject: Re: PPPoE Date: Mon, 22 Jan 2001 12:21:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Hmmm, I seem to remember something about another way to do PPPoE... But I've been using ppp's built-in PPPoE support for about a year now. (With Netgraph etc) Simple to set up, works flawlessly. Uses 21% CPU on a 486 DX2-50. -- "Jupiter accepts your offer..." AIM: IMFDUP ----- Original Message ----- From: Daniel C. Sobral To: Sent: Monday, January 22, 2001 3:01 AM Subject: PPPoE It seems I need the following parameters to get my PPPoE to work. Could we have these options, please? >> -f disc:sess >> The -f option sets the Ethernet frame types for >> PPPoE discovery and session frames. The types are >> specified as hexadecimal numbers separated by a >> colon. Standard PPPoE uses frame types 8863:8864. >> You should not use this option unless you are abso¡ >> lutely sure the peer you are dealing with uses non- >> standard frame types. If your ISP uses non-stan¡ >> dard frame types, complain! >> >> -S service_name >> Specifies the desired service name. pppoe will >> only initiate sessions with access concentrators >> which can provide the specified service. In most >> cases, you should not specify this option. Use it >> only if you know that there are multiple access >> concentrators or know that you need a specific ser¡ >> vice name. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki 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 Jan 22 12:10:59 2001 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 E672537B6A6 for ; Mon, 22 Jan 2001 12:10:35 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0MKAXZ28660; Mon, 22 Jan 2001 12:10:33 -0800 (PST) Date: Mon, 22 Jan 2001 12:10:33 -0800 From: Alfred Perlstein To: Robert Lipe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122121033.A26076@fw.wintelcom.net> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122132647.I10504@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Jan 22, 2001 at 01:26:47PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Robert Lipe [010122 11:21] wrote: > > > In this case, the resource failure isn't temporary. Once it starts > > > failing, it fails until the system is rebooted. Since this is on a > > > dedicated thread, I could handle it if it really was temporary. Of > > > course, putting me to sleep so that someone else (or even another of my > > > own threads) could run around and free the resources would be ideal. As > > > it stands, once I get the failure notice, I'm hosed. > > > > Yup, it's sort of the fault of the memory allocator, afaik except > > for allocations that are > (PAGE_SIZE/2), you can't free back to > > the kernel map, meaning that if you allocate several thousand < > > (PAGE_SIZE/2) chunks you've pretty much broken contigmalloc. > > Aaaah. There's a hint. Yes, by the time we get into trouble, I've > allocated (and freed) several thousand chunks that are < PAGE_SIZE/2. > This is happening in periods of a few dozen. (I don't know the number, > but I think it's 48 or 64.) The test program allocates a few dozen tx > buffers, fills them up, then the tx completion handler releases them. > There are never very many of these outstanding at any time. All the > allocs (in this specific case) are always the same size, and there are > no intervening calls to contigmalloc. This should stack the deck pretty > well for fragmentation. > > So if I sandbagged the allocs to be *larger* the KMA would behave more > consistently with what I'd expect becuase it would then reclaim? I > didn't see that one coming. :-) > > Would rounding them up to PAGE_SIZE/2 suffice, or did you really mean "> > PAGE_SIZE/2"? On i386, PAGE_SIZE is 4096, so the allocations need to be 2048+1 :). so it's > PAGE_SIZE/2. but... this is a terrible workaround, I'm not sure it would work and you shouldn't do it. :) > > Not hinting much, the only reason I can guess that you need contigmalloc > > is because you're allocating > PAGE_SIZE chunks and you don't want to > > tell your hardware to do scatter/gather IO and would rather point it > > at some physically contig memory and be done with it. > > Is there an s/g memory interface in FreeBSD? This was my first choice, > but since I couldn't find a set of functions to build a list of buffers > that satisfied a set of constraints, I fell back to contigmalloc to get > things off the ground. I'd be delighted to use an interface to get me > an s/g list with a given set of constraints that pointed to a list of > buffers with a given set of constraints. See the busdma stuff, there's a problem because there's no busdma for mbufs (well actually there is but it fails on really small unaligned blocks which basically breaks it for mbufs). NetBSD has some stuff for setting up s/g on mbufs (more busdma) but it looks pretty inefficient and I havne't had a chance to look at emulating or providing a different interface for it. > > This is possible (using contigmalloc) if you cache the contigmalloc'd > > chunks, but not if you keep discarding them and allow the kernel memory > > map to become more fragmented. > > Implementing a cache for these is a few lines of code and will improve > the robustness of what I have. I'm clearly going to have to do this. There's no way around it if you want to use contigmalloc. However if you were to use busdma you could do it with normal malloc'd blocks. > > My question is, why exactly do you need contigmalloc, is this some > > device you're trying to write a driver for? Can you explain it some? > > That would help me suggest a workaround. > > Sure. I'm trying to write a driver for arbitrary devices. :-) This is > kinky, I know. > > UDI (www.projectudi.org) allows a driver writer to specify a very rich > set of constraints on DMA objects. I'm implementing the piece of the > UDI environment that provides this to the drivers. So while I know > that the test program and driver I'm using right now don't *really* > need contigmalloc, we'll eventually need the ability to ensure that DMA > buffers for 32-bit PCI cards are in the bottom 32 bits, (or perhaps > even not the bottom if you have intervening bus bridges) that stupid > hardware providing 24 bits of addressing but bolted to a PCI controller > gets allocated in the bottom 16Mb, etc. > > If I was trying to support a very specific piece of hardware, I could > divine workarounds, but it's something I'm probably going to have to > determine programmatically. ack, I'd review patches if you wanted to write/port busdma for mbufs.. see: http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/arch/i386/i386/bus_machdep.c for a starting point. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 12:26:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 95C6A37B400 for ; Mon, 22 Jan 2001 12:26:34 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0MKfY001170; Mon, 22 Jan 2001 12:41:34 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101222041.f0MKfY001170@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Lipe Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. In-reply-to: Your message of "Mon, 22 Jan 2001 13:26:47 CST." <20010122132647.I10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 12:41:34 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Aaaah. There's a hint. Yes, by the time we get into trouble, I've > allocated (and freed) several thousand chunks that are < PAGE_SIZE/2. > This is happening in periods of a few dozen. (I don't know the number, > but I think it's 48 or 64.) The test program allocates a few dozen tx > buffers, fills them up, then the tx completion handler releases them. > There are never very many of these outstanding at any time. All the > allocs (in this specific case) are always the same size, and there are > no intervening calls to contigmalloc. This should stack the deck pretty > well for fragmentation. Several things to note. - Calling contigmalloc is wrong. Use bus_dmamem_alloc() - Calling an allocator is generally wrong; keep a freelist and just recycle your buffers. If you're not sure about how many you need, then by all means error out in the "freelist empty" case and allocate a few more (up to some sane limit). > So if I sandbagged the allocs to be *larger* the KMA would behave more > consistently with what I'd expect becuase it would then reclaim? I > didn't see that one coming. :-) No, this isn't going to help much. It's possible that contigfree is actually doing the wrong thing, but regardless, what you're doing is a recipie for frustration. If your allocations are always guaranteed to be much smaller than PAGE_SIZE, making an individual allocation per object is also wasteful (since contigmalloc will have to give you a whole page...). You should definitely be using bus_dmamem_alloc, and allocate a cluster of objects. eg. if your object is (say) 20 bytes in size, you should round up to 32, then allocate (PAGE_SIZE / 32) objects and push them all onto your freelist. (This requires tracking the base addresses of your clusters, but it's much more efficient.) > Is there an s/g memory interface in FreeBSD? This was my first choice, > but since I couldn't find a set of functions to build a list of buffers > that satisfied a set of constraints, I fell back to contigmalloc to get > things off the ground. I'd be delighted to use an interface to get me > an s/g list with a given set of constraints that pointed to a list of > buffers with a given set of constraints. Yes; this is where the busdma stuff comes in. Use bus_dma_tag_create to create a DMA tag which defines the costraints applicable to your DMA-able memory. Then you can either use bus_dmamem_alloc/bus_dmamem_free to allocate conforming memory, or just take memory in the kernel's address space. In either case, you use bus_dmamap_load to build the scatter/ gather list (and possibly perform other setup work), bus_dmamap_unload to tear down any of the setup work, and bus_dmamem_sync to perform possibly-required bounce buffering, bus scatter/gather control, etc. > UDI (www.projectudi.org) allows a driver writer to specify a very rich > set of constraints on DMA objects. I'm implementing the piece of the > UDI environment that provides this to the drivers. So while I know > that the test program and driver I'm using right now don't *really* > need contigmalloc, we'll eventually need the ability to ensure that DMA > buffers for 32-bit PCI cards are in the bottom 32 bits, (or perhaps > even not the bottom if you have intervening bus bridges) that stupid > hardware providing 24 bits of addressing but bolted to a PCI controller > gets allocated in the bottom 16Mb, etc. All this is already provided for with the above. I hope this helps, feel free to ask more questions if you need more answers. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 12:42:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 0D0C337B69C for ; Mon, 22 Jan 2001 12:42:08 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0MKvL001244; Mon, 22 Jan 2001 12:57:21 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101222057.f0MKvL001244@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Lipe Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. In-reply-to: Your message of "Mon, 22 Jan 2001 12:41:34 PST." <200101222041.f0MKfY001170@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 12:57:21 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Is there an s/g memory interface in FreeBSD? This was my first choice, > > but since I couldn't find a set of functions to build a list of buffers > > that satisfied a set of constraints, I fell back to contigmalloc to get > > things off the ground. I'd be delighted to use an interface to get me > > an s/g list with a given set of constraints that pointed to a list of > > buffers with a given set of constraints. > > Yes; this is where the busdma stuff comes in. Use bus_dma_tag_create to > create a DMA tag which defines the costraints applicable to your DMA-able > memory. Then you can either use bus_dmamem_alloc/bus_dmamem_free to > allocate conforming memory, or just take memory in the kernel's address > space. In either case, you use bus_dmamap_load to build the scatter/ > gather list (and possibly perform other setup work), bus_dmamap_unload > to tear down any of the setup work, and bus_dmamem_sync to perform > possibly-required bounce buffering, bus scatter/gather control, etc. Urk. I should avoid replying to messages in the first 20 minutes or so after I wake up; my dreams get confused with reality. With dma-conformant allocated memory: struct buf_cluster { void *vaddr; vm_offset_t paddr; bus_dmamap_t map; } bus_dma_tag_create(parent_tag, ... &tag); bus_dmamem_alloc(tag, &cluster.vaddr, BUS_DMA_NOWAIT, &cluster.map); bus_dmamap_load(tag, cluster.map, cluster.vaddr, cluster_size, cluster_helper_func, &cluster, 0) ... void cluster_helper_func(void *arg, bus_dma_segment_t *segs, int nseg, int error) { struct buf_cluster *cluster = (struct buf_cluster *)arg; cluster->paddr = segs[0].ds_addr; } The above case works if you've specified the tag as giving you a single, unfragmented allocation. If you took a more generous route and allowed it to be fragmented because your structures would never cross a page boundary then you would want to make the helper function more elaborate; the scatter gather list is in the usual base/length format in the segs array, and nsegs of course gives you its length. I hope this helps, there are lots of examples of the use of this interface scattered throughout the tree. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 12:43:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.speedera.com (unknown [64.242.144.230]) by hub.freebsd.org (Postfix) with ESMTP id B0C3137B69E for ; Mon, 22 Jan 2001 12:42:53 -0800 (PST) Received: from salesnb1 (ph-128.speedera.com [10.40.10.128]) by mail.speedera.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DK0VDANR; Mon, 22 Jan 2001 12:38:00 -0800 Message-ID: <054e01c084b5$6c4ee270$800a280a@speedera.com> From: "Ras-Sol" To: "Daniel C. Sobral" , "Felix-Antoine Paradis" Cc: References: <3A6C48E3.493F5161@newsguy.com> Subject: Re: PPPoE Date: Mon, 22 Jan 2001 12:53:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, I believe that the kernel optons are not needed anymore- Or, if you tell PPP to start at bootup in "/etc/defaults/rc.conf" it dynamically loads the netgraph stuff. And btw, does anyone else completely DETEST the "/etc/rc.conf" - "/etc/defaults/rc.conf"? Why can't we just have ONE file, instead of one file, plus an override file? And yah- I set mine up by looking in the handbook, so check there... -- "Jupiter accepts your offer..." AIM: IMFDUP ----- Original Message ----- From: Daniel C. Sobral To: Felix-Antoine Paradis Cc: Sent: Monday, January 22, 2001 6:51 AM Subject: Re: PPPoE > Felix-Antoine Paradis wrote: > > > > To get pppoe to work, just set the options in the kernel and use a good > > config (ppp.conf) and use pppd. > > Kernel options are bad for a number of reasons, not the least of them > the inability to do network installs (I mean, you have ADSL and get > restricted to cd installs?). Anyway... what _are_ the kernel options? > > -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > capo@a.crazy.bsdconspiracy.net > > "There is no spoon." -- Kiki > > > 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 Jan 22 12:50:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id B2A5A37B698 for ; Mon, 22 Jan 2001 12:50:08 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id OAA12347; Mon, 22 Jan 2001 14:55:50 -0600 (CST) Date: Mon, 22 Jan 2001 14:55:50 -0600 From: Robert Lipe To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122145550.O10504@rjlhome.sco.com> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> <20010122121033.A26076@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: <20010122121033.A26076@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jan 22, 2001 at 12:10:33PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > So if I sandbagged the allocs to be *larger* the KMA would behave more > > consistently with what I'd expect becuase it would then reclaim? I > > didn't see that one coming. :-) > > but... this is a terrible workaround, I'm not sure it would work > and you shouldn't do it. :) Good. I didn't actully *want* to do that. I still have to respect myself in the morning. :-) > > Is there an s/g memory interface in FreeBSD? This was my first choice, > > See the busdma stuff, Yes, this looks to be much closer to the interface I really wanted anyway. I see no man pages for them. Is there any doc anywhere? "Read the source and look at existing examples" will do if it must but any pointers to better doc are appreciated. > there's a problem because there's no busdma > for mbufs (well actually there is but it fails on really small > unaligned blocks which basically breaks it for mbufs). Can you tell me more about this hazard? I can't control the alignment that's asked for by the driver, but I can certainly fudge the size and alignment of the request by the time it gets to this interface. Just tell me the rules. :-) > ack, I'd review patches if you wanted to write/port busdma for mbufs.. Thanx for the offer, but I'm hoping to avoid that right now. It's very much a goal of mine (esp. now that we're in the final days of the NDA requirement) to stamp out something that works on shipping FreeBSD well enough for this crowd to see what remains to be done and see where we are. Then we can figure out how to improve interfaces or otherwise enhance the base OS if we want to. So given a choice between, say, incurring an extra copy in a data path and porting busdma for mbufs I'll take the former for now. RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 12:53:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id C382837B698 for ; Mon, 22 Jan 2001 12:53:39 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MKrQ912161; Mon, 22 Jan 2001 13:53:27 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222053.f0MKrQ912161@harmony.village.org> To: "Ras-Sol" Subject: Re: PPPoE Cc: "Daniel C. Sobral" , "Felix-Antoine Paradis" , hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 22 Jan 2001 12:53:50 PST." <054e01c084b5$6c4ee270$800a280a@speedera.com> References: <054e01c084b5$6c4ee270$800a280a@speedera.com> <3A6C48E3.493F5161@newsguy.com> Date: Mon, 22 Jan 2001 13:53:26 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <054e01c084b5$6c4ee270$800a280a@speedera.com> "Ras-Sol" writes: : And btw, does anyone else completely DETEST the "/etc/rc.conf" - : "/etc/defaults/rc.conf"? I don't. : Why can't we just have ONE file, instead of one file, plus an override file? Because we had one file in the past. It was a nightmare to support. Even with mergemaster there were all kinds of headaches that it caused and support nightmares for the folks who answer questions in the -stable and -current mailing lists. A defaults file gives us the ability to tweak the defaults over time and to add new defaults which you don't get in the one file case. This will likely never change back to one file. Get used to it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 12:55: 7 2001 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 AED0037B402 for ; Mon, 22 Jan 2001 12:54:45 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0MKsi800440; Mon, 22 Jan 2001 12:54:44 -0800 (PST) Date: Mon, 22 Jan 2001 12:54:44 -0800 From: Alfred Perlstein To: Robert Lipe Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122125444.C26076@fw.wintelcom.net> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> <20010122121033.A26076@fw.wintelcom.net> <20010122145550.O10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122145550.O10504@rjlhome.sco.com>; from robertlipe@usa.net on Mon, Jan 22, 2001 at 02:55:50PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Robert Lipe [010122 12:50] wrote: > Alfred Perlstein wrote: > > > > So if I sandbagged the allocs to be *larger* the KMA would behave more > > > consistently with what I'd expect becuase it would then reclaim? I > > > didn't see that one coming. :-) > > > > but... this is a terrible workaround, I'm not sure it would work > > and you shouldn't do it. :) > > Good. I didn't actully *want* to do that. I still have to respect > myself in the morning. :-) > > > > Is there an s/g memory interface in FreeBSD? This was my first choice, > > > > See the busdma stuff, > > Yes, this looks to be much closer to the interface I really wanted > anyway. I see no man pages for them. Is there any doc anywhere? "Read > the source and look at existing examples" will do if it must but any > pointers to better doc are appreciated. I know of no docs, I don't write drivers. (lucky me) > > there's a problem because there's no busdma > > for mbufs (well actually there is but it fails on really small > > unaligned blocks which basically breaks it for mbufs). > > Can you tell me more about this hazard? I can't control the alignment > that's asked for by the driver, but I can certainly fudge the size and > alignment of the request by the time it gets to this interface. Just > tell me the rules. :-) I don't know, Bill Paul explained that the normal busdma stuff is pretty broken for chunks too small. Basically, disks work, network cards won't because mbufs are too small. > > ack, I'd review patches if you wanted to write/port busdma for mbufs.. > > Thanx for the offer, but I'm hoping to avoid that right now. > > It's very much a goal of mine (esp. now that we're in the final days > of the NDA requirement) to stamp out something that works on shipping > FreeBSD well enough for this crowd to see what remains to be done and > see where we are. Then we can figure out how to improve interfaces or > otherwise enhance the base OS if we want to. So given a choice between, > say, incurring an extra copy in a data path and porting busdma for mbufs > I'll take the former for now. With mbufs you're stuck. I have some code that needs to send > PAGE_SIZE chunks of data down the network stack, my current "hack" is that I prebuild the mbuf packets and split them on page boundries, then just call m_copym on the chain, but I doubt that'll help you. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 13: 8:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 25EFE37B404 for ; Mon, 22 Jan 2001 13:08:38 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0ML8X912362; Mon, 22 Jan 2001 14:08:33 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222108.f0ML8X912362@harmony.village.org> To: Alfred Perlstein Subject: Re: contigmalloc, M_WAITOK, & leaks. Cc: Robert Lipe , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 22 Jan 2001 12:54:44 PST." <20010122125444.C26076@fw.wintelcom.net> References: <20010122125444.C26076@fw.wintelcom.net> <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> <20010122121033.A26076@fw.wintelcom.net> <20010122145550.O10504@rjlhome.sco.com> Date: Mon, 22 Jan 2001 14:08:33 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010122125444.C26076@fw.wintelcom.net> Alfred Perlstein writes: : > Yes, this looks to be much closer to the interface I really wanted : > anyway. I see no man pages for them. Is there any doc anywhere? "Read : > the source and look at existing examples" will do if it must but any : > pointers to better doc are appreciated. : : I know of no docs, I don't write drivers. (lucky me) There are no docs. You can find docs on NetBSD's busdma implementation from all the usual places. The busdma interface for FreeBSD is close to NetBSD's, but the implementation is somewhat different. FreeBSD's busspace, however, is missing many parts of the NetBSD interface, and implementing those would be hard give newbus. At leas that was my take when I tried. : I don't know, Bill Paul explained that the normal busdma stuff is : pretty broken for chunks too small. Basically, disks work, network : cards won't because mbufs are too small. Yuck. We should fix that. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 13: 9: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjlhome.sco.com (unknown [207.65.180.181]) by hub.freebsd.org (Postfix) with ESMTP id 5DA5C37B6A4 for ; Mon, 22 Jan 2001 13:08:48 -0800 (PST) Received: by rjlhome.sco.com (8.9.3/SCO5) id PAA12491; Mon, 22 Jan 2001 15:14:30 -0600 (CST) Date: Mon, 22 Jan 2001 15:14:30 -0600 From: Robert Lipe To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122151430.R10504@rjlhome.sco.com> References: <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> <20010122121033.A26076@fw.wintelcom.net> <20010122145550.O10504@rjlhome.sco.com> <20010122125444.C26076@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: <20010122125444.C26076@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jan 22, 2001 at 12:54:44PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > there's a problem because there's no busdma for mbufs (well > > > actually there is but it fails on really small unaligned blocks > > > which basically breaks it for mbufs). > > > > Can you tell me more about this hazard? I can't control the > > alignment that's asked for by the driver, but I can certainly fudge > > the size and alignment of the request by the time it gets to this > > interface. Just tell me the rules. :-) > > I don't know, Bill Paul explained that the normal busdma stuff is > pretty broken for chunks too small. Basically, disks work, network > cards won't because mbufs are too small. Ouch. That's a problem. Of course, one of the goals of UDI is to provide a consistent API into this sort of stuff. We don't distinguish at the driver level between disk buffers and network buffers. Ideally, the underlying DMA code really wouldn't know (or have to care) what type any of this is. If busdma is "pretty broken" for network-sized requests, I may just avoid it for now, implement the contigmalloc cache, and move on to more interesting problems. RJL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 13:19: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id CE62B37B401 for ; Mon, 22 Jan 2001 13:18:44 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0MLY1001413; Mon, 22 Jan 2001 13:34:01 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101222134.f0MLY1001413@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Lipe Cc: Alfred Perlstein , freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. In-reply-to: Your message of "Mon, 22 Jan 2001 15:14:30 CST." <20010122151430.R10504@rjlhome.sco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 13:34:01 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If busdma is "pretty broken" for network-sized requests, I may just > avoid it for now, implement the contigmalloc cache, and move on to more > interesting problems. It's broken for network-sized requests because it uses contigmalloc. 8) The cache approach will work equally well for either interface; the busdma interface is "more correct". At some point, some changes in the busdma interface will make it possible for you to throw out a lot of code related to doing s/g for network drivers. For now, to work around the network interface problem you can just defragment outbound packets into a single buffer; this is the 'extra copy' tradeoff you mentioned. Once busdma is fixed, that can go away. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 13:20: 9 2001 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 3FEC137B401 for ; Mon, 22 Jan 2001 13:19:48 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0MLJhQ01393; Mon, 22 Jan 2001 13:19:43 -0800 (PST) Date: Mon, 22 Jan 2001 13:19:43 -0800 From: Alfred Perlstein To: Warner Losh Cc: Robert Lipe , freebsd-hackers@FreeBSD.ORG Subject: Re: contigmalloc, M_WAITOK, & leaks. Message-ID: <20010122131943.E26076@fw.wintelcom.net> References: <20010122125444.C26076@fw.wintelcom.net> <20010122110642.B10504@rjlhome.sco.com> <20010122100524.D7240@fw.wintelcom.net> <20010122124539.F10504@rjlhome.sco.com> <20010122105227.E7240@fw.wintelcom.net> <20010122132647.I10504@rjlhome.sco.com> <20010122121033.A26076@fw.wintelcom.net> <20010122145550.O10504@rjlhome.sco.com> <20010122125444.C26076@fw.wintelcom.net> <200101222108.f0ML8X912362@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101222108.f0ML8X912362@harmony.village.org>; from imp@harmony.village.org on Mon, Jan 22, 2001 at 02:08:33PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Warner Losh [010122 13:09] wrote: > In message <20010122125444.C26076@fw.wintelcom.net> Alfred Perlstein writes: > : > Yes, this looks to be much closer to the interface I really wanted > : > anyway. I see no man pages for them. Is there any doc anywhere? "Read > : > the source and look at existing examples" will do if it must but any > : > pointers to better doc are appreciated. > : > : I know of no docs, I don't write drivers. (lucky me) > > There are no docs. You can find docs on NetBSD's busdma > implementation from all the usual places. The busdma interface for > FreeBSD is close to NetBSD's, but the implementation is somewhat > different. FreeBSD's busspace, however, is missing many parts of the > NetBSD interface, and implementing those would be hard give newbus. > At leas that was my take when I tried. It would be uber-nice to have docs, the interface has only existed for afaik 2-3 years now. :( > > : I don't know, Bill Paul explained that the normal busdma stuff is > : pretty broken for chunks too small. Basically, disks work, network > : cards won't because mbufs are too small. > > Yuck. We should fix that. I don't know about "fixing it", netbsd seems to offer a different interface for it (bus_dmamap_load_mbuf). Possibly for effeciency reasons but i'm not sure. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 14:17:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 0FEB937B69E for ; Mon, 22 Jan 2001 14:17:18 -0800 (PST) Received: (qmail 84158 invoked by uid 1000); 22 Jan 2001 22:17:38 -0000 Date: Mon, 22 Jan 2001 14:17:16 -0800 From: Jos Backus To: hackers@freebsd.org Subject: Re: Possible bug in /usr/bin/makewhatis Message-ID: <20010122141716.A82292@lizzy.bugworks.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This patch gets rid of the Broken pipe messages. --- makewhatis.orig Mon Jan 22 12:54:09 2001 +++ makewhatis Mon Jan 22 13:01:31 2001 @@ -333,7 +333,8 @@ local($source) = 0; local($list); - while() { + local($flag) = 0; + LOOP: while() { # ``man'' style pages # &&: it takes you only half the user time, regexp is slow!!! if (/^\.SH/ && /^\.SH[ \t]+["]?($section_name)["]?/) { @@ -352,7 +353,7 @@ $list .= ' '; } } - &out($list); close F; return 1; + &out($list); $flag++; last LOOP; } elsif (/^\.Sh/ && /^\.Sh[ \t]+["]?($section_name)["]?/) { # ``doc'' style pages local($flag) = 0; @@ -375,12 +376,15 @@ $list .= ' '; } } - &out($list); close F; return 1; + &out($list); $flag++; last LOOP; } elsif(/^\.so/ && /^\.so[ \t]+man/) { - close F; return 1; + $flag++; last LOOP; } } + 1 while(); # Flush pipe + close F; + return 1 if $flag; if (!$source && $verbose) { warn "\n" if $pointflag; warn "Maybe $file is not a manpage\n" ; -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 14:18:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtpout.ev1.net (smtpout.ev1.net [207.218.192.2]) by hub.freebsd.org (Postfix) with ESMTP id 9878337B6A2; Mon, 22 Jan 2001 14:18:05 -0800 (PST) Received: from max [207.218.202.38] by smtpout.ev1.net (SMTPD32-6.05) id A1A4240400C2; Mon, 22 Jan 2001 16:18:12 -0600 Reply-To: From: "Steve Shoecraft" To: "'Nicolas Souchu'" Cc: "'John Baldwin'" , "'Donald J . Maddox'" , Subject: RE: more info about: odd result of pci_read_config Date: Mon, 22 Jan 2001 16:24:07 -0600 Message-ID: <000001c084c2$09e1f8e0$26cadacf@max.home.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C0848F.BF4788E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <20010122174822.D30873@ontario.alcove-int> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C0848F.BF4788E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-freebsd-hackers@FreeBSD.ORG > [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Nicolas Souchu > Sent: Monday, January 22, 2001 10:48 AM > To: Steve Shoecraft > Cc: 'John Baldwin'; 'Donald J . Maddox'; freebsd-hackers@FreeBSD.org > Subject: Re: more info about: odd result of pci_read_config > > > On Mon, Jan 22, 2001 at 04:05:31AM -0600, Steve Shoecraft wrote: > > > My viapm driver is a kmodule. Could it be that > PCI_READ_CONFIG is not > > > correctly resolved and returns ENXIO which is 0x6? > > > > That's exactly whats going on here. Have you turned on > BUS_DEBUG (or mebbe > > DEBUG_BUS) in /kern/subr_bus.c ? > > Not yet. I will then. > > > > > Also, I have a userland app that loads and runs your kernel > module - it > > makes it alot easier to debug this kinda stuff. Even does > device file I/O. > > If you want, you can check it out. > > Thanks, where? > I've included it as an attachment (very small -- only 14k). I forgot to add in the readme file you need to create the test device: cd /dev mknod test0 c 252 0 Once you get it running, you can enable the output of the newbus debug code by editing mod/test_bus.c and setting DEBUG to 1. You'll have to re-install testmod before your changes will take effect (the testmod program loads testmod.ko from /modules). - Steve > -- > Nicolas.Souchu@alcove.fr > Alcôve - Open Source Software Engineer - http://www.alcove.fr > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > ------=_NextPart_000_0001_01C0848F.BF4788E0 Content-Type: application/x-compressed; name="testmod.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testmod.tgz" H4sIAFqubDoAA+w8a3faSLLz1fyKXudOBhwZI4wficeZi4HYOsPDi7DjnJkcVkgNaA0Sq4cfszf/ /VZVt14g7GRukjn3LDqJkaq7Hl3dXVXdXVLA/WDvh297sVrl6OCA/cDwqiz9ygd2VN3fV6tHanWf MbWi1io/sINvLBddoR8YHmM/eK4bPFXvfsr57HsI9H2vAPu/Y9zysT3j34iHWqkc1mrr+79aqUX9 X61Vq9D/6mHt8AdW+UbyZK7/8P4vXPZ756dbOAzmrlXQ+w09fiqbhca7dv0cILvvjdms0O116t3T rUfuFxrtVr37Tmu39FenZYsvuAPIV2dNrX8KmMzid4UzrYuPe6Hv7fkj2ykUyrZjzkKLs59HvlVe eO6kPL99W/irdfCffNH8hx77lj7gT9j/I/VoY/+/xxX3P96Up9+ExzP2f796dBj1/6G6D2NBraoH 6sb+f49rb2e3wHZYw108evZkGrCiWQKHXFGZHvA7zvSpy03PGAdYqz6bMarlM4/73LvjVhngWNTn lu0Hnj0KA9t1mOFYLPQ5sx3mu6FncoKAEzC8RzZ2vbmvsHs7mDLXo183JAYwEO2xbRpIQ2GGx9mC e3M7CLjFwF3c2RbcBFMjgD8c6Mxm7r3tTJjpOpaNSD5SQbw5D97gvVpeEs1n7jiSyXTBF81hBEBz AgNkRarGyL3DIqkQJAKX4wa2yRWoYftsBvSQTMKWmpeVCZiaM8Oecw91xKqrggDDlEYiQaCdVgjC fRtZmGilpGS5ZjjnTmBEnbYH/eFCucfmRsA925j5ieKpw5BwuhnRABhcaDrTe+8G7+v9FoN7CCyu tWaryc4+QGGL1a8GF70+q3ebrNHrDvra2dWg19fZP/5R16H+Tz9hEY2y7gfWurnst3SdAYLWuWxr QAbo9uvdgdbSFaZ1G+2rptY9VxhQYd3egLW1jjaAaoOeguyQ0Com671jnVa/cQGP9TOtrQ0+kEDv tEEX2b1DAdllvT/QGlftep9dXvUvezpRw2Y1Nb3RrmudVrPMQAhgzFrXre6A6Rf1djvdTPiXaeVZ CySsn7WJFLGBVkJ41GoMsDnJXQN0BsK1FaZfthoa3rRuWtCSev+DIsnqrb9fQSUoRGrNeqd+Dm0r PqMV6JDGVb/VQXlBDxCt6QNtcDVosfNer6kjKSCvt/rXWqOln7B2TyeFXektBZgM6sQeqIC2oBju z650jfSmdQetfv/qcqD1uiUkdNF7D4oBYeuA3SQd97rUZtBRr/8B6aI+qAsU9v6iBfA+qpS0Vkdd 6KC9xgCppWoCV9DnINVY1m2dt7XzVrfRwtIeEnqv6a0S9JimYwVNcH5f/0BtvKLmY1+BbOI2NXQV 6lGmvWP15rWGwsvKMA50TY6Z3jukpF81LqT25SzYKxRe2GPH4mM2HLT0wfBiWHgBT7bDE0CBP8DU ctida1tgp+bDP7jnFulpR7GdoHQS44yoyFBGpaQiPiEXVokIAQ4Vm/NFEcwA2ANJjGWflmhjdSCm mKUYWzwWXkA0b4/jmk0+CicT7hWNEhgDoDIubkewN+xH/3dnWzFKcfXbO1mJqCmWwkvsznckEAEG gNLCO+F8CPbGnHL/JIKDhQnNgC1MewitGDNZ/pt6+PGkEEn4V3vP//9XJv4bjkK/bH51Hs/Ef9Wj 6kES/1UgFoQgUN2s/7/LtYn/NvHfJv7bxH+b+O+rxX9yj3Nb7KhsF5I4qnV2dQ5hG0Vv9BAXgSaH EiIimxSd/967hYBozw9HnnDQ25lCe//4UPxx+IMo/gL7n/X/GGl9/QDgWf9/dJT4/xru/+2rh9WN //8e18b/b/z/xv9v/P/G/397/z83bvnQ4nfMnVnD6CEutaC65z7GFVLPq8EA/pHeentNqPDw8LC+ 0JsbDkUKsf//hjkAz53/H4G3kf6/VlNreP5T29/4/+9yFX7t9Jp55/9DSgBgqbCQJVtEVO+VrLgw bYC8SINs30gqwQAGdzW0x+UpS+7NLaAkgPLGZHcOOGQBi29jMrgTSEXyJmEJ3ESJvDELvcsBNMNd CHEhyoC7hevbD/Leny/gbm4aURk0QZbYcxcxfi8QumWNooqRHP9VROqlVAbEadKqnagxO5GYO0lT dpjEZVHGRDqLwucBWIJfyjuFAvF7U9gK3NCMuC8lT9xi93yF5Ils/E9d+VXGVfp6ev6rR2qlGsf/ VbVC+3+Vo838/x7XJv7fxP+b+H8T/2/i/790/++yoT2x/wdueY9c83Ye2A8XC9cLsLSwR3MRgBCG MD4PZzSzCxnBfvYf/b2F4Rnz8vTtEhj+BzlgiqKWgbia4DOEpwqkTHeGl0WQcI9PVgkB3HaJjo+W yJTH1uYUHPMObWpiYDKCqHI4dTEE9WxrwosAM8cToOizHbhRCltbW+HQdoL96jBgtqUwejqGBzB+ vp9UQBAsgwQ0huxAK51wXmL/LmylJfDZKetetdsnhS0pX4yyeBj9Vvt4srW3w6aGeYt2nNUOKs4D DYUtSRHwKyfw6IMBhXiuaFuChwEOsvKgVqsHx5XjQ4j3tpDVtuYEfMaOq7VffmHYXha4OD6YaPY2 iIH8bm5u2AAdAPwz2CTkvo9MqSzhS8fnqCTDKqKOgF9NVZhaOhGVk5pQuvsWnpD8COrfnsQSHqnV Sq6ExxCsFW38e95pXJTYBUo7cNlFOEpLu0quuo7cbrMB0aIgKu+/kHRtHemWoNr6QoLH+U2v1fbb N6xYq1VY+6a0rp9WqL1eS+1MUjv7Emr5ehTUVomwYv38Ep23MZpxq5RP01gr4XkezTVE1M8ggsI8 SWRt63Il+YzWHdfM/OFRO6j9erMHZIs9D+zl2h54emIZNLFy2RoRWzDQW1sYAoClwFBKWAtzai9g /YchHYfglab0/dSdcVhOOhb8uGOBBiGfM8GQjAfoJyC0AyFHXMgrBPXLYBc462i9BkRsELELTKjk c+6wse1BVQwRbd/5CQNOYzZ7BH7QoliTGCESlmEGoTHDRa3PfQqsjSAwzCmG4S414PLm7Ce/VGbv OXO4AAtUVA3VAAsN8SL3KPIOItGg3tiehEARYn8WM0S/BRoeYfWx1BGwQFPsgLfxy1RN1NXBi/CE ouVyatHUgJhZtgeoRQLDgkPykNpjdsDuDUIhtQvSaBXRrFc+5veyVRHmE8wshD/dHlaMkdR1SGRz 2Sumkq+A0KsOeK/UBLO6DnN/iZ2aYre/Dqm2yk6N2UHrQ8+JXFoyRkfx1JB+ilyCP3MDcleJv8I6 K/One4P99AK0cxb6L+o0XdLzhVRKwGh2xAT3P4PgWR5BdQ3B2lME1SckrK4hePAZBHMl3F8i+Cmx DsJV1ztNtrvL7mA8wmgHVpVqlbopMoOVyiHCYpMFCLtHB+ozplgQ1219ifj+6zTxSu31IcJi4ohw fGACOM98VmqV3OoHFTW3+mFFzat+mF/94OD1anUEfqbXqVRy2GXw8x2OUNV1W9eWdFWpZXRVqRwg LCZPGMfVxsHrqggmnukMDNgupHXvXF/CvNbYxBU7GZYRGP6Uc7DhYAxhVdnZOyMDC0sINFNxZBe4 AZrrMruccZRrxjH1k9067j2DRYXhPJKHYPee60zKLHXtvouJoCRkq21n7DJXbHugSKgAIMECA2J7 /5dM8w9eH4N6E9d5rdVF648BE3zvAjcbiEop7Y1W9VA3udc2Rv6StkevY/nehQ4I8YbcWKKZwJ1h umyEY6MDY9uAeLytQDC/K+EREVH+ExLeJq2mXREzZvfGo8/8qXsviLzeLoOK3IexYXss3XD1oKZi eTIBI/k7WAQtnxkWeOLd6xJ1/5Nt710O7KV21w7S3MzjahVhMTfCAD0DPDMPztZw6DcaWQbq4eHK MAZYzAARYHX7pwKe2nLAk2ZzGLHBHq2324OLfu/q/GJJmOMVYb6KJGkWr1dYtL9Se0Xj0CNMPAP3 KDu26blMd2dyhy/b1bySbvzxce01wjLB6Bo61+3cDrf42AhnAVKAyV+k9Sw7PcVGNYZnfa153mIv X8ZLXVmky6LhRU8flGLH9rQNA89ViCIHWCN+irYadNMQ9kPElVHQhaEbqng3iSrFviTMFdqeANsD i2mI32jHVsaStNYnXA4hm8Qr076KXHlTKnt6S8DiTmCPH4uWZ99xD1fx4k6JjppAJghbHRHDpLYM Fp474tCu9I5B9JhsGSTbBEyMjJOlvYGTwlbMCKL4GdLAlPYHBZvKLewmaFDx4ZQeTysn7IH9nMl4 Zw+vXokICzsxynN/+FhemEPRb387ZYcl3BUJbCcEodnSRW0pg7652GrIL8d+OWVZ+j6f4Q+t+/Ox MP5bhwYtX4c2Dh1zHRqWkbHYgs7MzrSXhK3gIOwPm63r61a32esrrEbTDvWDKKdsV03rAwI1Mb7X 02q067oeTd9kQqxHgKA5hSPn6PrNqAjXtpTlkYMz7KXcW4pa4YsO36IhA4Qx/6/ebA4bF1q7WRQj FjhXIPrdRnbbStKJRCQadbBqxEwBs0iUgGtJhpmfcI7KWUPvWCSiE6ViPGzhhqSRABinQyKGNQT7 7Xg2TYBd6NgBlpWQlTQJlZMUO1l3zoOpaw0zrAXM/w0XLsASrGeTKqOI3BsbcIcmEnq+0xpc9JqR lNE8V7ZyJn9JycEQ/bG1tdzu3MpijajQkfSEO9yzTQnLre5Pw8By750sQgTNRwl9PPFdwhDAXASP ++GcZ+sLGFQnzcGiY63aEIteuBFdmSWTKsiyxkoQXrrEiY7IllSSKVvF9ThFpWuwl0tzeJuBfQcO MCHAMuyXi1cpWPwZGjkVVqnApAoX6Ai8pf6K4as4ATc87P0ctEwR9d6/GUzsCoM5elKQ73Ilc4es xpB86WgYPZ/EBwNRxcjhpQa4gImpJc1GYWt19gFQVYh1s69dt/rDTq951W7hhvpIEfSUVbJKViCF mgAm4K8+wd5c/5crm/9BeTtfncfz73/tJ/nfhwci/6O2yf/4Htcm/2OT/7HJ/9jkf2zyP/7S/A9N rz+R/wFuGf8PTXc+d538F8BElS98+2vZ/1PO71f3MU/7//0jVU29/3Uk3v/e37z//V2ujf/f+P+N /9/4/43//1r+P+3s6Zs/wuN/RvJl8LjgT+ZZZuFgLMMZX4X/K+RhDphe4vm8zE65e4i7ZLlZnCvZ nXPDnEKj9+yFkDMUn0D6tdXvttpp4oElMj0zoJk9ysJCBwyMtVLP8JaSR7nnOUvkxqYT5OgqTjFd UiG+BrfaD2Aol6D2xDGWUl23y+U9i99R4IS0KfsWz6zB7aEHEuPAIhcosmrB5U1tc8pMwwkwH0tS snDc0DecjH+6Hu7/DgP2UDoRMNvJwMQdvjwId0V50oQ/j1AYilL4W8XbFTQEVrFAVpSoI8krFMwS KjGcBMvAw0SQMEcS/J25EzYcXhaxTMnk9CqsXC6XRDVvbvi3mI+7mE3Bx9F3sFZKguAxv2Bku/kF 9nyRX+DwIL/ANOZRAZ0yAuihmFTBQyDo37HnzlkySKKu83lgB+Rfl1ssv2MlSu+MGbZ+FVaS5HUa aHQEKs4BmLbXQyaRWaGPiDVb10NdO2fw/0rvq8uYdCjghYvAX8HU+n+PMOvtfgcxn7tYB4IH9my1 vcxpEx6rjS2FPiyGvzhaxtZJ4cmveq18Cowg0z/YKTusieIRROl33BuJo87Exp7IXjBDPGW44zNx EIpA7EIwCgkAes8MZsOhhZ8wE8cgHndWyqcGZl7inr0ookGxMBzbLKbH8ngeKDiacc/9zhhSOGYs 8MQw+lQa4bxh23hcBjVwvREUjYUCmASS9ZCQsZCVYBFYFA8Rld8dIsAf7KCIJ5KfojlGU+8eYuLs HEvLRYpFkdICxpSBxnrpUC9fJqE8EXTkiSD1N/a1PRnKIZ08BcZIHgV+EroXMBgbYbrHYCXhGSbo 3bAsbxiQmYk+Z5dTzgxp18SPSTqQYqmR5jCotp2l7+VFv779Bx9G1HNqhhZyiurfigeBxGbcSTNs Xbb6nTRTWOp8LtflqrdprpEMn8HW5zPoB16M1JbWXaosR28sPt9lnz7LWIjjXP9ZewHmQniQ9Lvw xWi4wL1/z3b8eyEJ+SWFhTaeJof4ZseEbid4S+aG04oyGfnkYE4KKXf5FH080X6ePGU6LLFYnvXy 1WnEnlPuB55wu5hijJl6mFqTpKBR6jWOeDq7pawAsFTgt5A6HbuXTk8rpSRjN6sqkD2WWxGySjWI qZudziyyNr6crnOr7BhzTgWw1F6d1lAB/D5MQv9+9y0y/qcAjmfGxI/B9CQKRunqo7g+dR7AUVgB CSntI6R8G3ic0OMkeqRGYGYG/p4IxdguWOSicCIKeTKt12kq7OXcKrGfWUVkUwCGB3HKNtWOa5FR Suwm5kb8KX3C+KeJt/RthmI6KhI18ktRRBodFo4Oi0aHRTom9cTBH8poJWqLA0D8dGe0b0g+L7G8 KYZvBKE37Ef0voiLt/iFTlBCxA78sWRQis+V1+q5iXq2ntNzM0/POapKPIRMInvOoGipYOY5i5IK 6CBiHNp4DyrU32vDweDDsFPXf81EfRA9Zio12r3Gr1SN/Y8A1DtnWm8VEYLIDGK3NVhCiyAZNAgx s/wS8nmYBZmrm3q1wnKZ7+IxPu7q0LsiSW4cWioaYBCMmotZUSwp/Fthw6CvU+5B5OusC78Tu5+m dwHypUTFW6VSQsewJljPJxP3jKLmIMcBfT5y3GO5yHHQn48c91oucrwwyEdOd3Mufrx+yMeP+14i F1KJ2D67d71b7Mq8lQfzUz1H/ZYJ6Tv1m6F2saUeRMGWPR1SYrcM/GzvX2jakXBxRwS1Xkl+brgU lezA2hpIA67/W4rqx8ik7QAlxMXssGJ2KRfFE1hcxeAs9bnhqAXxx4efJiYckhQ6TZRJuSPiIK2C rxnBleaCv4vAEyTIMwkHLZhimlyUnXlSWGtMU8K9YSgRfuJYQYmkUQUmcAeLXeEJf3yQ1lVKj5In kggpkuwdyoC3aC5T0ECuHyUT0a7MFZVZoqmeWMoS/Rt21MPHctSfIptQAkEEoCb6PQbKmlAg79KF oE8ooDGAQClPNEheilorb7IknlTqVpiUqN+GHp+7dzwZamvLCJ3asDSEd+wpyrEMLUUMC1IZAj8J 8Z/tXMH+TdSr2INAfvctPKddIkASvVWW0x2fd146vngWztBYP+e7SBPNVrv+oZiaKjGAYQABC50Z 52Dj9lQ0vNIisCTzUqiTKnEPVtX4xhWpPZCIydRc3pFJVgSZuvjenQyCPTuLcz/n/kSUBfbcjVea MDMen+gCQf4NvdEHul/gJoE/ib4jzgRDop3qicy0UCvLsyFu8cNHORVSEHy5GYjmDN9nZcR2xeOD GpmNl+J2k4CPKOAjCIhguItEFLF9VsQUZ/1/23vSrjauZD9Lv+KGl8ESFlhiTVBgHgbZ4QUQQXg8 mcRHR0gtrLGQFLXE8mLeb3+13a27tZAATs50nwSr71p9l7pVdWs5qlRO60fV6ilhtCgM9A+sIGA3 mMPWAKA1O08VrgZ8vxcLs1vcNBoQ9XdVVNuq8r767ujgNVI4RJ2poBsGBN7Nx0438ODLxpq+lfU/ x5jxqgSAzcDdOkDLBrq19PQNihAHFkvEE3H27OpyRStczK4ls4LyUVQaWzPeAuEVIrMVbbzdH/da MvaxlVWcjBVn4wh1DGhoeKdIr5bv4Kbjh6VjGPTj07J5O6j84/W7N9ap//Hhyd4RzHHt8F8VlSup 777DpNfv9n+onOelFsrkqEeWB/jRARKKkITBnLxaZOwQk1dcFIup73wQ/u6/blNbxEyZ6AftYRBE Zj+SPEDUR+8DD+slBlBwvyOSZ0gDAgLahHygznKUXiwIbE4HHSewQlRYY/GlX6Kli4TcV9ehB6Ek FmwVwkI3b7+A1ao7qFYvbTRGDfMNybmm0WgzwMPaopFGvLx4M3PId5ZQU2W2MNiuWFRbuRk2BnXi BUmROPTE7JMLuLCprDFXwAqs6o0J5fmgRsnLfFBr6bU2Col6GaFJhVfZB3dA47uUC3l966tOf8oJ 6DS/jcrpTFeioQ3/gtaZwKTWHf5d++goKGOaXWBYGA7ncOqvDDqOdY/v4MPLRQHUjm0wmi2GPJQv hjucD/1COvw1KTed1gjpNQLGk9zo6wCYhur+WWUPRQqdfoJIwRkaRreW4ALEOteAuucPkeYMnOyp yDlk8+yBJK3dDDujuJMZf/qx4h9fCNTTA1aC+gsuBTPOkMjDPWl5vD87PK9MWx80XHW+RHAXSflB Z68ghuPGYDA3eb6kBleAqeB/lGap66t6v91GCyw8Rq/qIok3p+jE0mrQcCvQwelwqnAeTVs0ttFt aIjXBzah1zu1LuesXgTQJMoSoVpODjrSBzmv42b8TL9k3I/3Tuu17/fOKgf29m7QmCJ89OEZDQ0d Br8j5DJBYfnK4u0befKKAXRYLBoEn9/i3YndjXtzzsHk0uo6eQ6mfqZuaRtqm+/Un3Pt4hc+wq6o Qs6WgNJyyyMT9OD1SkofM5eryw+SFErYWKHnLl1yOuN/s0PROxW3yVcB1DRICFtx5BpEU3cucX7d O2revrF7F9y11Hx/gHdAeHOSMaJybVj9NmA9v/6ArfonSajfVk8BX/QHDr4wCMP/BlNeaHkrrSb7 Zuz0EjoVByjUKeNErXDRH2gJOv4SCTp6TEG0hh+nZdzCl94IOG0Z03DUAsAKKgIX1O+E5JHFsBkJ oO0DFceKfYiICTqGFMHCNMdPi5mD6mnlhLyX3Jq7mf4g6LFxJ9RrrPSbfKdjX1ERiY27Ys5QTLv7 R9VaJdJws9sPgz/cMqKkSMNEiVG7WhY07qAcaJHaHd6swCvZ2WZ0AvY7tRdCd5Fu+Mh/3H7gRDs/ 2hZrX7mflgOQhJd4cUsLPtMlJQQof7p3dlw/qpzkqBM4OptXLe4DF5WTqBaxeL36js34M3K+Cj+G N8K8lIDTd/N1CwYMOwJmexWU00+BCR374ZCMH25mcjJc/OFUAL9vlxBtv51zYcgz9DIASQWokwyy T4M7L0cgU+ZbM8Qn2kr3UfY8Mj2n1aOjyCpATybOEAz6K/h7+po9hmMz0gwdtraZq6sVOHrsy2DY H0WadNw5TMDB4x56eukRAjCIWG9+M5WVk+r5+U9RwQTjkJrFqblhMOje5RmRQCNwEqEu0g6dCROR be2ByLaWjGy1ACp6bIiCkshp9PWFfx6gfHv6gQCtIAU5/HVeKKGCQNlud8fhR0TU/fEoCXDuFZv+ LU6kTZo4T87sypixiovatbiZvm+e24AJ9wGucwQB2bkcoNsBXT9yQ5CzdwKypewqkv10nyTpipEc RtYQZYuQdNe8Ec1xi1aARzdITsfJkaVRtrcERn+uM7p2bnYyvBoQExIBK24e6MdySbQy9rtBY6hE mGfvYpKFhjGZn9MEXkDpaQvjbcRnLXYho9uroXm5Yl1Tv0VOy+FoFDx6DmdIMltJmRPJWaQByH0g ephiUUpMwGyGkQiGBaPtWoRFXK2fHbw/E7SIy0sKxzg2rKucqrSmgJbEu+xeMF2kDIT6iMwXWG9M tHCjYApW8woZlZpEFHZQQ5UGIoOnKjVAwUR47WQ1erIKkxQvZ3wVlcbVSw3EPgvW9EoHdxGXWhld Ax+O/LdkQNo4sKnIOiVUGSfXkeRSsViU+TMarLnD88PjyhmSYUeIREd0+MUHylR40JTqdQc7c9Ky M5vWWXaQlrTopOiURYcVfw986LdoAnwGlzjwsZOUGHxSdAp8pOb1APguZfEgfCwCSRo/lGovAqmq pdpAT3X65K8F6CZSr61fjNt1j+ASrVu3UOA4DJossHlbOd+vnryZJLLhDeWWTPrgjKP4i+u1v+Jr Apt7c+MmCnd4zGUNWvHVSSy2QKUWeDIYXdNwocdRcgUHJclVFbajq4lUCcrkUGkegNuOcOjIgHf7 jRbr3dAxxHYYmqGOPp1W2XuHJsa9zq/jAD3UsadTRlYJdYdBOyz7dSEpGAY90qJFHVlyKIbXsZGH dCnKXlWBEzOoGrwH14FciEvnWjfAqUZlPLqEjvhof6g84IMKKWRcxs7AnPrQcTgImmjpp/tllsiv L/DqolQE69+XXY2nboPtVhkFmnuw6kENT121ua4L+7O1hED8rIvhNblLv2BmhH4xepuGyvCOed2S nPHUurkgnEAlUS/oGOb39qLvMr+S7nyyjxAkZxg1BqH5osm6XAF7qL87OaqiiN6UMqQgMVe6s7LT kr4JZarQQc27O4gPWDDASRHc6BbgpIhUTA8VzFpdDw/PjasajSBax+1cHBdMfbSkhO3NJeTlRelF 2qdcl5LkhZXT2Xn3rrPfznlrCh3uQkIXhSvQ+vIu7rT8S2IcoMTyLm5nPHT1O+1EhIvUKfLUDTrt zTOJi7yuKceMrrSpG7AkJGcG15iic1mph3PQmkufmU5NWqjeKuAVYObfzP3DluFv/tLgQc0wWKTt q3fty5dRNjWZqzC6jTITDsRm3vgihi0hcFEQBmLeg6VkmOWIyPSHEr9tOZYkPt/uim038z7Z/5m7 wgzU4pUJX/EuL+FjILXIXpkq+0d7ZxXtlgmLFkw7BVU7ROd0dfbdVKP36tkBUGx7Jz/hWVf7qXZ4 cnieI93v8cBU+OHowCn85vCsdl6wmA4PSqz67oQraxdnU7srWByWOoP6Sz7G/wPatD1RH2q9uLWx MTn+H75o/w9rFP+rtIHx/zaeCB7v+Q/3/+DNPx9uKx8fuY8Z/r/W1tc27fxjLMjS2urGRur/4zme 1P9H6v8j9f+R+v9I/X88mv+vNju/AFoaeCRUfa1/XzeCiUhyNriFbdZTvnZvJDGm5MvVhU3INfLx nDcwL7lG4aIA2FwY5Eiznopv3s+Mq+XaENZURVrOXcgdi6TmLSRUHYrlbWMunFPVlP2v4c4KrQIw 2MTGS5vcZ9MWf3NWqUzpsn5Sfb93eA48lk3ChOoPmVJWhKfR6fnSp/PTP4b+QwdyT9THvPQ/UB1r pU2k/0rrm+sp/f8cjzf/jo/Bx+QBZtD/m6Xilpn/VfQFWFovbqb+f5/lMccVeqDE//erx8fVE+/I imdlE9mG0rfffqsO+uNLdda4CPu9lGVIWYaUZUhZhpRlmMIyqK/fAKX6unawrcJhk8Rw0aO4cA04 aYPQ66si/Lelit9sr69ur2+pVnuoKrcD9TUzHxyT6bQxHJlgm2ivhdfcnatBN7Abl9tGM3TUPGsM mx87o6A5GgOS1oAdsDEWIxlAIKoVYLQSDBiHZtjDK26JsANglXanC9gnxHB1GBMKDSovCWkIshYc xOGcshEe5hgPGOBz8mXzESenSt/GNwRJAZL+FAzQiBw4AcC+3V+5tfO9w6Mf699X9g5yPG7kXwrR XEE5CfDxQ3ROp9XHIjl4P8MtwXI/+ykXq6lQ16Db6X3iG0LUnKNAM53+sDO6c/TSTEUqwD/LdLXD 34aB7bgsaiPAoUf+ADjgjGidhDomFjSG86ejYJkORN3JatbpcCb03ZlOy8Q3QdUNE+UKrfvrHJMM NRNeLalBb+DE1MP7eb9wSDjdFOXXhHLd/iUcw12nVUnRmlmJrcM6HMD02kqcEKkTnzH9kfwaOtXx HRY1crPQ8HXAGh5O1eZFJrNkqsIrVQZAuxcUw3vca7Iprqg6ZLzieF+cccsbNQdWTXAcgP7jvAqr miwCMrlcfO6W8m5YJfSqGXJcJWedhIEBSOLvOltVdmSjN+Ll4fLw2I/VYDD8fWSxqCUs58f1sZGh SJHGD2/GSuAZIAToSpbU+fHXEiwnmzeG1QA0BN1AFvQbhj+KliAlFgnUbnxlCKis/9mIxQ2aAz4f NgNa7OOHeetlp9EdIJ0SANUzxO1HY486yjfaz46hletYtlGvRyG18YFmw6jiU+E6LpEy4ralg1fE xmmL5wWFfy41+/1PnWAQHz0v+NA8YKlkyMQUn7px1Jfl3y/NxqTP73yI/0eLm+PKk/Uxg/8Hpt/c /22VShj/p1RaLab8/3M82ddwpLSuO0SDIBkH/wEVDjzO0en3e+rXMZzoozvACON2W+UaHIBYfYSD D06pwxEThxcBHdtAALaEWVRIyALTN4SDCj1c5IiwxcUG1TAK8gsMcd8ObqDlYBBuZ7MZYLtfjzEa 4iLHBu12sxnggD91Wd8S6wK+ymbWVsgaD6r/36sVTL3qt4ZNIT+BPB1IrF/UlDJUMKqpqLv+WN2g 7+VRX8wP4YsuQoyyGiggOj6GKFv4N5G7qJrVaePXiJ/tMJ/NrK8o6ZD8N/UlwD01jrHqJe87JK4B lN1YKehWOO2eGo6RipWiMIRAUePxMyJX2pfZLPSOAKM9IsZkJm3akP0PWz6fRq8ARFmPYiOTZc94 BEOQzaKfOKS5AxhdJH9UOB4M+sMRsuKNC5yqHIAX9PA3uj5ESALy0ISgvjqGMcYxzbOuEppBNsdD jEvZvQMWAP4EV+MucPwh6UEXWIWvQFPAKr9IIQHdiodxyDXIyxlQVt+sbny7fNHANSeew2FkEHb0 fHZ7yzVRN3iEDu90UOts9m0fRrc7bn4qZJf5fjobhvqC+r9Ly0ibr/SCUXoczf0Q/peF+wShX+iZ jv9LpeJWSeP/jc0tlP+ulkqp/PdZnlT/IxXmpsLcVJibCnMfO/7btEgvE0K0PDTSC0cqiMVJmSfE Cm7g3uXssCutbrsZCZEyuKEyvs9JJHO1IUPZyxr3KM+okmSpFHwSUtw/w4mvfVReAQZmN/TDy6Z2 5o5CDvad/ebwqKKW2ugqRDRYyKqAijlNkeynH/6vY9jGXeWtgHbQCMMbdLQjlmFoWC5UPjVlHbLT AF/cITuQW8DpWRGdfSy2UJCmC4vQYQHddxSK+YiVpNNC3EM29X6kOQSefqGr+8ZWCs0lcAQXNJn2 qb+gjWjQ5CKvTJPmazAiArBYH4EHACaMWhqgk/VgNLgZd1o5+IH/5E07Ax9sXXACyFW0X3SYLzhU nB5ZZCsWizQ+auFvocOsoXOg5d3BTR1gI+MShK1N5pRSfGi/sB0BjcsN8+rr76vHFbfVKcOLlxzI zdCh6wCOkLL/yzZ8cijdy8KhVbNcKigAQWDAdSY2PpJrTJ8IWJooynFmBe1EtP3mbBc/0YeNO+lT KrdBE3nVGNvIe4z8WMnKxT2kdlVJ/O/cAaN4hYnXP5c+RPx/Gg9HQNOFwBCi+RmaZhIrui3GmsEI N1rOGdd3PW0H+Yc/LiM4AhdzOdmmhrZ8vdWHIZVNjMxeMESZK6OVSeiILKacexK3HowLysjDGB4p iBcuQTVsoVP2kJBvqle4kzl609HUFwok5PICTbl4aWn7rbmWfGwP4da3bUxs5D66ddj7FyMrrHin Fy2vfSioFhfpk/Hfu5cv1XdqQ8y4tOtXXZhKfbWjXpRf6Ep5Hrjbly9xN2CK2HUhFFLApHFR6zsV h6cxigyP9p80GsJ/OTKAWyC8l1de+QWNDCcPhmOTiOPRZlPD9kBvqlaXrLFFREMzxtONxnNdp72z 86MDVCL8TD/eHlVf7x2ZKeMqeW9DEcJSemfywbH9S++Xkbg6RqMvRGn5uKfDrHZFRVIRXqW0ZMO7 q4s+X7/pxet4yPb2BLQPpXMMGQyH04xdaroRH3IyNkPAt4HZ8Ppn6RBa0P4C6/GXBXE4x8drwjcY xyYMKsItu1h3jNMg9fQ2i2x7j4JwBjp5Q7OTU20zPnsMpfwDRpFrxMZRGtJ+yMuRAdD9eEOg69hB mB/peVMn+ZIGdFPYGQzKCem3yelh4zoQc2N0yDMYOONhK+d1n8u73bDegTMlLCvuSuFfbQ1Krdxy K9TYS1WCgtS3unUK0uDlqIX88m44vuCTCtBPjkp7iZ8/0y1eUnn0KhivsLjIFXT5/rAF+Po7pyyl iP8pYzuN0xZ+6gzYBw+ODGI1GdBMZkmGRw8lpOhPpUHUGOdxhnLCAMEHa8PMd8fHP9EXxD5AtcZX V3dq1Ag/5UJx9KSXpHfNDUNkOyFnUnn7PtbetDzL3C8tuEqfR3lI/ouOSJ6wjwfYf26VVteVQonw Vqr//RyPmX+KVv80FwAz5P9ra5vm/ndja7VI8v+t9P73WZ5U/p/K/1P5fyr/T+X/zyn/l4Dg88r/ k0O3w75sxlPHSXHO2SnirLDtTmxzG9TcWAGRI0vW2oa9U6tHSlMA9P/qtFFBkhzX6Sjw8sJ6glY5 FhJV0ZrLipvM/6meRaPbQZJa3Vg1LfgV/ll/d3J4Ho+Ih6lqzdSi0Oyo8KNdkJuoiewOG7WRxR85 umM2eSQsgkzKoxcnk9RcdCa9WDGk7/Gcq/Nv8gME4JDUaemV7bZAydSJSWelGspAH9iY3uvjL04j h9WcSD85ldVvdBP0xhno2ZhL4y9OQzfFnIa/OA2AB+x/ecfp+o3zxH2c9WSEbTT+jUl2wjgZuE9p Gn8JCORon2GgMASUypH0IPWgfrL39m3lgJMvpOHlEmlW+0PLwRX77RGk4N+fvbn/YG2WUbmaSuRa ebXIZSWqav5D3MMUSfyUcUbv6uTyT4yXqy+SYAuqpYGywV3DJjq0h79826I75uiwxMxfNFoYiGfE qt46NFDl5J+HVe2Kszmg8Bx3NhcwLTp0NjniRozeEyPIck5CDFnOEY+79Ft87BZNHn2VzpSXohMA wo8QoFX1cdx8R5RJcnwzzCyGfZJxjoTZtd7cZg4/rbr3FPeLlO6031++J+KYZNCnFh2fURRBKol7 e4LzX/IPHneWJuHPbz+sUHTgqOc+m00fSdMhMjMnarAtRSllnS0T72RjStl4Omu18Ds4sK+RWPnr a/aM0xS2psw5DBGq+ikgptgjruxIeC9lirerRTdlFVL2iu5CyVr8lXPWiTYdQL/0JuL70Cwb8kvv rBvAOXMuGw7tg07Q518sp9ADXpsNg1/HgfiQNo7UaUux7zl04e9HZ8DY1Nvk51JCUIvPb1NbQonz ROVsYPGlPH7tJHf0GIqZmnUCLye23PJabs3Tcu2gRk2H7G4ZfS1D0yLIRSMQxiR0ic9tuR6oXe/o TntuTJElL6gICl8dZIWZZZsoiGkQcyDoQvy2ekoQ4zUAhRFhYG3okaU+iWedhDngplZNnCl0wB+P zWiCFcAmI4Dxl1wsQ6f5/FS4awJ3yHDneOryj/UB1Lz2Qz0NfAt6HHxxXR9Hl7LcPHw5bY4Oz340 k8S+/Z0lxcFsvSUlWbcci5cBwVvKTu8ih6hFR0L4bJJW8+hi5Jvy1EklMG5NFKVbbzwEjtIG3zUC kse+d9ZWtza/KTMc9Fft7u6UXM/8t2qRMvLK8aKfw+byy8tl9qY/Eyq71txAAkt+tNrICLvRJMzO TwgNcT8JzTPm3RaUaHqVpehEMBC0qFHnXJFx54ljtOSGMvpjHkANCTCHK9BXGHS+M2KqcmogBiQ0 +Vhn8zIiLfEWfMWeoW6LcBaHExusvbdUAjd3owmAm5VWHUlhDl+QWNsjMqi6R194sKAfbQlxNELt fwGJ+RMKyr3oMCz5CbuGKAG5C8b72aAVQyJTnajiRdTHoPkJzSwQeYzpdhSpyKA156hzuC7kBt9U z/Yr0rr+eieYlFYn4Ani6YnGyPADPZmiEu7JvpugTxmHReNAL0X+j8ZAx9yZ3bE7oNtoO/1iJFfe 20p0G0wZHCTYiKJwZfBUJmPu3kvuBNzrKRdKdfKsSzzuyMTPnnkGdMrc/yl95H5pqfuf5zH3P9re 5wn6mGH/p0qra/r+Z3VzDe3/VtfR/2t6//P0T/YH2EE72sQrWzvbr/HbSlPYhOB6pZndP6rsnaDy W+3lzgpbnWezK0aQeBG2Vj6haurVp910c/2VHv/+97E9//IzY/+vr61t2ftf8v+2WtpM73+f5Unv f9P73/T+N73/Te9/H+v+172JZJ5efeOnCq9O15Nu+uH3UhoF5zUtfYhfd4k8A3lJsp3A213YnuFH tO7X9wDRZJH/63CLZeYLARQ3Yp533UIS1rIpxomvbFxGaeLw7MeJTXRsE1jMNOGFfhZZADsXILmy BHzW4T/9AhL9E5hA9PCDzH98hJaUlfbTxSEr395g/d+0oL8dWj1ouZvFwNT3tgLHx8IaDxtkR/gQ uXaQbzkJAkSoF3Rv5Bl8uR6k7O0DxgaSG0sMsKY+f1bmfdeXjOTZmE5fHtjuNXvMgv6yLdVKKNXS pbSAJX797w0qy6qcNf+hHBlEEUe5G+CDlpP4vqkmt+iXm9Fw6pdonsej/1Hj4wn6mOX/dx11fiX+ R7G0ifT/RrGU0v/P8aT0f0r/p/R/Sv+n9P9TxP/gO9xY/A+brB19Olo1h6+qdEE07HfDrNfiD5Wz k8pRRLUTieCQ1Dq1fqSb2+k3m/0ETVPREs1aWpScXF4EzQai7TFGZw91jy/caLfDG8j7Latl95Kq OoCogO6GinX4WTb5OqytZDR7I5vXb7cp/ivmwe8wGCXXg7Om07JZQW98pbPC4FL/2+5eJpcZ3sg/ 5RjUzJBgLv4aaB+9Ci9D9HygzgF+f4Tb+E1MxlEf8ue11Q+asofXl1SFPLV5uj1xJoJZo+PGv7m0 VU6NliW9OC79hnQlZ5S/MI2/nqN15lsYFtIcmwn7GCaEyr87PJhd+lKXfjtPaTzy5VtP8We8xr1l ZXi+DljXafaUPYiPu7e8EHfzlrVxMLBqYuukfzbuNYXP1q3Tb2ENgZ+Dk5aM+001VmfhKdZv2Lh5 GXQofuq96mPTXk13V8I6LrutcR1c934dq0BHxWkZ402s9qDit+BDwF1EYSdON1JykFgS9rktOuyP uOzVFd4Uq0ZECe9eGUEBTADtacPmvXl3sl8jl906pXpaOSk47/twgFXcBHRz6r6/P4Oz0U04rO6f H7kJp9Uj7/34eO/UfYcjau/cTTh4d+wVOMUIRwWPqxe9nkzmxfmLSOLxQQZgeJ+TIqRNYFZ6PhPR FfTrHkTrlhxWnupGFAL96rWDWqT+KmnT5Gkf+gp/0U+pnmLVM1t1rWAnLq+t8EWwkzur/JhP6J8b cfpfjzYSeo2c5uOAHJ79GIFkw/kIq15mwj1B6lf+iYy5X5one87H4//5svfR+5hh/7mxtuXw/8VV NAktrqb8/7M8Kf+f8v8p/5/y/yn//ye2/9RxuZ/WLjTZ/PMxjDxZyFFhf+EtzaWJMioyTCzo8Dy4 edY5fJvmaXInKK2bKtvMeqHKeoE5L6O9bo3kCo5ZnKvNPq8BV8T0Ck20bOPseohQrG+CRcVsv1mr uOsZfE1WnKUL3H4dZi7nXy3mxa60FmgGirz4kQega305y9YcK9ZC6bYVNFrNYivQJk/G4oa/lBqE 88Te8LoqwXrkGaBt8kOPbkVj9iQDrp+zpjsFZXsiHW3sCe1HVA54AThrgNZACxIgI9R4kJ/ZM1ZN 7HpEWWzrdPqvyhlgwoURaTsusK721HYbCIPf4r02/nOsHiLgRVsx9htmHfozETeg8/MTLSif2lD1 K1pUCTZvNQxzoy/pNaC4jaEpjxsv2+zJRqqYOdFOFTIbK4DO2EB4xwhJvEyUlWDe1SiaM+igTjn6 Gq2TXILB56Us9tdmxGVTsbnS8xqsPsZ4k7TjTz3gRvtjzgFHM3fX7lOGFmXTKLLlQe/0EUIaZj1y p5Wz48QGyUT+kVp8gG0qitZkhcSMU2GNPMA4tQsrdkcdVveBQj2uH1VOyKxUC80eZx2RDOyR1hGQ EAAg5JOokd0hAi+DPAgOinFWi4UW8bvqhye+I0oqBsXhyw3qhN95bSWNI7Kr7RK9jslpnRjiJVm1 UcvAXQ3bwCNhUBIE4m9dtv2TYc1keMQntq9t7SLWkrZEQWZfYL6PjA6uB9xIImv18ubbSmjk7e4j O8gYctEb5a/IuasdayCELTXzBwcSqcDHHEketYThNANpzQ4T9zo6uMhFcDXpC4WJ+28m7kDnGG57 11dyZVUnmTb84D56KNR2m8wtl/Ixn5683cWvhvYNeTFuq6ULF55ESNCXRoQmlq7Yz4Zsw6QxwdGf VNVkcl1Xh0z52MlTJIOpdv2P6jsmVKTTRrrtPqwOXytOOy9vWTx1ePKPvaNkul6626a7NkADIZHx hro3iAGXT2t5l7wFK/wFpeSHGO0ZIp+wIUV4YvzW6OJpc6e0U2cxQWRegD5goq2m2UIJ9po7GgzZ P9xSKWYOnWiDS4Vzpbz5PkpwSEX28UyJmlbHMK2UUlBw+mAsVrLym25taj2xJn7CsrFnNtmoPGkc OHtfZT+LtvN9InHNX7Y6+cu8TzMnWbVycl429PdhrzmkgLakyslnmgsfupsWj9zASsQsH8kTz6Lz wYh/b4AhIbpaO0lgd0CSwa55dhxy0GSRc54dS7eYDPbQs+MQICaL3fRIlrgPkixy1LNjMZnJIG89 OxYlmQzjsmfHRy6mAPnt2VFkVr5AEU8x6CUcHB9lOKh5MjKWNWuqkh+fHYt9LJjkzGfHwS4mS9OP 2JahISnnwnZCt9TZbPRiyzHFrZMt7k3BbGL6Ne606N9L+ZdujAt67+tTEDcA+bFHvnrqdp7PQ8vv 3cFr8+1gu8yPK8eMLn35gjMvMaGCxXJeLg8kKyJHHMqQNnI2ImNI1gl2kD7rBbdaVhRj8Lt8TSsB pzsWyHSXb6dkErZvtabIcFotcXokP33k/gdnebIfHiPmMf1PlfJY0JyVI36b5l07D1w4jB+de96c /3EJa6Mo03MQeNgU721u/G3z+84/M1YyCh6KFgcYiMzbqtug6492gS56OSJ3IwTKkuJjs7E6szdu EzNdJfgD7S33L3339md43Ph/w+ZK2MAw8Y/cx0z77w3j/3dzbQvtv9fW1zbT+9/neF7Z+FLhK7zm 6/PflU/9rJfXGLc6ff4byxuNe8GQ/8byho3LgP5gzpf+2vRJn/RJn/RJn/RJn/RJn/RJn/RJn/RJ n/RJn/RJn/RJn/+M5/8BLm6bswBAAQA= ------=_NextPart_000_0001_01C0848F.BF4788E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 14:20:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id 4A73337B6A3 for ; Mon, 22 Jan 2001 14:20:38 -0800 (PST) Received: from HSE-QCity-ppp94185.qc.sympatico.ca ([64.230.224.150]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010122222036.NWDI6682.tomts7-srv.bellnexxia.net@HSE-QCity-ppp94185.qc.sympatico.ca>; Mon, 22 Jan 2001 17:20:36 -0500 Date: Mon, 22 Jan 2001 17:24:46 -0500 (EST) From: Felix-Antoine Paradis To: "Daniel C. Sobral" Cc: Subject: Re: PPPoE In-Reply-To: <3A6C48E3.493F5161@newsguy.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 would say... options NETGRAPH options NETGRAPH_PPPOE options NETGRAPH_SOCKET That's it. recompile and conf'd your pppd. On Mon, 22 Jan 2001, Daniel C. Sobral wrote: > Felix-Antoine Paradis wrote: > > > > To get pppoe to work, just set the options in the kernel and use a good > > config (ppp.conf) and use pppd. > > Kernel options are bad for a number of reasons, not the least of them > the inability to do network installs (I mean, you have ADSL and get > restricted to cd installs?). Anyway... what _are_ the kernel options? > > -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > capo@a.crazy.bsdconspiracy.net > > "There is no spoon." -- Kiki > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Felix-Antoine Paradis . cell: 1-418-261-0865 . . IRC: reel @ DALnet . job: Idemnia Network . . Email: reel@sympatico.ca . *** 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 Jan 22 15:18:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 788D837B6B8; Mon, 22 Jan 2001 15:18:02 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id f0MNIdU19899; Mon, 22 Jan 2001 23:18:39 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id f0MNKl104853; Mon, 22 Jan 2001 23:20:47 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200101222320.f0MNKl104853@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Julian Elischer Cc: Felix-Antoine Paradis , "Daniel C. Sobral" , hackers@FreeBSD.ORG, brian@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: PPPoE In-Reply-To: Message from Julian Elischer of "Mon, 22 Jan 2001 08:52:28 PST." <3A6C654C.F14FA457@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jan 2001 23:20:47 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think the best way to implement this is some sort of config message = to the pppoe node (before the connect/listen). The NETGRAPH version = of ppp(8) is capable of doing ``chat scripts'' with netgraph nodes, = so it's fairly easy to configure the node configuration conversation... Hopefully now that Christmas is over I'll be able to get back to = netgraph'ifying ppp :-) > Felix-Antoine Paradis wrote: > > = > > To get pppoe to work, just set the options in the kernel and use a go= od > > config (ppp.conf) and use pppd. > > = > > On Mon, 22 Jan 2001, Daniel C. Sobral wrote: > > = > > > It seems I need the following parameters to get my PPPoE to work. C= ould > > > we have these options, please? > > > > > > >> -f disc:sess > > > >> The -f option sets the Ethernet frame types for > > > >> PPPoE discovery and session frames. The types are > > > >> specified as hexadecimal numbers separated by a > > > >> colon. Standard PPPoE uses frame types 8863:8864. > > > >> You should not use this option unless you are abso=A1 > > > >> lutely sure the peer you are dealing with uses non- > > > >> standard frame types. If your ISP uses non-stan=A1 > > > >> dard frame types, complain! > = > Definitly complain! This is equivalent to calling a protocol tcp/ip > but using a first byte in the packet. > I will look at a configuration message for the netgraph node > but Brian will hav eto work out how to send it, and where the > configuration parameter should be set to do this.. > = > The other possibility is a sysctl. > = > = > > > >> -S service_name > > > >> Specifies the desired service name. pppoe will > > > >> only initiate sessions with access concentrators > > > >> which can provide the specified service. In most > > > >> cases, you should not specify this option. Use it > > > >> only if you know that there are multiple access > > > >> concentrators or know that you need a specific ser=A1 > > > >> vice name. > = > = > If you are talking about the netgraph based pppoe, then -xxx type = > flags are not how you configure it. I think you are talking about > the (rather inefficient) userland ppp daemon. > = > the service name requested is already an argument in the pppoe = > configuration. > = > "If a PPPoE:iface[:provider] specification is given, ppp will at- > tempt to create a PPP over Ethernet connection using the given > iface interface by using netgraph(4). " > = > In this case the "provider" is the service name. > = > = > -- = > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ from Perth, presently in: Budapest > v -- = Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 15:25:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ruhr.de (in-ruhr3.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id 1DDC537B6B8 for ; Mon, 22 Jan 2001 15:24:53 -0800 (PST) Received: (qmail 7319 invoked by alias); 23 Jan 2001 00:35:54 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.0/8.11.0) id f0MN3dj77264 for hackers@FreeBSD.ORG; Tue, 23 Jan 2001 00:03:39 +0100 (CET) (envelope-from ue) Date: Tue, 23 Jan 2001 00:03:39 +0100 From: Udo Erdelhoff To: hackers@FreeBSD.ORG Subject: Re: PPPoE Message-ID: <20010123000339.A37967@nathan.ruhr.de> References: <3A6C48E3.493F5161@newsguy.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 reel@idemnia.ath.cx on Mon, Jan 22, 2001 at 05:24:46PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 05:24:46PM -0500, Felix-Antoine Paradis wrote: > I would say... > > options NETGRAPH > options NETGRAPH_PPPOE > options NETGRAPH_SOCKET add NETGRAPH_ETHER for 4.2 and above. /s/Udo -- Eat the rich -- the poor are tough and stringy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 15:40:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DA35B37B6A5 for ; Mon, 22 Jan 2001 15:40:09 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MNdu913510; Mon, 22 Jan 2001 16:39:56 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222339.f0MNdu913510@harmony.village.org> To: dan@langille.org Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Cc: FreeBSD Current Users In-reply-to: Your message of "Mon, 22 Jan 2001 22:10:28 +1300." <200101220910.WAA24873@ducky.nz.freebsd.org> References: <200101220910.WAA24873@ducky.nz.freebsd.org> Your message of "Thu, 18 Jan 2001 10:13:15 +0200." <20010118101315.A10537@rapier.smartspace.co.za> Date: Mon, 22 Jan 2001 16:39:56 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101220910.WAA24873@ducky.nz.freebsd.org> "Dan Langille" writes: : http://www.freebsd.org/handbook/kernelconfig-building.html This change should do the trick if I'm reading things right. Warner Index: chapter.sgml =================================================================== RCS file: /home/imp/FreeBSD/CVS/doc/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml,v retrieving revision 1.36 diff -u -r1.36 chapter.sgml --- chapter.sgml 2000/08/10 02:09:18 1.36 +++ chapter.sgml 2001/01/22 23:20:48 @@ -167,8 +167,8 @@ following commands: &prompt.root; cd /usr/src -&prompt.root; make buildkernel KERNEL=MYKERNEL -&prompt.root; make installkernel KERNEL=MYKERNEL +&prompt.root; make buildkernel KERNCONF=MYKERNEL +&prompt.root; make installkernel KERNCONF=MYKERNEL If you have not upgraded your source tree in any way (you have not run CVSup, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 15:59:15 2001 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 7A59E37B402 for ; Mon, 22 Jan 2001 15:58:58 -0800 (PST) Received: from jade (jade.cs.binghamton.edu [128.226.140.161]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f0MNwvR18748 for ; Mon, 22 Jan 2001 18:58:57 -0500 (EST) Date: Mon, 22 Jan 2001 18:58:55 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@jade To: freebsd-hackers@freebsd.org Subject: kernel debugging help 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 am debugging a kernel. Since a kernel is consisted of many files, how can I load a specific file into gdb, browse it, and set a break point at some line within that file? Right now, I can only view the file whose statements are being executed. Thanks. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 17:32:32 2001 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 7599C37B400 for ; Mon, 22 Jan 2001 17:32:15 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id CAA74755; Tue, 23 Jan 2001 02:32:10 +0100 (CET) (envelope-from 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: Jos Backus Cc: hackers@FreeBSD.ORG Subject: Re: Possible bug in /usr/bin/makewhatis References: <20010122141716.A82292@lizzy.bugworks.com> From: Dag-Erling Smorgrav Date: 23 Jan 2001 02:32:10 +0100 In-Reply-To: Jos Backus's message of "Mon, 22 Jan 2001 14:17:16 -0800" Message-ID: Lines: 8 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 Jos Backus writes: > This patch gets rid of the Broken pipe messages. No need to name the loop... 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 Mon Jan 22 18:17:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 93BB737B400; Mon, 22 Jan 2001 18:16:50 -0800 (PST) Received: from bellatlantic.net (client-151-198-135-12.nnj.dialup.bellatlantic.net [151.198.135.12]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id VAA22152; Mon, 22 Jan 2001 21:16:43 -0500 (EST) Message-ID: <3A6CE98B.4EA9EB9B@bellatlantic.net> Date: Mon, 22 Jan 2001 21:16:43 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Doug Barton Cc: cvs-committers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To mention it from the start, I've backed out my changes. (Yes, the pre-backed-out version was the one with the old behavior enabled by default and changed behavior enabled by an option). Doug Barton wrote: > > On Sun, 21 Jan 2001, Sergey Babkin wrote: > > > Doug Barton wrote: > > > > > > This needs to be backed out immediately. This isn't even close to what was > > > discussed in -hackers. After LONG, often pointless discussion, the > > > following points were agreed to there. > > > > Could you please look at the changes first ? The changes I > > committed are _not_ those from NetBSD. > > So instead of following what was agreed to on -hackers you went > off on your own and committed something totally different? This is worse > than I thought. Gerhard Sittig did test the changes from NetBSD and found that they do not quite solve the DST problem. That means that some other way of handling the DST changes should be used. I proposed such a way. > > My changes do not try > > to cover all the cases of skipped minutes but are specifically > > for the change of DST and actually take many precautions to avoid > > messing with the other cases. > > ... which makes the POLA violation worse instead of better. When > we tell people that our cron handles DST changes, the people who live in > areas where the change is not exactly one hour happening at :00 will > not hear the disclaimer that they are, "out of luck," as you put it. Yes, I agree that this is not good. Though considering that practically all the world except Kirgizia and two smaller islands near Australia falls into the lucky category, this is not that bad. I think I see a reasonably easy way to fix it now. > > On the points: > > > > > Gerhard Sittig wrote: > > > > I take notice of your (and Greg Black's) reservation / being > > > > opposed, respect it and conclude that the change will have to > > > > - default to the current behaviour (something quite usual for > > > > expanding changes) > > > > The behavior is quite close to the current one, differing for > > only the jobs running less frequently than every hour when of course they hit the DST change frame, and different in a rather safe way. > > For a definition of "safe" that is entirely inadequate. In the traditional way strange things happen to the jobs scheduled between 1am and 3am (for Europe/US, time may differ for other time zones) at the DST changes. In the changed way other things happen which are somewhat less strange. That sounds very much like "safe". > > > > - yet be enabled easily for those interested in the change to > > > > work for them and free up some of their resources for more > > > > important tasks > > > > - maybe provide knobs (besides the on-off-switch) to customize > > > > behaviour in a more fine grained way > > > > All the discussion in the thread was about that sysadmins must > > not schedule jobs at 2:00-2:59 AM time (and actually 1:00-1:59 > > as well to avoid duplication though somehow nobody mentioned it). > > If no jobs are scheduled at this interval, then the behavior > > of the cron with my changes is absolutely identical to the > > old one. > > That is certainly NOT the only discussion. I made the point > several times that someone who schedules a time critical job during the > DST change period will have a huge problem if their job is unexpectedly > run without sufficient time to finish, or There are other things which may not allow a job to finish in a predefined time slot. For example, other operations going on and consuming CPU, disk or network bandwidth. So presuming that a job would finish by some time is inherently unsafe. The safe way is to put both jobs sequentially into one script and run this one script from cron. And of course there is a very good chance that the problem would be exactly the same or worse if the job does not run at all, what happens with the traditional implementation. > what is frequently worse their > job is run twice. That's what happens now at switch from 1am DST to 1am ST - all the jobs in the interval 1:00-1:59 run the second time. And that's a part of what my change prevents. > The proponents of the change responded by saying that > you shouldn't schedule time critical jobs during this period, to which I > replied that if you can solve the problem other ways then there is no need > to modify cron. Time critical jobs should be avoided at all, by including all the dependent jobs into one script and running only this script from cron. There is no reason why the DST-dependent period is worse for this purpose than any other one. > What I object to about making this the default is that you are > effectively programming to the lowest common denominator, assuming from > the start that people are too stupid to schedule their jobs properly, > therefore we must fix them in ways that potentially break cron for people > who expect the well established behavior. I'm trying to say that I do not exactly see how changing this denominator would make life worse for "not too stupid people". However I see how it can make life better for the "too stupid people". Also many of the "not too stupid people" just have never met this behavior before because purely by occasion they've never scheduled the jobs at the troubled intervals. So for them the current behavior is not something to cling to and I believe they would prefer to never discover it. I can give you one example from my past experience: a nightly cold backup of a database which takes a long time, must be started after all the day's work would be complete, and finish by 7:30AM the next morning. The time of backup depends on the amount of change logs generated during the day, so to be safe it should be started as early as possible. Well, eventually we got the day's close processing to complete by 12:50 and scheduled the job there. But the fact that two hours of time are unusable for starting any jobs is not a particularly exciting one nor fun to discover. > > > I made the additional point that the options should be command line > > > options, instead of environment variables as someone else suggested. > > > > And I made the additional point that practically all the commercial > > Unixes do support intelligent handling of DST. Being different > > from them makes no good and is a lot of inconvenience. > > If you want to offer the option of making cron think for the user > instead of following traditional behavior then it should be offered as a > command line option, defaulting to off. Period. "We're not like everyone > else" is not a compelling argument here. This sort of arguments is largely responsible for why Unix had branched in so many incompatible ways. The NIH syndrome is not the most productive approach. > > I also have a feeling that these agreed points were agreed only by > > the proponents of keeping the traditional behavior, practically > > ignoring anyone with a different opinion. > > You are in fact 100% wrong. I was careful to quote the summary of > agreed points from Gerhard Sittig's e-mail, who is the original proponent > of the change in the first place. He asked for discussion on the change > and agreed readily after several people spoke up saying that the new > behavior should be an option. It's only partially so. The discussion was rather one-way, with much vocality from the opponents of the change and not much technical arguments. Also the discussion was about different kind of changes, which not only change the behavior of once-a-day jobs in the DST switch timeframe but also affect the jobs running at hourly and sub-hourly intervals enclosing this timeframe and all the jobs get affected by the time changes, and this discussed kind of change is a more dangerous one than I did. I agree that an option is a resonable solution and although I believe that making the changed behavior default is technically better, I do not really mind making the traditional behavior the default. > You need to back out your changes and let the people who are > proposing a more complete solution which has been widely discussed and > agreed to have time to finish their work and send it to -arch for more a) as far as I can see, no more complete solution is proposed b) I don't see any implementations of these proposals either c) the next DST time change would be in about two months from now and it would be really good to do something with this issue before then > discussion. Your drive-by commit out of the blue of something that doesn't Once again, I've described this change in -hackers before implementing it. If you ignored that description, that does not mean that the change comes out of the blue. > come close to what even the people who want the time-skewing behavior are > proposing is wrong on many levels. I agree with the critique of the time zone switch time limitation but on the main meaning of changes you still did not give much technical arguments nor any example showing where the behavior of my changes would be worse than the traditional one. I'd like to see this critique. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 18:38:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id BA3F937B402 for ; Mon, 22 Jan 2001 18:38:23 -0800 (PST) Received: from bellatlantic.net (client-151-198-135-12.nnj.dialup.bellatlantic.net [151.198.135.12]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id VAA22413; Mon, 22 Jan 2001 21:37:56 -0500 (EST) Message-ID: <3A6CEE84.21B5676F@bellatlantic.net> Date: Mon, 22 Jan 2001 21:37:56 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Matt Dillon Cc: Greg Black , Neil Blakey-Milner , John Gregor , Gerhard.Sittig@gmx.net, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) References: <200101140244.f0E2i3518278@vieo.com> <3A621ABF.FA2C6432@bellatlantic.net> <200101142155.f0ELtLO64117@earth.backplane.com> <3A6A059C.486F6237@bellatlantic.net> <20010120235412.A42508@rapier.smartspace.co.za> <3A6B3D85.9773C9ED@bellatlantic.net> <3A6B68E9.278A6BBB@bellatlantic.net> <200101212332.f0LNWun16287@earth.backplane.com> <3A6B82F5.43CA6A65@bellatlantic.net> <200101220635.f0M6ZbJ17648@earth.backplane.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon wrote: > > :> with your rather large diff set. For better or for worse, people > :> already know about the daylight savings shift problem. Thousands > :> of people depend on cron to work, which means that when you > :> make a major change like this it must be tested by a wider audience > :> for a longer time before becoming the default. It needs to have some > :> real-life operational experience behind it. > : > :This can be applied to whole FreeBSD just as well. And IMHO > :cron is less critical than any part of the kernel, yet changes > :to the kernel don't usually bring such a strong reaction. > > I think you have a valid argument in regards to cron vs the kernel. > But keep in mind that even though you are fixing a 'bug', it's a well > known 'bug' so you are in fact creating an operational change to the > code rather then just a bug fix or minor performance enhancement, etc... Yes, I understand that and I tried to make the change maximally compatible with the existing behavior. Even with all this I agree that making this change optional is a yet safer approach and by now I feel quite sorry that I did not take it from the start. > When I do major kernel work, it's usually tested by third parties for > a week or two. The last three major commits I've done had been under > test for three weeks (don't let the 2-5 day MFC fool you, I have to > do all my work on -stable first, then forward port to -current, then > MFC back to -stable). I never intended to MFC it immediately, that's why I said "in a few weeks" thus implying something like a month or so, possibly more. Also this change is not quite a major one. > :> This is broken. If you want to check for a DLS change there is only > :> one right way to do it, and that is to compare the wall clock > :> differential verses the GMT differential, and to not put in any silly > : > :I disagree. Checking the difference from GMT creates a danger > :of misrecognition of a time zone change (for example, when > :a machine was physically moved) for a DST switch. So comparing > :is_dst is the only reliable way to tell if there actually was > :such a switch. > > I don't consider someone changing the machine's /etc/localtime zone > to be an issue, since it rarely if ever happens. And if a machine is > moved, it's likely to be powered down anyway.... cron is not going to > nor is it supposed to 'catch up' after downtime. Additionally, cron > cannot detect a timezone change without being restarted, so the point > is moot anyhow. Agreed, this did not occur to me at once. Actually, after some thinking I see a reason why the difference from GMT may change without changing the DST state: if the country adopts different offset for its time zones, then the zoneinfo file would be updated in advance and cron would discover it on time. So comparing the difference really is the right way. And I think I see a simple way to do that and handling of arbitrary offsets as well. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 18:56: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 0FD3A37B401 for ; Mon, 22 Jan 2001 18:55:51 -0800 (PST) Received: from bellatlantic.net (client-151-198-135-12.nnj.dialup.bellatlantic.net [151.198.135.12]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id VAA22593; Mon, 22 Jan 2001 21:55:33 -0500 (EST) Message-ID: <3A6CF2A4.ABEBD306@bellatlantic.net> Date: Mon, 22 Jan 2001 21:55:32 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Greg Black Cc: dan@langille.org, freebsd-hackers@FreeBSD.ORG Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etccrontab) References: <200101212035.JAA19266@ducky.nz.freebsd.org> <3A6B85B2.3A10195C@bellatlantic.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Black wrote: > > Sergey Babkin wrote: > > > It still can be backed out. > > Well, what are you waiting for? Back it out. Listen to what > people are saying and then maybe propose something that takes > into account their concerns. I wanted to get a confirmation from Doug Barton that he still considers the changes unacceptable even after looking at them. Demanding the changes backed out without even looking at them does not strike me as a very good way of conducting a technical discussion. > To make this point a little more clearly -- the fact that Matt > Dillon, who is no fool, and you have wildly divergent ideas on > the appropriate/correct method to determine when to do things is > further evidence (as if any were needed) that this is not a > trivial thing to get right. First, people have to agree on what > is right and we're not there yet. > > Please take note of what people are saying, stop the silly > protests about your failure to be convinced by other people's > arguments, and recognise that you don't have a special line to > the One True Way. I never mentioned that I know this One True Way. I'm still not convinced but I've backed out the changes anyway. Yet I'd still like to see the discussion of technical merits of keeping the traditional behavior. > Finally, in reference to the confusion over POLA, get something > straight: the people we must take most care not to astonish are > current users of FreeBSD; after them, we can consider users who > are migrating from other Unix variants. The fact that others > may do things differently is not, of itself, an argument to take > a wild jump into the darkness here. I agree that random changes are bad. What I'm trying to say is that the current FreeBSD users most probably divided into two classes: 1) Those who know about the DST switch issues. For them POLA works as you say but they would probably avoid the 1:00-2:59am timeframe and thus would not be affected by the changes. 2) Those who don't know about this issue (speaking in Doug's words, those "too stupid") - they don't care for now but if some day they schedule a cron job in this timeframe, for them POLA would work the other way, and with the traditional behavior they are going to learn a harder lesson. Some people who use both FreeBSD and some other Unix may get into the second category as well. > The continued, predictable, behaviour of cron is important to > users and cannot be just played about with at your whim, and > this is especially true when you don't even have support for the > so-called solution you have proposed. As far as I can see, I do have some support. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 19:16:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from isis.uniandes.edu.co (isis.uniandes.edu.co [157.253.54.5]) by hub.freebsd.org (Postfix) with ESMTP id 43FB637B401; Mon, 22 Jan 2001 19:16:15 -0800 (PST) Received: from yahoo.com (LIsdn147.uniandes.edu.co [157.253.30.88]) by isis.uniandes.edu.co (8.11.0/8.11.0) with ESMTP id f0N3EcF10969; Mon, 22 Jan 2001 22:14:41 -0500 (GMT+5) Message-ID: <3A6CF781.C9C2871A@yahoo.com> Date: Mon, 22 Jan 2001 22:16:17 -0500 From: "Yonny Cardenas B." Organization: Universidad de los Andes X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: questions@FreeBSD.org, hackers@FreeBSD.org Subject: Kernel programming Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello I am adding a set the new system calls to FreeBSD kernel, but to compile and to test new source code within the kernel is a little hard when there is some problem. Is there anybody knows some reference (URL), tools or some help to programming and debugging in the kernel FreeBSD? That is some suggestions, examples, etc., different to kernel?s source code of course. Thanks. +------------------------------------------------------------------+ | YONNY CARDENAS B. Apartado Aereo 22828 | | Systems Engineer Santafe de Bogota D.C. | | Colombia - South America | | Student M.Sc. Tel: +571 6095477 | | UNIVERSIDAD DE LOS ANDES mailto: y-carden@uniandes.edu.co | | ycardena@computer.org | | http://www.geocities.com/ycardena | +------------------------------------------------------------------+ UNIX is BSD, and FreeBSD is an advanced 4.4BSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 20:28:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by hub.freebsd.org (Postfix) with ESMTP id 028F437B401; Mon, 22 Jan 2001 20:28:15 -0800 (PST) Received: from tim.elnsng1.mi.home.com (c1129767-a.elnsng1.mi.home.com [24.183.248.20]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id XAA14142; Mon, 22 Jan 2001 23:28:12 -0500 (EST) From: Tim McMillen To: "Yonny Cardenas B." , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Kernel programming Date: Mon, 22 Jan 2001 23:32:09 -0500 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" References: <3A6CF781.C9C2871A@yahoo.com> In-Reply-To: <3A6CF781.C9C2871A@yahoo.com> MIME-Version: 1.0 Message-Id: <01012223320902.12411@tim.elnsng1.mi.home.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are you looking for something more than: http://www.freebsd.org/handbook/kerneldebug.html I don't know if there is any. There are a fair amount of undocumented system calls in the FreeBSD kernel as I understand it. Chapter 22 of the handbook may be helpful too. There may also be some articles in say daemonnews or something, but basically the source code is going to be what you'll have to go on. Tim On Monday January 22, 2001 22:16, Yonny Cardenas B. wrote: > Hello > > I am adding a set the new system calls to FreeBSD kernel, > but to compile and to test new source code within the kernel > is a little hard when there is some problem. > > Is there anybody knows some reference (URL), tools or some help > to programming and debugging in the kernel FreeBSD? > That is some suggestions, examples, etc., different to > kernel?s source code of course. > > Thanks. > > +------------------------------------------------------------------+ > > | YONNY CARDENAS B. Apartado Aereo 22828 | > | Systems Engineer Santafe de Bogota D.C. | > | Colombia - South America | > | Student M.Sc. Tel: +571 6095477 | > | UNIVERSIDAD DE LOS ANDES mailto: y-carden@uniandes.edu.co | > | ycardena@computer.org | > | http://www.geocities.com/ycardena | > > +------------------------------------------------------------------+ > UNIX is BSD, and FreeBSD is an advanced 4.4BSD > > > 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 Jan 22 21:15:57 2001 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 D997C37B401 for ; Mon, 22 Jan 2001 21:15:33 -0800 (PST) Received: (qmail 55337 invoked by uid 1001); 23 Jan 2001 15:15:21 +1000 X-Posted-By: GJB-Post 2.11 18-Jan-2001 X-Operating-System: FreeBSD 4.1-RELEASE i386 X-URL: http://www.gbch.net X-Image-URL: http://www.gbch.net/gjb/img/gjb-auug048.gif X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 X-PGP-Public-Key: http://www.gbch.net/gjb/gjb-pgpkey.asc Message-Id: Date: Tue, 23 Jan 2001 15:15:21 +1000 From: Greg Black To: Sergey Babkin Cc: Doug Barton , cvs-committers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h References: <3A6CE98B.4EA9EB9B@bellatlantic.net> In-reply-to: <3A6CE98B.4EA9EB9B@bellatlantic.net> of Mon, 22 Jan 2001 21:16:43 EST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergey Babkin wrote: > To mention it from the start, I've backed out my changes. Thank you. > There are other things which may not allow a job to finish in > a predefined time slot. For example, other operations going on > and consuming CPU, disk or network bandwidth. So presuming > that a job would finish by some time is inherently unsafe. > The safe way is to put both jobs sequentially into one script > and run this one script from cron. Remember that for later. > Time critical jobs should be avoided at all, by including all the > dependent jobs into one script and running only this script > from cron. And remember that while you read this: > I can give you one example from my past experience: a nightly cold > backup of a database which takes a long time, must be started after > all the day's work would be complete, and finish by 7:30AM the next > morning. The time of backup depends on the amount of change logs > generated during the day, so to be safe it should be started as > early as possible. Well, eventually we got the day's close > processing to complete by 12:50 and scheduled the job there. > But the fact that two hours of time are unusable for starting > any jobs is not a particularly exciting one nor fun to discover. This is an absurd claim, especially in the light of what you said earlier (quoted above). If the backup depends on the processing of something else, then the script that starts the other processing should run the backup at the end, and issues of DST are completely irrelevant. This has always been the case, and still is. You keep demanding technical arguments (which I think means arguments about the content of the proposed changes) -- but the matter of concern to me is /not/ that at all, it's whether there is any need for potentially breaking an important utility which has known behaviour to "solve" things that don't need and are not suited to technical solutions, no matter who else might think that is the way to go. Arguing that commercial Unix vendors have decided to meet the lowest common denominator by changing cron is not a case for FreeBSD to go down the same road. > > > > I made the additional point that the options should be command line > > > > options, instead of environment variables as someone else suggested. > > > > > > And I made the additional point that practically all the commercial > > > Unixes do support intelligent handling of DST. Being different > > > from them makes no good and is a lot of inconvenience. > > > > If you want to offer the option of making cron think for the user > > instead of following traditional behavior then it should be offered as a > > command line option, defaulting to off. Period. "We're not like everyone > > else" is not a compelling argument here. > > This sort of arguments is largely responsible for why Unix had > branched in so many incompatible ways. The NIH syndrome is not > the most productive approach. A certain TLA once came out with their own Unix (known by another TLA) and I had the joy of working with beta versions of this OS. Thousands of things just didn't work, including dozens of awk scripts. It turned out that the company had "audited" the awk code and "fixed" it to comply with their in-house coding standards. Just because other people do something is not of itself a compelling argument to follow suit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 22 23:44:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 44A2437B400 for ; Mon, 22 Jan 2001 23:44:28 -0800 (PST) Received: (qmail 89119 invoked by uid 1000); 23 Jan 2001 07:44:48 -0000 Date: Mon, 22 Jan 2001 23:44:26 -0800 From: Jos Backus To: hackers@FreeBSD.ORG Subject: Re: Possible bug in /usr/bin/makewhatis Message-ID: <20010122234426.A87598@lizzy.bugworks.com> Reply-To: Jos Backus References: <20010122141716.A82292@lizzy.bugworks.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 des@ofug.org on Tue, Jan 23, 2001 at 02:31:48AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 02:31:48AM +0100, Dag-Erling Smorgrav wrote: > No need to name the loop... Oops, you're right, sorry. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 0:38:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 824) id B8FB037B69C; Tue, 23 Jan 2001 00:37:56 -0800 (PST) Date: Tue, 23 Jan 2001 00:37:56 -0800 To: "Yonny Cardenas B." Cc: questions@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Kernel programming Message-ID: <20010123003756.A33892@hub.freebsd.org> Mail-Followup-To: alex@hub.freebsd.org, "Yonny Cardenas B." , questions@FreeBSD.org, hackers@FreeBSD.org References: <3A6CF781.C9C2871A@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6CF781.C9C2871A@yahoo.com>; from ycardena@yahoo.com on Mon, Jan 22, 2001 at 10:16:17PM -0500 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@FreeBSD.ORG (Alexander Langer) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Yonny Cardenas B. (ycardena@yahoo.com): > Is there anybody knows some reference (URL), tools or some help > to programming and debugging in the kernel FreeBSD? Try http://www.freebsd.org/tutorials/ Andrew W. Reiter has written a nice kernel mod tutorial. There recently (last week or something) was a thread here or on another mailinglist on how to debug kernel moduls, which is a little bit tricky. Just search the archives. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 1:12:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 15DC037B401 for ; Tue, 23 Jan 2001 01:12:31 -0800 (PST) Received: from xeon (xeon.unixathome.org [192.168.0.18]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with SMTP id WAA00300; Tue, 23 Jan 2001 22:12:23 +1300 (NZDT) Message-Id: <200101230912.WAA00300@ducky.nz.freebsd.org> To: Warner Losh Cc: FreeBSD Current Users From: Dan Langille Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Date: Tue, 23 Jan 2001 09:12:24 GMT X-Mailer: Endymion MailMan Professional Edition v3.0.29 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks. I'll use that for starters. I still think that part of the handbook needs to be modified, along the lines of my original patch but excluding the different build patterns, just to stop the confusion. I won't be able to submit a PR for a few days. So if anyone wants to jump in, my old PR is can still be found. Look for submitter = my name. Otherwise, it'll be the weekend before I have time. > In message <200101220910.WAA24873@ducky.nz.freebsd.org> "Dan Langille" writes: > : http://www.freebsd.org/handbook/kernelconfig-building.html > > This change should do the trick if I'm reading things right. > > Warner > > Index: chapter.sgml > =================================================================== > RCS file: /home/imp/FreeBSD/CVS/doc/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml,v > retrieving revision 1.36 > diff -u -r1.36 chapter.sgml > --- chapter.sgml 2000/08/10 02:09:18 1.36 > +++ chapter.sgml 2001/01/22 23:20:48 > @@ -167,8 +167,8 @@ > following commands: > > &prompt.root; cd /usr/src > -&prompt.root; make buildkernel KERNEL=MYKERNEL > -&prompt.root; make installkernel KERNEL=MYKERNEL > +&prompt.root; make buildkernel KERNCONF=MYKERNEL > +&prompt.root; make installkernel KERNCONF=MYKERNEL > > If you have not upgraded your source > tree in any way (you have not run CVSup, > --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 3:17:14 2001 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 A9BD137B699; Tue, 23 Jan 2001 03:16:50 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA76979; Tue, 23 Jan 2001 12:16:49 +0100 (CET) (envelope-from 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: alex@FreeBSD.ORG (Alexander Langer) Cc: "Yonny Cardenas B." , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Kernel programming References: <3A6CF781.C9C2871A@yahoo.com> <20010123003756.A33892@hub.freebsd.org> From: Dag-Erling Smorgrav Date: 23 Jan 2001 12:16:48 +0100 In-Reply-To: alex@FreeBSD.ORG's message of "Tue, 23 Jan 2001 00:37:56 -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 alex@FreeBSD.ORG (Alexander Langer) writes: > There recently (last week or something) was a thread here or on > another mailinglist on how to debug kernel moduls, which is a little > bit tricky. It's also documented in the handbook. 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 Jan 23 3:21:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16]) by hub.freebsd.org (Postfix) with ESMTP id 6355237B699; Tue, 23 Jan 2001 03:21:05 -0800 (PST) Received: from fwd07.sul.t-online.com by mailout00.sul.t-online.com with smtp id 14L1VY-0001IY-00; Tue, 23 Jan 2001 12:21:04 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.158.39.148]) by fmrl07.sul.t-online.com with esmtp id 14L1VW-1oRtzsC; Tue, 23 Jan 2001 12:21:02 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 70841AB0C; Tue, 23 Jan 2001 12:23:04 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id DF5C414BB9; Tue, 23 Jan 2001 12:20:56 +0100 (CET) Date: Tue, 23 Jan 2001 12:20:56 +0100 From: Alexander Langer To: Dag-Erling Smorgrav Cc: "Yonny Cardenas B." , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Kernel programming Message-ID: <20010123122056.A8416@cichlids.cichlids.com> Mail-Followup-To: Alexander Langer , Dag-Erling Smorgrav , "Yonny Cardenas B." , questions@FreeBSD.ORG, hackers@FreeBSD.ORG References: <3A6CF781.C9C2871A@yahoo.com> <20010123003756.A33892@hub.freebsd.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 des@ofug.org on Tue, Jan 23, 2001 at 12:16:48PM +0100 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Dag-Erling Smorgrav (des@ofug.org): > > There recently (last week or something) was a thread here or on > > another mailinglist on how to debug kernel moduls, which is a little > > bit tricky. > It's also documented in the handbook. Well, actually debugging modules is a little bit more tricky than debugging kernels with statically linked drivers. This is what I meant. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 3:26:54 2001 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 3F2CF37B699; Tue, 23 Jan 2001 03:26:32 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA77034; Tue, 23 Jan 2001 12:26:31 +0100 (CET) (envelope-from 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: Alexander Langer Cc: "Yonny Cardenas B." , questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Kernel programming References: <3A6CF781.C9C2871A@yahoo.com> <20010123003756.A33892@hub.freebsd.org> <20010123122056.A8416@cichlids.cichlids.com> From: Dag-Erling Smorgrav Date: 23 Jan 2001 12:26:30 +0100 In-Reply-To: Alexander Langer's message of "Tue, 23 Jan 2001 12:20:56 +0100" 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 Alexander Langer writes: > Thus spake Dag-Erling Smorgrav (des@ofug.org): > > Alexander Langer writes: > > > There recently (last week or something) was a thread here or on > > > another mailinglist on how to debug kernel moduls, which is a little > > > bit tricky. > > It's also documented in the handbook. > Well, actually debugging modules is a little bit more tricky than > debugging kernels with statically linked drivers. It's still documented in the handbook. I don't see where you find a contradiction here. 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 Jan 23 10:58:30 2001 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 EA89837B401 for ; Tue, 23 Jan 2001 10:58:12 -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 OAA63184 for ; Tue, 23 Jan 2001 14:00:10 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010123140404.036a2100@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 23 Jan 2001 14:05:53 -0500 To: hackers@freebsd.org From: Dennis Subject: Re: if_fxp driver info 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 01:38 PM 12/19/2000, David Greenman wrote: > >> Your stupidity is also is emphasized by the fact that no major > manufacturer > >> has supported drivers for freebsd. Intel wont even help by providing > docs. > >> Bravo. What a WIN for the freebsd community. You've done a tremendous job > >> marketing your concept. > > > >So that's why Intel provides free bound copies of their IA-64 books and > PDF's > >of the other chip manuals, PXE manuals, etc. I guess all those data sheets > >I've seen Bill Paul pore over while working on his ethernet drivers were > just > >figments of my imagination as well. > > I think he's refering to the 82559 manual. It is available from Intel to >developers, but only with an NDA. For various reasons, I can't sign an NDA >for that information without putting myself in legal jeopardy. That has always >been true, but I was able to obtain the [now older] 82557 manual without an >NDA due to a screwup at Intel - which allowed me to write the original fxp >driver. Unfortunately, a few things have changed since then, especially in >the SEEPROM area and the only method I have of fixing those problems these >days is by reverse-engineering. The 82559 manual is available online, as is a full driver with source for the eepro100 board for linux written by intel. I guess they changed their policy on the part. I've tested the linux driver with the new part on the supermicro board and it works, so the driver is reasonably up to date. It would seem that all of the answers needed are in one of the 2, but without knowing much about the controller at this point, its all a bit cryptic to me. Its seems that there are some extensions for the 82558 and 82559 parts which is probably the problem. http://developer.intel.com/design/network/products/lan/controllers/82559.htm I spent a couple of hours on it but its a substantial learning curve to learn the part to fix what is most likely a small problem. Perhaps someone else has more time than I do. . Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 11:15:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 2682937B400 for ; Tue, 23 Jan 2001 11:15:34 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0NJUwS01334; Tue, 23 Jan 2001 11:30:58 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101231930.f0NJUwS01334@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Dennis Cc: hackers@freebsd.org Subject: Re: if_fxp driver info In-reply-to: Your message of "Tue, 23 Jan 2001 14:05:53 EST." <5.0.0.25.0.20010123140404.036a2100@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 11:30:58 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think he's refering to the 82559 manual. It is available from Intel to > >developers, but only with an NDA. For various reasons, I can't sign an NDA > >for that information without putting myself in legal jeopardy. That has always > >been true, but I was able to obtain the [now older] 82557 manual without an > >NDA due to a screwup at Intel - which allowed me to write the original fxp > >driver. Unfortunately, a few things have changed since then, especially in > >the SEEPROM area and the only method I have of fixing those problems these > >days is by reverse-engineering. > > The 82559 manual is available online, as is a full driver with source for > the eepro100 board for linux written by intel. The online manual for the 8255x parts is not adequate for driver development. There are a signficant number of critical items missing from it which would preclude you developing a driver based on the information it contains; this datasheet has been available in one form or another for some time and is generally regarded as almost useless. > I guess they changed their > policy on the part. I've tested the linux driver with the new part on the > supermicro board and it works, so the driver is reasonably up to date. The source-available Intel driver does actually look pretty good. I don't know why David has failed to track it wrt. PHY numbers. I've dumped the last board I had with an unrecognised PHY, so I don't have any incentive to poke him about it anymore. -- ... 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 Jan 23 11:29:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nyapp002.mediaondemand.com (mailhost.mediaondemand.com [208.184.36.78]) by hub.freebsd.org (Postfix) with ESMTP id BFF2F37B402 for ; Tue, 23 Jan 2001 11:28:48 -0800 (PST) Received: from nywst536 (nywst536.newyork.mod [192.168.10.35]) by nyapp002.mediaondemand.com (8.11.2/8.11.2) with SMTP id f0NJSin22151 for ; Tue, 23 Jan 2001 14:28:48 -0500 (EST) Message-ID: <001701c08572$7d218a90$230aa8c0@newyork.mod> From: "Dejvid Zaninovic" To: Subject: IP Address Overtaking Date: Tue, 23 Jan 2001 14:27:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I could not find any non-commercial IP Address overtaking solution for FreeBSD so I wrote this simple shell script. If you find it useful you can use it. ----------- #!/usr/local/bin/ksh # # Node v0.01 # # purpose: # - very simple ip address overtaking for FreeBSD systems # - can be used as simple apache clustering solution if used # with mod_backhand # # tested to work on: # - FreeBSD v4.1.1 # - pdksh v5.2.14 # - fping v2.2b1 # # command line arguments: # - node_name: resolvable name of the virtual node # # instructions: # - configure config section in the script # - run the same scipt on two or more cluster nodes using nohup # - for more virtual nodes run same script many times # # signals: # - send INT or TERM signal to stop the virtual node # - send HUP signal to switch virtual node to another node, # if another node don't take over the virtual node in 5 seconds # virtual node is switched back # # versions: # # v0.01 - 01.19.2001 - Dejvid Zaninovic (dzaninov1@icqmail.com) # - initial version # # config section NETWORK_INTERFACE=xl0 TMPDIR=/tmp # command line arguments SCRIPT_NAME=$0 NODE_ADDRESS=$1 # global vars init NODE_ETHER=$(ifconfig $NETWORK_INTERFACE | grep ether | cut -d" " -f2) LOCKFILE=$TMPDIR/$SCRIPT_NAME.$NODE_ADDRESS.lock MASTER=false # functions usage() { print -u2 "usage: $SCRIPT_NAME node_name" exit 1 } node_up() { print $SCRIPT_NAME: $NODE_ADDRESS: up ifconfig $NETWORK_INTERFACE alias $NODE_ADDRESS netmask 0xffffffff arp -S $NODE_ADDRESS $NODE_ETHER pub > /dev/null 2>&1 } node_down() { if $MASTER then print $SCRIPT_NAME: $NODE_ADDRESS: down ifconfig $NETWORK_INTERFACE -alias $NODE_ADDRESS netmask 0xffffffff arp -d $NODE_ADDRESS > /dev/null 2>&1 route delete $NODE_ADDRESS > /dev/null 2>&1 fi } node_check() { fping -q $NODE_ADDRESS } node_kill() { node_down rm $LOCKFILE print $SCRIPT_NAME: $NODE_ADDRESS: exit exit 0 } node_switch() { print $SCRIPT_NAME: $NODE_ADDRESS: switch node_down sleep 5 } # main trap node_kill INT TERM trap node_switch HUP if [[ $# -ne 1 ]] then usage fi if [[ -f $LOCKFILE ]] then print -u2 "$SCRIPT_NAME: $NODE_ADDRESS node is already running" exit 1 fi touch $LOCKFILE print $SCRIPT_NAME: $NODE_ADDRESS: started while true do node_check if [[ $? -ne 0 ]] then MASTER=true node_up fi sleep 1 done To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 11:31:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id 232AA37B400 for ; Tue, 23 Jan 2001 11:31:25 -0800 (PST) Received: from xeon (xeon.unixathome.org [192.168.0.18]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with SMTP id IAA04345; Wed, 24 Jan 2001 08:31:07 +1300 (NZDT) Message-Id: <200101231931.IAA04345@ducky.nz.freebsd.org> To: Cc: freebsd-hackers@freebsd.org From: Dan Langille Subject: Re: IP Address Overtaking Date: Tue, 23 Jan 2001 19:31:07 GMT X-Mailer: Endymion MailMan Professional Edition v3.0.29 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG DZ wrote: > I could not find any non-commercial IP Address overtaking solution for > FreeBSD so I wrote this simple shell script. If you find it useful you can > use it. What is "IP Address overtaking"? --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 11:38:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nyapp002.mediaondemand.com (mailhost.mediaondemand.com [208.184.36.78]) by hub.freebsd.org (Postfix) with ESMTP id 6931137B400 for ; Tue, 23 Jan 2001 11:38:11 -0800 (PST) Received: from nywst536 (nywst536.newyork.mod [192.168.10.35]) by nyapp002.mediaondemand.com (8.11.2/8.11.2) with SMTP id f0NJc6n22834; Tue, 23 Jan 2001 14:38:06 -0500 (EST) Message-ID: <001f01c08573$c9b6d670$230aa8c0@newyork.mod> From: "Dejvid Zaninovic" To: Cc: Subject: RE: IP Address Overtaking Date: Tue, 23 Jan 2001 14:36:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What is "IP Address > overtaking"? It is a way to move IP address from one host to another, it is used for redundancy purposes. If one host goes down the second take over. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 11:38:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bdr-xcon.matchlogic.com (mail.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id 2538037B401 for ; Tue, 23 Jan 2001 11:38:40 -0800 (PST) Received: by mail.matchlogic.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 12:38:30 -0700 Message-ID: <5FE9B713CCCDD311A03400508B8B3013054E3E24@bdr-xcln.is.matchlogic.com> From: Charles Randall To: 'Dan Langille' , dzaninov@mediaondemand.com Cc: freebsd-hackers@freebsd.org Subject: RE: IP Address Overtaking Date: Tue, 23 Jan 2001 12:38:29 -0700 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 Server B takes over a virtual IP address of server A when server A fails. -----Original Message----- From: Dan Langille [mailto:dan@langille.org] Sent: Tuesday, January 23, 2001 12:31 PM To: dzaninov@mediaondemand.com Cc: freebsd-hackers@freebsd.org Subject: Re: IP Address Overtaking DZ wrote: > I could not find any non-commercial IP Address overtaking solution for > FreeBSD so I wrote this simple shell script. If you find it useful you can > use it. What is "IP Address overtaking"? --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 11:42:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 866DC37B400 for ; Tue, 23 Jan 2001 11:42:25 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0NJvRS01701; Tue, 23 Jan 2001 11:57:31 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101231957.f0NJvRS01701@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Dejvid Zaninovic" Cc: dan@langille.org, freebsd-hackers@FreeBSD.ORG Subject: Re: IP Address Overtaking In-reply-to: Your message of "Tue, 23 Jan 2001 14:36:31 EST." <001f01c08573$c9b6d670$230aa8c0@newyork.mod> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 11:57:27 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What is "IP Address > > overtaking"? > > It is a way to move IP address from one host to another, it is used for > redundancy purposes. If one host goes down the second take over. Commonly referred to as "IP failover". -- ... 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 Jan 23 12: 0:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id A21B337B401 for ; Tue, 23 Jan 2001 12:00:34 -0800 (PST) Received: from holly.calldei.com ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G7M0076MSKHQA@mta4.rcsntx.swbell.net> for hackers@FreeBSD.ORG; Tue, 23 Jan 2001 13:53:06 -0600 (CST) Received: (from chris@localhost) by holly.calldei.com (8.11.1/8.9.3) id f0NJrVk05216; Tue, 23 Jan 2001 13:53:31 -0600 (CST envelope-from chris) Date: Tue, 23 Jan 2001 13:53:24 -0600 From: Chris Costello Subject: Re: IP Address Overtaking In-reply-to: <001701c08572$7d218a90$230aa8c0@newyork.mod>; from dzaninov@mediaondemand.com on Tue, Jan 23, 2001 at 02:27:09PM -0500 To: Dejvid Zaninovic Cc: hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20010123135324.B776@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <001701c08572$7d218a90$230aa8c0@newyork.mod> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, January 23, 2001, Dejvid Zaninovic wrote: > I could not find any non-commercial IP Address overtaking solution for > FreeBSD so I wrote this simple shell script. If you find it useful you can > use it. Just a note: This script doesn't look like it implements anything that our own /bin/sh needs. Should somebody make this into a port, that's one less dependancy. -- +-------------------+------------------------------------------+ | Chris Costello | Herblock's Law: | | chris@calldei.com | If it is good, they will stop making it. | +-------------------+------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 12:16:13 2001 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 D89BB37B402; Tue, 23 Jan 2001 12:15:53 -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 MAA18988; Tue, 23 Jan 2001 12:07:32 -0800 (PST) Message-Id: <200101232007.MAA18988@implode.root.com> To: Mike Smith Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-reply-to: Your message of "Tue, 23 Jan 2001 11:30:58 PST." <200101231930.f0NJUwS01334@mass.dis.org> From: David Greenman Reply-To: dg@root.com Date: Tue, 23 Jan 2001 12:07:32 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I guess they changed their >> policy on the part. I've tested the linux driver with the new part on the >> supermicro board and it works, so the driver is reasonably up to date. > >The source-available Intel driver does actually look pretty good. I >don't know why David has failed to track it wrt. PHY numbers. I've >dumped the last board I had with an unrecognised PHY, so I don't have any >incentive to poke him about it anymore. Primarily for two reasons: 1) I didn't know that Intel had released Linux driver source, and 2) I don't have any boards that don't work correctly. I'll look into the Linux driver, however, and see if it has anything useful in it. Historically the Linux Pro/100+ driver has totally sucked and was chalk-full of magic numbers being anded and ored. -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 Jan 23 12:18:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 63AFA37B401 for ; Tue, 23 Jan 2001 12:17:51 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0NKXHS01892; Tue, 23 Jan 2001 12:33:17 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101232033.f0NKXHS01892@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: dg@root.com Cc: hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-reply-to: Your message of "Tue, 23 Jan 2001 12:07:32 PST." <200101232007.MAA18988@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 12:33:17 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Primarily for two reasons: 1) I didn't know that Intel had released Linux > driver source, and 2) I don't have any boards that don't work correctly. I don't either, anymore, sorry. 8( > I'll look into the Linux driver, however, and see if it has anything > useful in it. Historically the Linux Pro/100+ driver has totally sucked and > was chalk-full of magic numbers being anded and ored. That's "chock full", and you're confusing the Becker driver (bad) with the Intel-supplied driver (slightly less bad). -- ... 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 Jan 23 12:46:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by hub.freebsd.org (Postfix) with ESMTP id C3CF137B402 for ; Tue, 23 Jan 2001 12:46:10 -0800 (PST) Received: from host213-122-9-173.btinternet.com ([213.122.9.173] helo=mail.btinternet.com) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 14LAKL-00036J-00 for freebsd-hackers@FreeBSD.org; Tue, 23 Jan 2001 20:46:05 +0000 Date: Tue, 23 Jan 2001 20:44:02 +0000 From: David Rufino To: freebsd-hackers@FreeBSD.org Subject: driver help Message-ID: <20010123204402.A1515@btinternet.com> Mail-Followup-To: David Rufino , freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am currently trying to port the compatability layer of a linux kernel driver to FreeBSD 4.x. The bit I'm stuck on at the moment is, how do I map arbitrary physical address space to kernel virtual address space (ala ioremap() in linux) ? Thanks. -David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 12:49: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id A9F3937B402 for ; Tue, 23 Jan 2001 12:48:50 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0NL4FS02055; Tue, 23 Jan 2001 13:04:15 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101232104.f0NL4FS02055@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: David Rufino Cc: freebsd-hackers@FreeBSD.org Subject: Re: driver help In-reply-to: Your message of "Tue, 23 Jan 2001 20:44:02 GMT." <20010123204402.A1515@btinternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 13:04:15 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am currently trying to port the compatability layer of a linux > kernel driver to FreeBSD 4.x. The bit I'm stuck on at the moment > is, how do I map arbitrary physical address space to kernel virtual > address space (ala ioremap() in linux) ? Thanks. You don't. If this is a PCI device, it's all done for you when you call bus_alloc_resource. -- ... 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 Jan 23 13:24:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by hub.freebsd.org (Postfix) with SMTP id 5917A37B69E for ; Tue, 23 Jan 2001 13:24:27 -0800 (PST) Received: (qmail 18805 invoked from network); 23 Jan 2001 21:24:24 -0000 Received: from sanpedro-a121.racsa.co.cr (HELO aristoteles.local.galileo.or.cr) (196.40.40.122) by relay1.pair.com with SMTP; 23 Jan 2001 21:24:24 -0000 X-pair-Authenticated: 196.40.40.122 From: Guillermo Leandro Organization: =?iso-8859-1?q?Fundaci=F3n=20Galileo?= To: freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Default users and the passwords Date: Tue, 23 Jan 2001 15:24:40 -0600 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: <01012315244000.00612@aristoteles.local.galileo.or.cr> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everybody! FreeBSD, like almost all Unix OS, has other default users, like uucp, operator, etc. Since this users cames with the FreeBSD distribution, where can I find their passwords? Another thing, why is there another uid 0 called toor? Isn't it a potential security hole? Thank very much. -- Guillermo Leandro, FUNDACIÓN GALILEO Correo electrónico: guille@galileo.or.cr Sitio: http://www.galileo.or.cr Tel. (506) 280 8683, telefax. (506) 280 8847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 13:25: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 89FE837B6A0 for ; Tue, 23 Jan 2001 13:24:35 -0800 (PST) Received: from float by dayspring.firedrake.org with local (Exim 3.12 #1 (Debian)) id 14LAvF-0005BY-00; Tue, 23 Jan 2001 21:24:13 +0000 Date: Tue, 23 Jan 2001 21:24:13 +0000 To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Message-ID: <20010123212413.A19691@firedrake.org> References: <20010118101315.A10537@rapier.smartspace.co.za> <200101220811.f0M8BF906529@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101220811.f0M8BF906529@harmony.village.org>; from imp@harmony.village.org on Mon, Jan 22, 2001 at 01:11:15AM -0700 From: void Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 01:11:15AM -0700, Warner Losh wrote: > > I've committed this change, as threatened late last week, since no one > said not to. Thank you. > buildworld is still required acorss major releases, when binutils > change, and when config's version changes. if buildkernel fails, then > do not complain unless you've also done a buildworld first and it > still fails. This is a convenience for those people that know what > they are doing. Is it possible/desirable to have make print a message upon failure of the buildkernel target, suggesting that the user do a buildworld if they haven't done so? I know that sounds a bit more hand-holdish than FreeBSD tends to be, but I think it would be nice. -- Ben "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." --Kate C. (no, different Ben, I would have stayed up) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 13:31:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id C29C337B698; Tue, 23 Jan 2001 13:31:11 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id OAA10865; Tue, 23 Jan 2001 14:31:07 -0700 (MST) Message-Id: <200101232131.OAA10865@faith.cs.utah.edu> Subject: Re: Default users and the passwords To: guille@galileo.or.cr (Guillermo Leandro) Date: Tue, 23 Jan 2001 14:31:07 -0700 (MST) Cc: freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <01012315244000.00612@aristoteles.local.galileo.or.cr> from "Guillermo Leandro" at Jan 23, 2001 03:24:40 PM From: "David G. Andersen" 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 Lo and behold, Guillermo Leandro once said: > > Hi everybody! > > FreeBSD, like almost all Unix OS, has other default users, like uucp, > operator, etc. Since this users cames with the FreeBSD distribution, where > can I find their passwords? They don't have passwords. /etc/master.passwd > Another thing, why is there another uid 0 called toor? Isn't it a potential > security hole? It doesn't have a password. It just has a different shell. No, it's not a potential security hole. If you don't like it, delete it with vipw. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 13:34:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4E49537B69C for ; Tue, 23 Jan 2001 13:33:57 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0NLXq920871; Tue, 23 Jan 2001 14:33:53 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101232133.f0NLXq920871@harmony.village.org> To: void Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 23 Jan 2001 21:24:13 GMT." <20010123212413.A19691@firedrake.org> References: <20010123212413.A19691@firedrake.org> <20010118101315.A10537@rapier.smartspace.co.za> <200101220811.f0M8BF906529@harmony.village.org> Date: Tue, 23 Jan 2001 14:33:52 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010123212413.A19691@firedrake.org> void writes: : Is it possible/desirable to have make print a message upon failure of : the buildkernel target, suggesting that the user do a buildworld if : they haven't done so? I know that sounds a bit more hand-holdish than : FreeBSD tends to be, but I think it would be nice. It is desirable, I think, but hard to know for sure if you have a stale world or a current world. No buildworld at all is easy to detect. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 13:40:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id A25D737B69F for ; Tue, 23 Jan 2001 13:40:03 -0800 (PST) Received: from float by dayspring.firedrake.org with local (Exim 3.12 #1 (Debian)) id 14LBAW-0005Mt-00; Tue, 23 Jan 2001 21:40:00 +0000 Date: Tue, 23 Jan 2001 21:40:00 +0000 From: void To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Message-ID: <20010123214000.B19691@firedrake.org> References: <20010123212413.A19691@firedrake.org> <20010118101315.A10537@rapier.smartspace.co.za> <200101220811.f0M8BF906529@harmony.village.org> <20010123212413.A19691@firedrake.org> <200101232133.f0NLXq920871@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101232133.f0NLXq920871@harmony.village.org>; from imp@harmony.village.org on Tue, Jan 23, 2001 at 02:33:52PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 02:33:52PM -0700, Warner Losh wrote: > In message <20010123212413.A19691@firedrake.org> void writes: > : Is it possible/desirable to have make print a message upon failure of > : the buildkernel target, suggesting that the user do a buildworld if > : they haven't done so? I know that sounds a bit more hand-holdish than > : FreeBSD tends to be, but I think it would be nice. > > It is desirable, I think, but hard to know for sure if you have a > stale world or a current world. No buildworld at all is easy to detect. I would suggest not trying to detect the condition but simply mentioning that it is a possible cause of failure and letting the user figure it out from there. -- Ben "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." --Kate C. (no, different Ben, I would have stayed up) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 13:41:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from vieo.com (vieo.com [216.30.79.131]) by hub.freebsd.org (Postfix) with ESMTP id 09B6637B69E for ; Tue, 23 Jan 2001 13:41:18 -0800 (PST) Received: (from johng@localhost) by vieo.com (8.11.2/8.11.2) id f0NLfCm43863 for freebsd-hackers@FreeBSD.ORG; Tue, 23 Jan 2001 15:41:12 -0600 (CST) (envelope-from johng) Date: Tue, 23 Jan 2001 15:41:12 -0600 (CST) From: John Gregor Message-Id: <200101232141.f0NLfCm43863@vieo.com> To: freebsd-hackers@FreeBSD.ORG Subject: searching physical memory... Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG All, I'm doing hardware bringup and am suspecting that our adapter is dma-ing to the wrong physical address. We know we're getting a PCI bus transaction when we expect it, but we don't know where it's going. Until the bus analyzer arrives, what's the easiest way to go through physical memory looking for a known pattern? Is it really as simple as opening /dev/mem and marching through it? Thanks, -JohnG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 13:53:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 92D4F37B6A2 for ; Tue, 23 Jan 2001 13:53:03 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0NLqs934704; Tue, 23 Jan 2001 14:52:54 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101232152.f0NLqs934704@harmony.village.org> To: void Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Tue, 23 Jan 2001 21:40:00 GMT." <20010123214000.B19691@firedrake.org> References: <20010123214000.B19691@firedrake.org> <20010123212413.A19691@firedrake.org> <20010118101315.A10537@rapier.smartspace.co.za> <200101220811.f0M8BF906529@harmony.village.org> <20010123212413.A19691@firedrake.org> <200101232133.f0NLXq920871@harmony.village.org> Date: Tue, 23 Jan 2001 14:52:54 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010123214000.B19691@firedrake.org> void writes: : I would suggest not trying to detect the condition but simply mentioning : that it is a possible cause of failure and letting the user figure it out : from there. I don't know how to generate a warning that isn't a false positive in most cases. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 14: 5: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by hub.freebsd.org (Postfix) with ESMTP id A099037B6A8; Tue, 23 Jan 2001 14:04:47 -0800 (PST) Received: from HSE-QCity-ppp94185.qc.sympatico.ca ([64.230.224.150]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010123220441.LQHR10080.tomts8-srv.bellnexxia.net@HSE-QCity-ppp94185.qc.sympatico.ca>; Tue, 23 Jan 2001 17:04:41 -0500 Date: Tue, 23 Jan 2001 17:09:02 -0500 (EST) From: Felix-Antoine Paradis To: "Yonny Cardenas B." Cc: , Subject: Re: Kernel programming In-Reply-To: <3A6CF781.C9C2871A@yahoo.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 You can refer to the FreeBSD Handbook (www.freebsd.org/handbook) On Mon, 22 Jan 2001, Yonny Cardenas B. wrote: > Hello > > I am adding a set the new system calls to FreeBSD kernel, > but to compile and to test new source code within the kernel > is a little hard when there is some problem. > > Is there anybody knows some reference (URL), tools or some help > to programming and debugging in the kernel FreeBSD? > That is some suggestions, examples, etc., different to > kernel?s source code of course. > > Thanks. > > +------------------------------------------------------------------+ > | YONNY CARDENAS B. Apartado Aereo 22828 | > | Systems Engineer Santafe de Bogota D.C. | > | Colombia - South America | > | Student M.Sc. Tel: +571 6095477 | > | UNIVERSIDAD DE LOS ANDES mailto: y-carden@uniandes.edu.co | > | ycardena@computer.org | > | http://www.geocities.com/ycardena | > +------------------------------------------------------------------+ > UNIX is BSD, and FreeBSD is an advanced 4.4BSD > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Felix-Antoine Paradis . cell: 1-418-261-0865 . . IRC: reel @ DALnet . job: Idemnia Network . . Email: reel@sympatico.ca . *** 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 Tue Jan 23 15:17:16 2001 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 7511337B402 for ; Tue, 23 Jan 2001 15:16:59 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NNGvf14857; Tue, 23 Jan 2001 15:16:57 -0800 (PST) Date: Tue, 23 Jan 2001 15:16:57 -0800 From: Alfred Perlstein To: John Gregor Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: searching physical memory... Message-ID: <20010123151657.J26076@fw.wintelcom.net> References: <200101232141.f0NLfCm43863@vieo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101232141.f0NLfCm43863@vieo.com>; from johng@vieo.com on Tue, Jan 23, 2001 at 03:41:12PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Gregor [010123 13:41] wrote: > All, > > I'm doing hardware bringup and am suspecting that our adapter is > dma-ing to the wrong physical address. We know we're getting a PCI > bus transaction when we expect it, but we don't know where it's going. > > Until the bus analyzer arrives, what's the easiest way to go through > physical memory looking for a known pattern? Is it really as simple as > opening /dev/mem and marching through it? see the mem(4) manpage and let us know. :) -- -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 Jan 23 15:17:52 2001 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 49A8D37B698 for ; Tue, 23 Jan 2001 15:17:32 -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 QAA20293 for ; Tue, 23 Jan 2001 16:17:21 -0700 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( Tumbleweed MMS SMTP Relay(WSS) v4.5); Tue, 23 Jan 2001 16:17:23 -0700 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id ; Tue, 23 Jan 2001 16:17:22 -0700 Message-ID: <8D18712B2604D411A6BB009027F644980DD87C@0SEA01EXSRV1> From: "Matt Simerson" To: "'freebsd-hackers@freebsd.org'" Subject: FreeBSD doesn't recognize keyboard unless is plugged in at boot t ime. Date: Tue, 23 Jan 2001 16:17:00 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 1670CE89363791-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, one of my biggest pet peeves of late is that unless you have the PS/2 keyboard plugged in at boot time, it's not recognized. In a world of workstations where every machine has a keyboard, this would never really be a problem but in our data center, where we have rows of racks full of machines without keyboards, this is quite the annoyance. If a machine has problems, the NOC monkeys wheel over a KVM cart, plug it in, and when the machines doesn't respond to keyboard activity, assume it's locked up and power cycle it. We've got the NOC monkeys trained NOT to do that now (without trying a few other things) but it's still a real bugger when you want to get onto a box via console. You have to go plug in a KVM, reboot the machine, and then you can get console access. Long ago, a bright SUNny OS has this same problem and they found some clever workaround. I know that my BSDI systems don't suffer from this affliction either. Is there already a kernel option for this? Is there some other workaround? On a few machines I've build PS/2 connectors with a resistor that I plug in so that FreeBSD _thinks_ there is a keyboard there at boot time. Then we just unplug the PS/2 plug, plug in a keyboard, and all is happy. Oddly enough, this behavior is also manifested when said server is plugged into a Belkin OmniCube KVM switch unless the KVM is set to that machine. This too is highly annoying because I have to sit and watch a computer boot if I want to have console access to it. I can't be the only one having this problem can I? Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 15:28:45 2001 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 0EA9037B69C for ; Tue, 23 Jan 2001 15:28:25 -0800 (PST) Received: by peitho.fxp.org (Postfix, from userid 1501) id CFA231360C; Tue, 23 Jan 2001 18:28:23 -0500 (EST) Date: Tue, 23 Jan 2001 18:28:23 -0500 From: Chris Faulhaber To: Matt Simerson Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: FreeBSD doesn't recognize keyboard unless is plugged in at boot t ime. Message-ID: <20010123182823.A62506@peitho.fxp.org> Mail-Followup-To: Chris Faulhaber , Matt Simerson , "'freebsd-hackers@freebsd.org'" References: <8D18712B2604D411A6BB009027F644980DD87C@0SEA01EXSRV1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8D18712B2604D411A6BB009027F644980DD87C@0SEA01EXSRV1>; from mpsimerson@hostpro.com on Tue, Jan 23, 2001 at 04:17:00PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 04:17:00PM -0700, Matt Simerson wrote: > OK, one of my biggest pet peeves of late is that unless you have the PS/2 > keyboard plugged in at boot time, it's not recognized. > man atkbd (see Driver Flags) -- 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 Tue Jan 23 15:30:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id E1D4B37B400 for ; Tue, 23 Jan 2001 15:30:31 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0NNjeS03002; Tue, 23 Jan 2001 15:45:40 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101232345.f0NNjeS03002@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Matt Simerson" Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: FreeBSD doesn't recognize keyboard unless is plugged in at boot t ime. In-reply-to: Your message of "Tue, 23 Jan 2001 16:17:00 MST." <8D18712B2604D411A6BB009027F644980DD87C@0SEA01EXSRV1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 15:45:40 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > OK, one of my biggest pet peeves of late is that unless you have the PS/2 > keyboard plugged in at boot time, it's not recognized. Change the flags value for the 'atkbd' driver to 0. The default value, 0x1, is necessary for the correct functioning of systems with USB keyboards. -- ... 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 Jan 23 16:15:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fremont.bolingbroke.com (adsl-216-102-90-210.dsl.snfc21.pacbell.net [216.102.90.210]) by hub.freebsd.org (Postfix) with ESMTP id 49B0C37B698 for ; Tue, 23 Jan 2001 16:14:55 -0800 (PST) Received: from fremont.bolingbroke.com (fremont.bolingbroke.com [216.102.90.210]) by fremont.bolingbroke.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0O0Ess50901 for ; Tue, 23 Jan 2001 16:14:54 -0800 (PST) Date: Tue, 23 Jan 2001 16:14:54 -0800 (PST) From: Ken Bolingbroke To: freebsd-hackers@FreeBSD.ORG Subject: Biometric security? In-Reply-To: <5FE9B713CCCDD311A03400508B8B3013054E3E24@bdr-xcln.is.matchlogic.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 Has anyone gotten any biometric security devices to work with FreeBSD? I'm particularly interested in something like a fingerprint scanner that I could use to authenticate logins or disable my password protected screensaver rather than typing in my password all the time... Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 16:36:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dayspring.firedrake.org (dayspring.firedrake.org [195.82.105.251]) by hub.freebsd.org (Postfix) with ESMTP id 6426137B69E for ; Tue, 23 Jan 2001 16:36:13 -0800 (PST) Received: from float by dayspring.firedrake.org with local (Exim 3.12 #1 (Debian)) id 14LDuy-0007Yv-00; Wed, 24 Jan 2001 00:36:08 +0000 Date: Wed, 24 Jan 2001 00:36:08 +0000 From: void To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Message-ID: <20010124003608.A26132@firedrake.org> References: <20010123214000.B19691@firedrake.org> <20010123212413.A19691@firedrake.org> <20010118101315.A10537@rapier.smartspace.co.za> <200101220811.f0M8BF906529@harmony.village.org> <20010123212413.A19691@firedrake.org> <200101232133.f0NLXq920871@harmony.village.org> <20010123214000.B19691@firedrake.org> <200101232152.f0NLqs934704@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101232152.f0NLqs934704@harmony.village.org>; from imp@harmony.village.org on Tue, Jan 23, 2001 at 02:52:54PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 02:52:54PM -0700, Warner Losh wrote: > > I don't know how to generate a warning that isn't a false positive in > most cases. Hmm ... how about something like, "make buildkernel failed, please check /usr/src/UPDATING for relevant information" ? -- Ben "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." --Kate C. (no, different Ben, I would have stayed up) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 16:40: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9165737B6A1 for ; Tue, 23 Jan 2001 16:39:47 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0O0df953274; Tue, 23 Jan 2001 17:39:41 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101240039.f0O0df953274@harmony.village.org> To: void Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 24 Jan 2001 00:36:08 GMT." <20010124003608.A26132@firedrake.org> References: <20010124003608.A26132@firedrake.org> <20010123214000.B19691@firedrake.org> <20010123212413.A19691@firedrake.org> <20010118101315.A10537@rapier.smartspace.co.za> <200101220811.f0M8BF906529@harmony.village.org> <20010123212413.A19691@firedrake.org> <200101232133.f0NLXq920871@harmony.village.org> <20010123214000.B19691@firedrake.org> <200101232152.f0NLqs934704@harmony.village.org> Date: Tue, 23 Jan 2001 17:39:41 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010124003608.A26132@firedrake.org> void writes: : On Tue, Jan 23, 2001 at 02:52:54PM -0700, Warner Losh wrote: : > : > I don't know how to generate a warning that isn't a false positive in : > most cases. : : Hmm ... how about something like, : : "make buildkernel failed, please check /usr/src/UPDATING for relevant : information" Ah. I see what you are saying. I'll see if there's an easy way to do that. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 16:42:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by hub.freebsd.org (Postfix) with ESMTP id 786FD37B69E for ; Tue, 23 Jan 2001 16:42:14 -0800 (PST) Received: from HSE-QCity-ppp94185.qc.sympatico.ca ([64.230.224.150]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010124004213.LWRR11735.tomts6-srv.bellnexxia.net@HSE-QCity-ppp94185.qc.sympatico.ca>; Tue, 23 Jan 2001 19:42:13 -0500 Date: Tue, 23 Jan 2001 19:46:40 -0500 (EST) From: Felix-Antoine Paradis To: "Daniel C. Sobral" Cc: Subject: Re: PPPoE In-Reply-To: <3A6C48E3.493F5161@newsguy.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 Well, i got a ADSL, and it's working very well with thoses settings. Post install administration is ok, and i don't have any problems with networking points. But, yeah, for sure, i am restricted to CD install, but, however, that's not that bad. Do you know if there's any way to get it to work to do a FTP install? On Mon, 22 Jan 2001, Daniel C. Sobral wrote: > Felix-Antoine Paradis wrote: > > > > To get pppoe to work, just set the options in the kernel and use a good > > config (ppp.conf) and use pppd. > > Kernel options are bad for a number of reasons, not the least of them > the inability to do network installs (I mean, you have ADSL and get > restricted to cd installs?). Anyway... what _are_ the kernel options? > > -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > capo@a.crazy.bsdconspiracy.net > > "There is no spoon." -- Kiki > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Felix-Antoine Paradis . cell: 1-418-261-0865 . . IRC: reel @ DALnet . job: Idemnia Network . . Email: reel@sympatico.ca . *** 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 Tue Jan 23 16:56:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by hub.freebsd.org (Postfix) with ESMTP id 5D34637B400 for ; Tue, 23 Jan 2001 16:55:59 -0800 (PST) Received: from x54.ripe.net (x54.ripe.net [193.0.1.54]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id BAA20695; Wed, 24 Jan 2001 01:55:57 +0100 (CET) Received: (from marks@localhost) by x54.ripe.net (8.8.8/8.8.5) id BAA17746; Wed, 24 Jan 2001 01:55:57 +0100 (CET) Date: Wed, 24 Jan 2001 01:55:57 +0100 From: Mark Santcroos To: Ken Bolingbroke Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Biometric security? Message-ID: <20010124015555.A11713@ripe.net> References: <5FE9B713CCCDD311A03400508B8B3013054E3E24@bdr-xcln.is.matchlogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from hacker@bolingbroke.com on Tue, Jan 23, 2001 at 04:14:54PM -0800 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 04:14:54PM -0800, Ken Bolingbroke wrote: > Has anyone gotten any biometric security devices to work with > FreeBSD? I'm particularly interested in something like a fingerprint > scanner that I could use to authenticate logins or disable my password > protected screensaver rather than typing in my password all the time... Hi, Compaq has some cheap devices for workstations at around $100. The API you can find at www.bioapi.org. Mark ps. if you get me a device, I might be interested in writing a driver ;) -- Mark Santcroos RIPE Network Coordination Centre PGP KeyID: 1024/0x3DCBEB8D PGP Fingerprint: BB1E D037 F29D 4B40 0B26 F152 795F FCAB 3DCB EB8D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 17: 2:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id A8A8B37B69E; Tue, 23 Jan 2001 17:02:15 -0800 (PST) Received: from bellatlantic.net (client-151-198-135-19.nnj.dialup.bellatlantic.net [151.198.135.19]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA19570; Tue, 23 Jan 2001 20:02:00 -0500 (EST) Message-ID: <3A6E2987.711B626@bellatlantic.net> Date: Tue, 23 Jan 2001 20:01:59 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Greg Black Cc: Doug Barton , cvs-committers@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h References: <3A6CE98B.4EA9EB9B@bellatlantic.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Black wrote: > > Sergey Babkin wrote: > > > There are other things which may not allow a job to finish in > > a predefined time slot. For example, other operations going on > > and consuming CPU, disk or network bandwidth. So presuming > > that a job would finish by some time is inherently unsafe. > > The safe way is to put both jobs sequentially into one script > > and run this one script from cron. > > Remember that for later. > > > Time critical jobs should be avoided at all, by including all the > > dependent jobs into one script and running only this script > > from cron. > > And remember that while you read this: > > > I can give you one example from my past experience: a nightly cold > > backup of a database which takes a long time, must be started after > > all the day's work would be complete, and finish by 7:30AM the next > > morning. The time of backup depends on the amount of change logs > > generated during the day, so to be safe it should be started as > > early as possible. Well, eventually we got the day's close > > processing to complete by 12:50 and scheduled the job there. > > But the fact that two hours of time are unusable for starting > > any jobs is not a particularly exciting one nor fun to discover. > > This is an absurd claim, especially in the light of what you > said earlier (quoted above). If the backup depends on the There were political reasons for that. The applications which were presumed to be stopped by some specific time were supported by the applications group. The backup process was supported by the systems/database administration group. The border time was a result of negotiations between these two groups. > You keep demanding technical arguments (which I think means > arguments about the content of the proposed changes) -- but the Largely, yes. But in addition to that I would like to hear, why would be wrong to modify the behavior if this behavior is changed within the DST change timeframe only. In fact, one of the reasons why I limited my patch to the 1 hour difference and changes at the hour limit only was to provide additional guarentees that the behavior outside the DST change time frame would not be touched. Another reason was to keep things simple for now and thus reduce the chances of bugs. > matter of concern to me is /not/ that at all, it's whether there > is any need for potentially breaking an important utility which > has known behaviour to "solve" things that don't need and are > not suited to technical solutions, no matter who else might This is a valid argument. However I don't see particularly much risk in this sort ot fix. Of course, rigorous testing would be a very good thing to do. Even though I provided the functional test cases, the additional black box tests would never hurt. > think that is the way to go. Arguing that commercial Unix > vendors have decided to meet the lowest common denominator by > changing cron is not a case for FreeBSD to go down the same > road. My point is that they had reasons for doing that: the demands of the users. In the commercial world nobody would budge for bug fixes unless they have some important customers crying out loud. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 19: 0:53 2001 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 7486E37B69F for ; Tue, 23 Jan 2001 19:00:36 -0800 (PST) Received: from localhost (carock@localhost) by kira.epconline.net (8.11.2/8.11.2) with ESMTP id f0O30ZO87148 for ; Tue, 23 Jan 2001 21:00:35 -0600 (CST) Date: Tue, 23 Jan 2001 21:00:35 -0600 (CST) From: Chuck Rock To: hackers@freebsd.org Subject: PRopose change or addition to periodic scripts.... 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 would like to add a message discard accounting to the daily script that displays rejected mail in the root mailbox. I have been using discard in my sendmail access file for SPAM as it keeps reject loops from happening, and also spares the poor S.O.B. whose domain was used in sending spam from getting all those rejects from our server anyway. If it's a good idea, I request an option in the periodic script config, otherwise can someone tell me what to change in the mail reject script file to also show discards. thanks, Chuck Rock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 19:48:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from PacHell.Pachell.net (PacHell.Pachell.net [207.90.181.5]) by hub.freebsd.org (Postfix) with ESMTP id 429C237B69C for ; Tue, 23 Jan 2001 19:47:56 -0800 (PST) Received: (from ulf@localhost) by PacHell.Pachell.net (8.11.1/8.11.1) id f0O3lbS66264 for hackers@freebsd.org; Tue, 23 Jan 2001 19:47:37 -0800 (PST) (envelope-from ulf) Date: Tue, 23 Jan 2001 19:47:37 -0800 From: Ulf Zimmermann To: hackers@freebsd.org Subject: Digi Etherlite driver for Linux in sourcecode available Message-ID: <20010123194737.H16465@PacHell.Pachell.net> Reply-To: ulf@Alameda.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 4.2-STABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Everyone. Digi is now providing a Linux module driver in source for their Etherlite devices. The source can be found at: http://support.digi.com/support/indexes/linux-els.html The file itself is a RPM file and basicly just contains a tar.gz file, which you can access at: http://pachell.pachell.net/~ulf/els-1.02-1.tar.gz I would like to see this driver ported to FreeBSD, out of this reason I am looking for someone who would like to work on this. I can borrow an Etherlite 32 to test the port. Please contact me in case you are interested in working on this. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 21: 0:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 073BD37B400 for ; Tue, 23 Jan 2001 21:00:38 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0O53q726684; Tue, 23 Jan 2001 21:03:52 -0800 (PST) (envelope-from kris) Date: Tue, 23 Jan 2001 21:03:52 -0800 From: Kris Kennaway To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PAM (was: Re: MAIL set by whom?) Message-ID: <20010123210352.A26571@citusc17.usc.edu> References: <3A6A50F3.307C9E06@nisser.com> <20010121103324.A297@frolic.no-support.loc> <3A6B042E.659C716D@nisser.com> <20010122094647.A7853@semantico.com> <3A6C7111.80E5663F@newsguy.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6C7111.80E5663F@newsguy.com>; from dcs@newsguy.com on Tue, Jan 23, 2001 at 02:42:41AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 23, 2001 at 02:42:41AM +0900, Daniel C. Sobral wrote: > Dominic Mitchell wrote: > >=20 > > On Sun, Jan 21, 2001 at 04:45:50PM +0100, Roelof Osinga wrote: > > > Grand gesture. Laudable even. Yeah, that PAM sure seems to've > > > become popular. The Courier IMAP port also insisted upon its > > > installation. Insisted in that fiddling with the makefile only > > > resulted in failure to configure. But that's a whole different > > > story. > >=20 > > Would it be a good idea to start using /etc/pam.d ala RedHat, instead of > > the monolithic /etc/pam.conf? > >=20 > > As far as I can see the support is already there, it's just not being > > used due to the presence of the /etc/pam.conf. > >=20 > > This would make installing PAM entries far easier for the ports. >=20 > Ports shouldn't touch /etc. >=20 > Does the existance of /etc/pam.conf precludes /usr/local/etc/pam.d from > working? Yes, at present (well, it doesn't know about /usr/local/etc/pam.d): from pam(8): ticate users. This dynamic configuration is set by the contents of the single PAM configuration file /etc/pam.conf. Alternatively, the configuration can be set by individual configuration files located in the /etc/pam.d/ directory. The presence of this directory will cause PAM to ignore /etc/pam.conf. FWIW, I agree about the need for the change. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6bmI4Wry0BWjoQKURAg5MAJ41zcDHDYQzlBt3F6FUlkbIGGW9gwCgnlQn LR97leWRFtXpPEWf9+/oZV0= =cota -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 21:37:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 0FE4D37B401 for ; Tue, 23 Jan 2001 21:37:39 -0800 (PST) Received: from localhost (joe@localhost) by panther.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id VAA07431 for ; Tue, 23 Jan 2001 21:37:29 -0800 (PST) Date: Tue, 23 Jan 2001 21:37:29 -0800 (PST) From: Joe Albowicz To: freebsd-hackers@freebsd.org Subject: need help with pthreads and memory corruption problem 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 Hello, I'm porting an application from Linux to FreeBSD and I am having some problems with the program crashing in weird/random places because of memory corruption. For example the crash can happen in STL or free or in c++ code that we have written (note that our code works just fine on Linux for extended periods of time under heavy load). The application consists of a main process plus a few dozen pthreads written in c++. The only changes that I have made in porting from Linux to FreeBSD consisted of Makefile changes (e.g. using -D_THREAD_SAFE) and I replaced "new" with malloc in code that is excuted by the pthreads [except STL may call new?]. Replacing new with malloc definately helped, but I'm not sure why. My questions are: How are you supposed to build a pthreads application with c++/STL/SMP? How are you supposed to build a linuxthreads application with c++/STL/SMP? [Incidentally I tried this approach but still had unstable code. Is linuxthreads stable on FreeBSD?] Are there reentrancy problems with STL? Are there (reentrancy) problems with stdlibc++/pthreads? What compile flags are important with c++/STL/pthreads/linuxthreads? (what are -D_PTHREADS -D__USE_MALLOC?) Details on the OS version, compile flags and libs are below. Any input or shared misery would be nice! thanks in advance! :) Joe ************************************************************ ** uname -a FreeBSD 4.2-RELEASE FreeBSD 4.2-RELEASE #0 ** g++ --version 2.95.2 ** Compile flags g++ -D_THREAD_SAFE -D_REENTRANT foo.cpp [note adding -D_PTHREADS -D__USE_MALLOC seems to have stabilized it] ** Link step g++ -v -g -pthread main.o -lxml -L./xml/lib -lz *produces /usr/libexec/elf/ld -m elf_i386 -dynamic-linker /usr/libexec/ld-elf.so.1 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L./xml/lib -L/usr/libexec/elf -L/usr/libexec -L/usr/lib main.o -lxml -lz -lstdc++ -lm /usr/lib/libgcc_r.a -lc_r /usr/lib/libgcc_r.a /usr/lib/crtend.o /usr/lib/crtn.o To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 21:54:24 2001 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 E467A37B400 for ; Tue, 23 Jan 2001 21:54:04 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0O5s4Y25628; Tue, 23 Jan 2001 21:54:04 -0800 (PST) Date: Tue, 23 Jan 2001 21:54:04 -0800 From: Alfred Perlstein To: Joe Albowicz Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: need help with pthreads and memory corruption problem Message-ID: <20010123215403.Q26076@fw.wintelcom.net> 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 joe@CS.UCLA.EDU on Tue, Jan 23, 2001 at 09:37:29PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Joe Albowicz [010123 21:38] wrote: > > Hello, > > I'm porting an application from Linux to FreeBSD and I am having some > problems with the program crashing in weird/random places because of > memory corruption. For example the crash can happen in STL or free or in > c++ code that we have written (note that our code works just fine on Linux > for extended periods of time under heavy load). Try updating to the most recent version of FreeBSD-stable. Afaik there were bugs with c++ and threads until several weeks ago. -- -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 Jan 23 22:45: 3 2001 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 4350237B402 for ; Tue, 23 Jan 2001 22:44:45 -0800 (PST) Received: from newsguy.com (p07-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.8]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id PAA06477; Wed, 24 Jan 2001 15:44:36 +0900 (JST) Message-ID: <3A6E7940.88E27D3@newsguy.com> Date: Wed, 24 Jan 2001 15:42:08 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Felix-Antoine Paradis Cc: hackers@FreeBSD.ORG Subject: Re: PPPoE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Felix-Antoine Paradis wrote: > > Well, i got a ADSL, and it's working very well with thoses settings. Post > install administration is ok, and i don't have any problems with > networking points. But, yeah, for sure, i am restricted to CD install, > but, however, that's not that bad. Do you know if there's any way to get > it to work to do a FTP install? You can grab a third disk, dump the required .ko on it, and then change the loader.rc script on the first disk to load those first. I think. But that's my problem. My problem is that my (future) provider uses a screwed up version of PPPoE with non-standard ethernet frame types for the identification (?) phase. As a result, all my friends resorted to running Roaring Penguin PPP, but _I_ am not going that way. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 23: 7:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interactivate.com (unknown [63.141.73.15]) by hub.freebsd.org (Postfix) with ESMTP id 463AB37B69F; Tue, 23 Jan 2001 23:06:48 -0800 (PST) Received: from interactivate.com (snakcx408168-b.@cx408168-b.escnd1.sdca.home.com [24.20.227.61]) by mail.interactivate.com (8.11.1/8.11.1) with ESMTP id f0O7T5V61581; Tue, 23 Jan 2001 23:29:05 -0800 (PST) (envelope-from larry@interactivate.com) Message-ID: <3A6E7F77.6DFC4A3E@interactivate.com> Date: Tue, 23 Jan 2001 23:08:39 -0800 From: Lawrence Sica Organization: Interactivate, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Guillermo Leandro Cc: freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Default users and the passwords References: <01012315244000.00612@aristoteles.local.galileo.or.cr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Guillermo Leandro wrote: > Hi everybody! > > FreeBSD, like almost all Unix OS, has other default users, like uucp, > operator, etc. Since this users cames with the FreeBSD distribution, where > can I find their passwords? > they don't have any, the pseudo users and system accounts dont have a login shell and their passwords should be set to * as well. Be careful if you remove them since on a make world certain users are expected, same with groups. > > Another thing, why is there another uid 0 called toor? Isn't it a potential > security hole? > toor is a big debate for many, its meant to give you another root shell with a differing shell, like bash,zsh,ksh whatever. Reason is you dont wan to mess with root's shell. Someone compared root to a loaded weapon recently, its a good analogy since you dont use root unless you mean it and you have to be careful. --Larry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 23:22: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id D30F337B6A2 for ; Tue, 23 Jan 2001 23:21:47 -0800 (PST) Received: (qmail 99383 invoked by uid 1000); 24 Jan 2001 07:22:08 -0000 Date: Tue, 23 Jan 2001 23:21:46 -0800 From: Jos Backus To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD doesn't recognize keyboard unless is plugged in at boot t ime. Message-ID: <20010123232146.A97946@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-hackers@freebsd.org References: <8D18712B2604D411A6BB009027F644980DD87C@0SEA01EXSRV1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8D18712B2604D411A6BB009027F644980DD87C@0SEA01EXSRV1>; from mpsimerson@hostpro.com on Tue, Jan 23, 2001 at 04:16:38PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 04:16:38PM -0700, Matt Simerson wrote: > Oddly enough, this behavior is also manifested when said server is plugged > into a Belkin OmniCube KVM switch unless the KVM is set to that machine. I have the same problem with a Win2k system and a FreeBSD system connected to an OmniCube 4-port switch, at rev. 1.5 (see the bottom of the unit). Belkin says it's fixed in rev. 1.9 and is willing to exchange the unit for a newer one. -- Jos Backus _/ _/_/_/ "Modularity is not a hack." _/ _/ _/ -- D. J. Bernstein _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 23 23:53:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.newst.irs.ru (newst.irs.ru [212.164.94.1]) by hub.freebsd.org (Postfix) with ESMTP id 788A437B400 for ; Tue, 23 Jan 2001 23:53:09 -0800 (PST) Received: from lark.nsk.bsgdesign.com (lark.nsk.bsgdesign.com [192.168.3.21]) by mail.newst.irs.ru (8.11.1/8.11.0) with ESMTP id f0O7qgX65850; Wed, 24 Jan 2001 13:52:48 +0600 (NOVT) (envelope-from fjoe@newst.net) Date: Wed, 24 Jan 2001 13:52:11 +0600 (NOVT) From: Max Khon X-Sender: fjoe@localhost To: Joe Albowicz Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: need help with pthreads and memory corruption problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Tue, 23 Jan 2001, Joe Albowicz wrote: > I'm porting an application from Linux to FreeBSD and I am having some > problems with the program crashing in weird/random places because of > memory corruption. For example the crash can happen in STL or free or in > c++ code that we have written (note that our code works just fine on Linux > for extended periods of time under heavy load). > > The application consists of a main process plus a few dozen pthreads > written in c++. The only changes that I have made in porting from Linux to > FreeBSD consisted of Makefile changes (e.g. using -D_THREAD_SAFE) and I > replaced "new" with malloc in code that is excuted by the pthreads [except > STL may call new?]. Replacing new with malloc definately helped, but I'm > not sure why. [...] > FreeBSD 4.2-RELEASE FreeBSD 4.2-RELEASE #0 please upgrade to latest -stable. there have been problems with C++ and threads in 4.2-RELEASE and they have been fixed recently /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 0:55:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hnmail7.dac.migros.ch (mail2.gmaare.migros.ch [164.14.132.116]) by hub.freebsd.org (Postfix) with ESMTP id B9E2437B401 for ; Wed, 24 Jan 2001 00:55:03 -0800 (PST) Received: by hnmail7.dac.migros.ch with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jan 2001 09:54:53 +0100 Received: from gmaare.migros.net (hunetm03.dac.migros.ch [10.16.61.22]) by hnmail2.dac.migros.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDCK8X9M; Wed, 24 Jan 2001 09:54:42 +0100 From: Andreas Brodmann To: Dejvid Zaninovic Cc: freebsd-hackers@freebsd.org Message-ID: <3A6E96A3.A42F8690@gmaare.migros.net> Date: Wed, 24 Jan 2001 09:47:31 +0100 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IP Address Overtaking References: <001701c08572$7d218a90$230aa8c0@newyork.mod> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Dejvid, just a suggestion: In production environments it is a must to also take over the cluster partner's mac address. Something that would make a nice plus to your script. Regards, Andreas --- switch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 1:20:14 2001 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 69D9637B69B for ; Wed, 24 Jan 2001 01:19:49 -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 <01JZA5VUW3L00006KP@research.kpn.com> for hackers@FreeBSD.ORG; Wed, 24 Jan 2001 10:19:48 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jan 2001 10:19:47 +0100 Content-return: allowed Date: Wed, 24 Jan 2001 10:19:46 +0100 From: "Koster, K.J." Subject: RE: if_fxp driver info To: "'dg@root.com'" Cc: hackers@FreeBSD.ORG, "Metz, E.T." Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7B4B@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 > > 2) I don't have any boards that don't work correctly. > I have several. If you send me your surface-mail address, I can ship one to you. Kees Jan ================================================ You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 2:42: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcs113.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id D11EE37B69D for ; Wed, 24 Jan 2001 02:41:36 -0800 (PST) Received: from localhost (pmk@localhost) by pcs113.sasi.com (8.9.3/8.9.3) with ESMTP id QAA05648 for ; Wed, 24 Jan 2001 16:11:23 +0530 X-Authentication-Warning: pcs113.sasi.com: pmk owned process doing -bs Date: Wed, 24 Jan 2001 16:11:23 +0530 (IST) From: Mohana Krishna Penumetcha To: freebsd-hackers@FreeBSD.ORG Subject: interrupt handling routine!!! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, we are writing a driver(FreeBSD 4.0) for a switch connected to a PCI port. the interrupt handling routine is not getting called. we checked the switch IRQ status register and find some interrupts to be pending. we have no clue about what is happening, can someone give a few ideas about what could be wrong? some info you may ask for: vmstat -i doesn't show any thing about the device there doen't seem to be any conflicts while assigning the IRQ numbers. and the IRQ info in dmesg matches with the interrupt line configuration register of the device. code to register to interrupt routine: rid = 0; sc->edge_irq = bus_alloc_resource(dev,SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE|RF_ACTIVE); if(!sc->edge_irq){ /*release all resources*/ return -1; } error = bus_setup_intr(dev, sc->edge_irq, INTR_TYPE_NET, edge_intr, /*interrupt handler*/ sc, &sc->edge_intrhand); if(error){ /*release all resources*/ return -1; } thanks, mohan --------------------------------------------------------------------------- Creativity is allowing yourself to make mistakes and Art is knowing which ones to keep. -Dilbert Mohana Krishna P. ph:- 527 6100/6108 x6352 Telecom ODC, Sasken Communication Technologies, INDIA. http://www.sasken.com --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 4:35:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from csunb0.leeds.ac.uk (csunb0.leeds.ac.uk [129.11.144.2]) by hub.freebsd.org (Postfix) with SMTP id 414CE37B400 for ; Wed, 24 Jan 2001 04:35:34 -0800 (PST) Received: from cslin.leeds.ac.uk (csunc0.leeds.ac.uk [129.11.144.3]) by csunb0.leeds.ac.uk (8.6.12/8.6.12) with ESMTP id MAA18037; Wed, 24 Jan 2001 12:22:55 GMT Received: from cslin006.leeds.ac.uk (cslin006 [129.11.146.6]) by cslin.leeds.ac.uk (8.9.3+Sun/) with ESMTP id MAA29690; Wed, 24 Jan 2001 12:22:56 GMT Date: Wed, 24 Jan 2001 12:22:53 +0000 From: Ben Smithurst To: Warner Losh Cc: dan@langille.org, FreeBSD Current Users Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Message-ID: <20010124122253.B1491@comp.leeds.ac.uk> References: <200101220910.WAA24873@ducky.nz.freebsd.org> <20010118101315.A10537@rapier.smartspace.co.za> <200101220910.WAA24873@ducky.nz.freebsd.org> <200101222339.f0MNdu913510@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101222339.f0MNdu913510@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <200101220910.WAA24873@ducky.nz.freebsd.org> "Dan Langille" writes: > : http://www.freebsd.org/handbook/kernelconfig-building.html > > This change should do the trick if I'm reading things right. It's still KERNEL= in -stable though I think. I think I'll just add a which says "in -current use KERNCONF instead of KERNEL". When -stable uses KERNCONF too this ugliness can go. In fact, I just have committed this. -- Ben Smithurst / csxbcs@comp.leeds.ac.uk / ben@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 Jan 24 6:58:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nyapp002.mediaondemand.com (mailhost.mediaondemand.com [208.184.36.78]) by hub.freebsd.org (Postfix) with ESMTP id 0AF5A37B699 for ; Wed, 24 Jan 2001 06:58:16 -0800 (PST) Received: from nywst536 (nywst536.newyork.mod [192.168.10.35]) by nyapp002.mediaondemand.com (8.11.2/8.11.2) with SMTP id f0OEwEn03417; Wed, 24 Jan 2001 09:58:14 -0500 (EST) Message-ID: <000e01c08615$ddda4b80$230aa8c0@newyork.mod> From: "Dejvid Zaninovic" To: Cc: Subject: Re: IP Address Overtaking Date: Wed, 24 Jan 2001 09:56:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > just a suggestion: In production environments it is a must to also > take over the cluster partner's mac address. Something that > would make a nice plus to your script. I was thinking about that.... I don't see that this is a must in production environment because when you assign a new virtual address to the interface broadcast is done and all hosts that have that ip in the arp cache are updated. It is clearly stated in arp protocol that ip address can be moved from host to host, that is why arp spoofing works. The problem with mac address is that you can have only one per interface and I would like to have more virtual addresses per interface. If I wanted to have five ip addresses per host I would need to have five mac addresses at the same time on the same interface which is as far as I know not so possible, especially using only shell tools. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 7:16:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hnmail7.dac.migros.ch (mail2.gmaare.migros.ch [164.14.132.116]) by hub.freebsd.org (Postfix) with ESMTP id 7918537B400 for ; Wed, 24 Jan 2001 07:16:26 -0800 (PST) Received: by hnmail7.dac.migros.ch with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jan 2001 16:16:16 +0100 Received: from gmaare.migros.net (hunetm03.dac.migros.ch [10.16.61.22]) by hnmail2.dac.migros.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDCK8Y8N; Wed, 24 Jan 2001 16:16:09 +0100 From: Andreas Brodmann To: Dejvid Zaninovic Cc: freebsd-hackers@freebsd.org Message-ID: <3A6EF007.9F06DBF8@gmaare.migros.net> Date: Wed, 24 Jan 2001 16:08:55 +0100 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IP Address Overtaking References: <000e01c08615$ddda4b80$230aa8c0@newyork.mod> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > just a suggestion: In production environments it is a must to also > > take over the cluster partner's mac address. Something that > > would make a nice plus to your script. > > I was thinking about that.... I don't see that this is a must in production > environment because when you assign a new virtual address to the interface > broadcast is done and all hosts that have that ip in the arp cache are > updated. It is clearly stated in arp protocol that ip address can be moved > from host to host, that is why arp spoofing works. On normal internetworking hosts, without the necessity of high availability this works fine. Not all hosts do update or even flush their arp cache with the same frequency though. Some have a cycle of less than one minute on routers on the other hand the default arp cache timeout is a lot higher which would force clients not in the same subnet to wait until the router flushes its arp cache until they can access your FreeBSD machine again. -> not ha compliant. > The problem with mac address is that you can have only one per interface and > I would like to have more virtual addresses per interface. If I wanted to > have five ip addresses per host I would need to have five mac addresses at > the same time on the same interface which is as far as I know not so > possible, especially using only shell tools. There is a way to solve this problem by having a second interface in each cluster partner serving as standby interface. To this interface you assign the mac of its partner's interface and all its interfaces ip addresses. Just a hint: Have a look at scyld.com and Donald Becker's new Linux driver architecture. Many new cards allow for using more than one mac per card even without going into promiscuous mode. They can then be assigned to different subinterfaces. I don't know wheter the FreeBSD drivers support this. Anyway we still keep to the old fashioned way mentionned above, as the new Linux network driver architecture is not yet as stable as it could be, but once it is this would solve your problem. Regards, Andreas --- switch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 7:34:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by hub.freebsd.org (Postfix) with ESMTP id 7373937B400 for ; Wed, 24 Jan 2001 07:34:32 -0800 (PST) Received: from host213-122-255-218.btinternet.com ([213.122.255.218] helo=mail.btinternet.com) by tungsten.btinternet.com with smtp (Exim 3.03 #83) id 14LRwN-0004zT-00 for freebsd-hackers@freebsd.org; Wed, 24 Jan 2001 15:34:31 +0000 Date: Wed, 24 Jan 2001 15:32:28 +0000 From: David Rufino To: freebsd-hackers@freebsd.org Subject: Re: driver help Message-ID: <20010124153228.A5828@btinternet.com> Mail-Followup-To: David Rufino , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mike Smith (msmith@freebsd.org) wrote: > > I am currently trying to port the compatability layer of a linux > > kernel driver to FreeBSD 4.x. The bit I'm stuck on at the moment > > is, how do I map arbitrary physical address space to kernel virtual > > address space (ala ioremap() in linux) ? Thanks. > > You don't. > > If this is a PCI device, it's all done for you when you call > bus_alloc_resource. Ideally I would do this, except I'm porting a compatability layer for a binary module, so I need a function which simply maps I/O space to kernel virtual address space. Is it possible, if not desirable ? -David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 8:17:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nyapp002.mediaondemand.com (mailhost.mediaondemand.com [208.184.36.78]) by hub.freebsd.org (Postfix) with ESMTP id 4911737B402 for ; Wed, 24 Jan 2001 08:17:30 -0800 (PST) Received: from nywst536 (nywst536.newyork.mod [192.168.10.35]) by nyapp002.mediaondemand.com (8.11.2/8.11.2) with SMTP id f0OGHOn08869; Wed, 24 Jan 2001 11:17:24 -0500 (EST) Message-ID: <000701c08620$ec9706d0$230aa8c0@newyork.mod> From: "Dejvid Zaninovic" To: Cc: Subject: Re: IP Address Overtaking Date: Wed, 24 Jan 2001 11:15:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On normal internetworking hosts, without the necessity of high availability > this works fine. Not all hosts do update or even flush their arp cache with > the same frequency though. Some have a cycle of less than one minute on > routers on the other hand the default arp cache timeout is a lot higher which > would force clients not in the same subnet to wait until the router flushes > its arp cache until they can access your FreeBSD machine again. Hosts will not wait for the arp cache to expire because FreeBSD is broadcasting that mac address changed and all hosts must update their cache info if they want to be compliant with arp protocol. Check the arpspoof tool from the dsniff software, it is doing the same thing. > There is a way to solve this problem by having a second interface in each cluster > partner serving as standby interface. To this interface you assign the mac of > its partner's interface and all its interfaces ip addresses. Yes, you could do that if you are using hosts which are not compliant with arp protocol, but I don't plan to use such hosts, all unix boxes, routers and windows are compliant, so I don't see the reason to complicate things with the mac address changing, you rarely need this. > Just a hint: Have a look at scyld.com and Donald Becker's new Linux driver > architecture. Many new cards allow for using more than one mac per card > even without going into promiscuous mode. They can then be assigned to > different subinterfaces. I don't know wheter the FreeBSD drivers support > this. Anyway we still keep to the old fashioned way mentionned above, as the > new Linux network driver architecture is not yet as stable as it could be, but > once it is this would solve your problem. You would probably have to change driver to support this for each card you plan to use. Again, I don't see any reason to overtake mac address. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 8:38:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B0A437B404 for ; Wed, 24 Jan 2001 08:38:40 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id JAA77841; Wed, 24 Jan 2001 09:36:18 -0700 (MST) Date: Wed, 24 Jan 2001 09:36:18 -0700 (MST) From: Nick Rogness To: Andreas Brodmann Cc: Dejvid Zaninovic , freebsd-hackers@freebsd.org Subject: Re: IP Address Overtaking In-Reply-To: <3A6EF007.9F06DBF8@gmaare.migros.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 Wed, 24 Jan 2001, Andreas Brodmann wrote: > > On normal internetworking hosts, without the necessity of high availability > this works fine. Not all hosts do update or even flush their arp cache with > the same frequency though. Some have a cycle of less than one minute on > routers on the other hand the default arp cache timeout is a lot higher which > would force clients not in the same subnet to wait until the router flushes > its arp cache until they can access your FreeBSD machine again. > -> not ha compliant. The time it takes to flush is very small. During that time the router queue's up the request and waits for a reply. Once the router has it, everything is transparent. I would not recommend playing with MAC addresses at all. Switch things using IP and let the ARP protocol take care of itself. > There is a way to solve this problem by having a second interface in each > cluster > partner serving as standby interface. To this interface you assign the mac of > its > partner's interface and all its interfaces ip addresses. > > Just a hint: Have a look at scyld.com and Donald Becker's new Linux driver > architecture. Many new cards allow for using more than one mac per card > even without going into promiscuous mode. They can then be assigned to > different subinterfaces. I don't know wheter the FreeBSD drivers support > this. Anyway we still keep to the old fashioned way mentionned above, as the > new Linux network driver architecture is not yet as stable as it could be, but > once it is this would solve your problem. I think this is a bad idea in a clustering enviroment. You are taking the job of a switch and moving it to the card/software by fiddling with MAC addresses on the hosts. I guess I can see where this may be useful (trunking) but taking over the MAC could cause problems...like duplicate MAC's etc,etc. Of course, this is my opinion and I could be wrong. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 9:47:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sttlpop3.sttl.uswest.net (sttlpop3.sttl.uswest.net [206.81.192.3]) by hub.freebsd.org (Postfix) with SMTP id CF4DB37B400 for ; Wed, 24 Jan 2001 09:47:23 -0800 (PST) Received: (qmail 8957 invoked by alias); 24 Jan 2001 17:47:13 -0000 Delivered-To: fixup-freebsd-hackers@FreeBSD.org@fixme Received: (qmail 8749 invoked by uid 0); 24 Jan 2001 17:47:09 -0000 Received: from www.a6l.net (HELO a6l.net) (63.229.13.49) by sttlpop3.sttl.uswest.net with SMTP; 24 Jan 2001 17:47:09 -0000 Received: (qmail 69549 invoked by uid 1002); 24 Jan 2001 17:47:21 -0000 To: freebsd-hackers@FreeBSD.org Subject: pthreads and kqueue From: Kevin Mills Date: 24 Jan 2001 09:47:21 -0800 Message-ID: <85ofwwkfkm.fsf@diablo.in.a6l.net> Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A little background: I have an application that uses kqueue to manage many, many sockets (and it works wonderfully, btw). I'm using non-blocking I/O, so my application can certainly work without threads. However, each incoming connection needs to access a back-end RADIUS or LDAP server and, due to the libraries I must use, these accesses do block. My question: Is it considered "safe" to have a number of threads each waiting on a call to kevent() using the same kqueue? Or do I need to have one thread waiting on the kevent() call and have it dispatch jobs to the waiting threads? For simplicity reasons, I would like to have each thread waiting on a kevent() call, but I want to ensure I wouldn't get strange behavior - like more than one thread waking up for the same event or other strangeness. I've looked at kern_event.c and it looks like I'll be OK, but I am not intimately familiar with kevent's workings, so hopefully someone can give me an educated answer :) Thanks for any help! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 10: 3:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from codex.cis.upenn.edu (CODEX.CIS.UPENN.EDU [158.130.6.15]) by hub.freebsd.org (Postfix) with ESMTP id 3C9EE37B401 for ; Wed, 24 Jan 2001 10:03:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by codex.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f0OI38T07650; Wed, 24 Jan 2001 13:03:08 -0500 (EST) Date: Wed, 24 Jan 2001 13:03:08 -0500 (EST) From: AARON J MARKS To: ycardena@yahoo.com Cc: hackers@freebsd.org, Ronald Minnich Subject: Re: Kernel programming (fwd) 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 Have you tried remote gdb kernel debugging yet? It's documented in the handbook also. I found it to be very easy to do and *much* better than debugging on the same machine. All you need is a serial cable and a spare FreeBSD machine. I used it to debug a module, but it would work just as well on the kernel itself. -A. On Tue, 23 Jan 2001, Ronald G Minnich wrote: > ---------- Forwarded message ---------- > Date: Tue, 23 Jan 2001 12:20:56 +0100 > From: Alexander Langer > To: Dag-Erling Smorgrav > Cc: Yonny Cardenas B. , questions@FreeBSD.ORG, > hackers@FreeBSD.ORG > Subject: Re: Kernel programming > > Thus spake Dag-Erling Smorgrav (des@ofug.org): > > > > There recently (last week or something) was a thread here or on > > > another mailinglist on how to debug kernel moduls, which is a little > > > bit tricky. > > It's also documented in the handbook. > > Well, actually debugging modules is a little bit more tricky than > debugging kernels with statically linked drivers. > > This is what I meant. > > Alex > -- > cat: /home/alex/.sig: No such file or directory > > > 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 Jan 24 10:11: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id 0BD6D37B404 for ; Wed, 24 Jan 2001 10:10:49 -0800 (PST) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id NAA21343; Wed, 24 Jan 2001 13:10:44 -0500 (EST) To: Jos Backus Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD doesn't recognize keyboard unless is plugged in at boot t ime. References: <8D18712B2604D411A6BB009027F644980DD87C@0SEA01EXSRV1> <20010123232146.A97946@lizzy.bugworks.com> From: Chris Shenton Date: 24 Jan 2001 13:10:44 -0500 In-Reply-To: Jos Backus's message of "Tue, 23 Jan 2001 23:21:46 -0800" Message-ID: Lines: 10 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 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, 23 Jan 2001 23:21:46 -0800, Jos Backus said: Jos> I have the same problem with a Win2k system and a FreeBSD system Jos> connected to an OmniCube 4-port switch, at rev. 1.5 (see the Jos> bottom of the unit). Belkin says it's fixed in rev. 1.9 and is Jos> willing to exchange the unit for a newer one. I recently got a Belkin OmniCube 4-port and it seems to allow FreeBSD machines to boot fine, even if the machine in question is NOT selected. A glance at the bootom indicates "V 1.9". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 10:28:12 2001 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 50C1D37B402 for ; Wed, 24 Jan 2001 10:27:42 -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 LAA00190 for ; Wed, 24 Jan 2001 11:27:40 -0700 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( Tumbleweed MMS SMTP Relay(WSS) v4.5); Wed, 24 Jan 2001 11:27:40 -0700 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id ; Wed, 24 Jan 2001 11:27:39 -0700 Message-ID: <8D18712B2604D411A6BB009027F644980DD880@0SEA01EXSRV1> From: "Matt Simerson" To: "'freebsd-hackers@freebsd.org'" Subject: RE: FreeBSD doesn't recognize keyboard unless is plugged in at bo ot t ime. Date: Wed, 24 Jan 2001 11:26:52 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 1671C116978-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Heeeyyyyy, thank you guys. That is very useful information. I just got off the phone with Belkin and my replacement KVM is on the way.... Thanks, Matt > -----Original Message----- > From: Chris Shenton [mailto:cshenton@OutBounderInc.com] > Sent: Wednesday, January 24, 2001 10:11 AM > To: Jos Backus > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: FreeBSD doesn't recognize keyboard unless is > plugged in at > boot t ime. > > > On Tue, 23 Jan 2001 23:21:46 -0800, Jos Backus said: > > Jos> I have the same problem with a Win2k system and a FreeBSD system > Jos> connected to an OmniCube 4-port switch, at rev. 1.5 (see the > Jos> bottom of the unit). Belkin says it's fixed in rev. 1.9 and is > Jos> willing to exchange the unit for a newer one. > > I recently got a Belkin OmniCube 4-port and it seems to allow FreeBSD > machines to boot fine, even if the machine in question is NOT > selected. A glance at the bootom indicates "V 1.9". > > > 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 Jan 24 10:46:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gypsy.vrac.iastate.edu (gypsy.vrac.iastate.edu [129.186.232.122]) by hub.freebsd.org (Postfix) with ESMTP id 4F91037B402 for ; Wed, 24 Jan 2001 10:46:27 -0800 (PST) Received: from 137.org (howe-193-222.dhcp.iastate.edu [129.186.193.222]) by gypsy.vrac.iastate.edu (Postfix) with ESMTP id CEB6819; Wed, 24 Jan 2001 12:46:26 -0600 (CST) Message-ID: <3A6F2302.1C35E034@137.org> Date: Wed, 24 Jan 2001 12:46:26 -0600 From: Chris 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 Cc: arla-drinkers@stacken.kth.se Subject: FreeBSD Linux emulation / arla 0.34.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have discovered a rather interesting bug with this combination, and was wondering if anyone could point me in the right direction to help me track it down. The problem is that linux binaries which call getdirents on an afs directory do not report the last directory entry: /afs/whatever% /bin/ls -f 1 2 3 4 /afs/whatever% /compat/linux/bin/ls 1 2 3 I believe that this might also be what is causing linux-netscape to wedge the machine (with home directories on afs), although I'm not positive. Any ideas where to start the search for the offending code? Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 10:50:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gypsy.vrac.iastate.edu (gypsy.vrac.iastate.edu [129.186.232.122]) by hub.freebsd.org (Postfix) with ESMTP id 8954C37B400 for ; Wed, 24 Jan 2001 10:50:29 -0800 (PST) Received: from 137.org (howe-193-222.dhcp.iastate.edu [129.186.193.222]) by gypsy.vrac.iastate.edu (Postfix) with ESMTP id 6C88119; Wed, 24 Jan 2001 12:50:29 -0600 (CST) Message-ID: <3A6F23F5.EF559FA0@137.org> Date: Wed, 24 Jan 2001 12:50:29 -0600 From: Chris 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 Cc: arla-drinkers@stacken.kth.se Subject: Re: FreeBSD Linux emulation / arla 0.34.6 References: <3A6F2302.1C35E034@137.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Silly me--I forgot to mention, this is with FreeBSD 4.2-STABLE. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 11: 7:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ducky.nz.freebsd.org (ns1.unixathome.org [203.79.82.27]) by hub.freebsd.org (Postfix) with ESMTP id A670B37B400 for ; Wed, 24 Jan 2001 11:06:59 -0800 (PST) Received: from xeon (xeon.unixathome.org [192.168.0.18]) by ducky.nz.freebsd.org (8.9.3/8.9.3) with SMTP id IAA13287; Thu, 25 Jan 2001 08:06:45 +1300 (NZDT) Message-Id: <200101241906.IAA13287@ducky.nz.freebsd.org> To: Ben Smithurst Cc: FreeBSD Current Users From: Dan Langille , Warner Losh Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake Date: Wed, 24 Jan 2001 19:06:46 GMT X-Mailer: Endymion MailMan Professional Edition v3.0.29 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Warner Losh wrote: > > > In message <200101220910.WAA24873@ducky.nz.freebsd.org> "Dan Langille" writes: > > : http://www.freebsd.org/handbook/kernelconfig-building.html > > > > This change should do the trick if I'm reading things right. > > It's still KERNEL= in -stable though I think. I think I'll just add a > which says "in -current use KERNCONF instead of KERNEL". When > -stable uses KERNCONF too this ugliness can go. > > In fact, I just have committed this. Thanks Ben. As the pri^W person who started this, I'm happy with the way it's turned out. I'll keep an eye on the number of confused users and see what difference it makes. Thanks folks. --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 11:12:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obivon.nren.nasa.gov (obivon.nren.nasa.gov [198.10.1.39]) by hub.freebsd.org (Postfix) with ESMTP id ABEEA37B400; Wed, 24 Jan 2001 11:12:28 -0800 (PST) Received: from localhost (matt@localhost) by obivon.nren.nasa.gov (8.10.2/8.10.2) with ESMTP id f0OJCO615395; Wed, 24 Jan 2001 11:12:24 -0800 (PST) X-Authentication-Warning: obivon.nren.nasa.gov: matt owned process doing -bs Date: Wed, 24 Jan 2001 11:12:24 -0800 (PST) From: Matt Chew Spence To: Lawrence Sica Cc: Guillermo Leandro , , Subject: Re: Default users and the passwords In-Reply-To: <3A6E7F77.6DFC4A3E@interactivate.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 Another question in a similar vein: Which, if any (besides root and nobody, which are a given), of these default accounts are critical to the basic functionality of the box? Is there a list somewhere where I can match these phantom/daemon users to their functionality/dependencies? I'd just as soon blow away things I'll never use, (uucp, xten, etc), but I am loathe to do so without a better understanding of the ramifications thereof.... Any information would be greatly appreciated, Matt On Tue, 23 Jan 2001, Lawrence Sica wrote: > Guillermo Leandro wrote: > > > Hi everybody! > > > > FreeBSD, like almost all Unix OS, has other default users, like uucp, > > operator, etc. Since this users cames with the FreeBSD distribution, where > > can I find their passwords? > > > > they don't have any, the pseudo users and system accounts dont have a login > shell and their passwords should be set to * as well. Be careful if you > remove them since on a make world certain users are expected, same with > groups. > > > > > Another thing, why is there another uid 0 called toor? Isn't it a potential > > security hole? > > > > toor is a big debate for many, its meant to give you another root shell with > a differing shell, like bash,zsh,ksh whatever. Reason is you dont wan to mess > with root's shell. Someone compared root to a loaded weapon recently, its a > good analogy since you dont use root unless you mean it and you have to be > careful. > > --Larry > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Matt Chew Spence Network Engineer/Systems Engineer matt@nren.nasa.gov NASA Research & Education Network (650) 604-4550 (voice) Ames Research Center Mail Stop 233-21 (650) 604-3080 (fax) Moffett Field, CA 94035-1000 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 11:19:31 2001 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 CC51237B698 for ; Wed, 24 Jan 2001 11:19:10 -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 OAA68060; Wed, 24 Jan 2001 14:15:08 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010124141209.02782aa0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 24 Jan 2001 14:20:26 -0500 To: David Rufino , freebsd-hackers@FreeBSD.ORG From: Dennis Subject: Re: driver help In-Reply-To: <20010124153228.A5828@btinternet.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:32 AM 01/24/2001, David Rufino wrote: >* Mike Smith (msmith@freebsd.org) wrote: > > > I am currently trying to port the compatability layer of a linux > > > kernel driver to FreeBSD 4.x. The bit I'm stuck on at the moment > > > is, how do I map arbitrary physical address space to kernel virtual > > > address space (ala ioremap() in linux) ? Thanks. > > > > You don't. > > > > If this is a PCI device, it's all done for you when you call > > bus_alloc_resource. > >Ideally I would do this, except I'm porting a compatability layer for >a binary module, so I need a function which simply maps I/O space to >kernel virtual address space. Is it possible, if not desirable ? You can use vaddr_t pmap_mapdev(paddr,size) to map any physical memory address. Of course you never know when these "old friend" routines will disappear. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 12:21:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from kweetal.tue.nl (kweetal.tue.nl [131.155.2.7]) by hub.freebsd.org (Postfix) with ESMTP id 14CE137B402 for ; Wed, 24 Jan 2001 12:21:05 -0800 (PST) Received: from hermes.tue.nl (hermes.tue.nl [131.155.2.46]) by kweetal.tue.nl (8.11.0/8.11.0) with ESMTP id f0OKKth12298; Wed, 24 Jan 2001 21:21:01 +0100 (MET) Received: from deathstar (t-27-92.athome.tue.nl [131.155.228.92]) by hermes.tue.nl (Postfix) with ESMTP id 2CE7E2E802; Wed, 24 Jan 2001 21:20:55 +0100 (CET) From: "Marco van de Voort" To: Chris Date: Wed, 24 Jan 2001 21:21:12 +0100 Subject: Re: FreeBSD Linux emulation / arla 0.34.6 Cc: arla-drinkers@stacken.kth.se, freebsd-hackers@freebsd.org Message-ID: <3A6F4748.15758.2090E6@localhost> In-reply-to: <3A6F2302.1C35E034@137.org> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have discovered a rather interesting bug with this combination, > and was wondering if anyone could point me in the right direction > to help me track it down. > > The problem is that linux binaries which call getdirents on an afs > directory do not report the last directory entry: Hmm. Could it be getdirentries itself, or some oddity that is not documented, but worked around in libc? I also have some getdirentries (FreeBSD version, patched together I directly admit) based code that sometimes doesn't seem to be able to find certain directories. 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 Wed Jan 24 12:24:42 2001 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 86CB537B400 for ; Wed, 24 Jan 2001 12:24:24 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0OKOGl33308; Wed, 24 Jan 2001 21:24:16 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Marco van de Voort" Cc: Chris , arla-drinkers@stacken.kth.se, freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD Linux emulation / arla 0.34.6 In-Reply-To: Your message of "Wed, 24 Jan 2001 21:21:12 +0100." <3A6F4748.15758.2090E6@localhost> Date: Wed, 24 Jan 2001 21:24:16 +0100 Message-ID: <33306.980367856@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A6F4748.15758.2090E6@localhost>, "Marco van de Voort" writes: >> I have discovered a rather interesting bug with this combination, >> and was wondering if anyone could point me in the right direction >> to help me track it down. >> >> The problem is that linux binaries which call getdirents on an afs >> directory do not report the last directory entry: > >Hmm. Could it be getdirentries itself, or some oddity that is not >documented, but worked around in libc? I also have some >getdirentries (FreeBSD version, patched together I directly admit) >based code that sometimes doesn't seem to be able to find certain >directories. I had some fun with it when playing with a TOYFS of mine. Take a peek in the libc sources, there are som assumptions which may surprise you. -- 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 Jan 24 13:25:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.interactivate.com (unknown [63.141.73.15]) by hub.freebsd.org (Postfix) with ESMTP id 6128037B400; Wed, 24 Jan 2001 13:25:11 -0800 (PST) Received: from interactivate.com ([63.141.73.10]) by mail.interactivate.com (8.11.1/8.11.1) with ESMTP id f0OLl0V70626; Wed, 24 Jan 2001 13:47:00 -0800 (PST) (envelope-from larry@interactivate.com) Message-ID: <3A6F4689.A3E65177@interactivate.com> Date: Wed, 24 Jan 2001 13:18:01 -0800 From: Lawrence Sica Organization: Interactivate, Inc X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matt Chew Spence Cc: Guillermo Leandro , freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Default users and the passwords References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Chew Spence wrote: > > Another question in a similar vein: > > Which, if any (besides root and nobody, which are a given), of these > default accounts are critical to the basic functionality of the box? Is > there a list somewhere where I can match these phantom/daemon users to > their functionality/dependencies? I'd just as soon blow away things I'll > never use, (uucp, xten, etc), but I am loathe to do so without a better > understanding of the ramifications thereof.... > The big issue if it can break make worlds. Make world expects cerain users and groups. If your not running hte services, star out the passwords and make sure they have a nologin shell. That probably the safest bet. --Larry -- Lawrence Sica ------------------------------------------- larry@interactivate.com systems Administrator - Interactivate, Inc. http://www.interactivate.com ------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 13:46:44 2001 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 B8E6237B400 for ; Wed, 24 Jan 2001 13:46:27 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f0OLkPj05828 for ; Wed, 24 Jan 2001 16:46:25 -0500 (EST) Date: Wed, 24 Jan 2001 16:46:23 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@onyx To: freebsd-hackers@freebsd.org Subject: buffer headers in FreeBSD & Linux 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 am wondering why FreeBSD has fixed number of buffer headers (nbuf) while Linux can grow the number of buffer headers on the fly. In FreeBSD, we have a lofreebuffers count. I think this is a reserve for avoiding deadlock when the buffer headers are low. But Linux does not seem to have such a counter. How do they solve this problems? What's the pros and cons of these two different schemes? 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 Jan 24 14: 0:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by hub.freebsd.org (Postfix) with ESMTP id 84EDD37B400 for ; Wed, 24 Jan 2001 14:00:00 -0800 (PST) Received: from HSE-QCity-ppp94185.qc.sympatico.ca ([64.230.224.150]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010124215959.EVNS11735.tomts6-srv.bellnexxia.net@HSE-QCity-ppp94185.qc.sympatico.ca> for ; Wed, 24 Jan 2001 16:59:59 -0500 Date: Wed, 24 Jan 2001 17:04:23 -0500 (EST) From: Felix-Antoine Paradis To: Subject: IDE CDRW 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 -----BEGIN PGP SIGNED MESSAGE----- Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? Thank's . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Felix-Antoine Paradis . cell: 1-418-261-0865 . . IRC: reel @ DALnet . job: Idemnia Network . . Email: reel@sympatico.ca . *** www.FreeBSD.org *** . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ."Without virtue, happiness cannot be." . . --Thomas Jefferson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBOm9RdxcIKY4ZDBRpAQHmWQP/b9GsH2IsIu3a78eUGeE1uN31Lfq0eceM ZEmO0FtSKG4hTCoSeSE2OHDlOsWuDZnGrNEfHyoMZuAHRErRMJyTLXEAjBr6QHaE 4bLorNRdKOSR9cnkEnSDEBo/FMvxdYkzQhhwyQZaqRYC6T8S50JeSeFGo0LrlX/n cOmNlXOsYjo= =hZas -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 14: 1: 3 2001 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 96FE037B402; Wed, 24 Jan 2001 14:00:43 -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 RAA68842; Wed, 24 Jan 2001 17:03:01 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010124170245.03bf6140@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 24 Jan 2001 17:08:16 -0500 To: Mike Smith , dg@root.com From: Dennis Subject: Re: if_fxp driver info Cc: hackers@FreeBSD.ORG In-Reply-To: <200101232033.f0NKXHS01892@mass.dis.org> References: 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 > > > I'll look into the Linux driver, however, and see if it has anything > > useful in it. Historically the Linux Pro/100+ driver has totally sucked and > > was chalk-full of magic numbers being anded and ored. > >That's "chock full", and you're confusing the Becker driver (bad) with >the Intel-supplied driver (slightly less bad). The intel driver seems to cover all the bases and has some nice glue routines for determining the part and features available. I havent tested it under load, but I wonder if intel would consider supporting it if someone ported it over to freebsd? they have drivers for just about every other major OS except BSD. it would be nice if the driver was updated BEFORE cards and MBs that dont work started showing up on the loading dock. Every time I get a shipment we have to hold our breath until we try one out. Dennis >-- >... 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 14:32:28 2001 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 4850037B400 for ; Wed, 24 Jan 2001 14:32:12 -0800 (PST) Received: by peitho.fxp.org (Postfix, from userid 1501) id 2E3E11360C; Wed, 24 Jan 2001 17:32:11 -0500 (EST) Date: Wed, 24 Jan 2001 17:32:11 -0500 From: Chris Faulhaber To: Felix-Antoine Paradis Cc: freebsd-hackers@freebsd.org Subject: Re: IDE CDRW Message-ID: <20010124173210.A50075@peitho.fxp.org> Mail-Followup-To: Chris Faulhaber , Felix-Antoine Paradis , freebsd-hackers@freebsd.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 reel@idemnia.ath.cx on Wed, Jan 24, 2001 at 05:04:23PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 05:04:23PM -0500, Felix-Antoine Paradis wrote: > Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? > Not sure if that is a question or not, but you probably want to look over ata(4) and burncd(8). -- 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 Wed Jan 24 14:38:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id E717437B400 for ; Wed, 24 Jan 2001 14:38:38 -0800 (PST) Received: from HSE-QCity-ppp94185.qc.sympatico.ca ([64.230.224.150]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010124223837.QODC27935.tomts5-srv.bellnexxia.net@HSE-QCity-ppp94185.qc.sympatico.ca>; Wed, 24 Jan 2001 17:38:37 -0500 Date: Wed, 24 Jan 2001 17:43:14 -0500 (EST) From: Felix-Antoine Paradis To: Chris Faulhaber Cc: Subject: Re: IDE CDRW In-Reply-To: <20010124173210.A50075@peitho.fxp.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 -----BEGIN PGP SIGNED MESSAGE----- I don't have theses installed here, not even in my port tree... you know where i could get them? Thank's On Wed, 24 Jan 2001, Chris Faulhaber wrote: > On Wed, Jan 24, 2001 at 05:04:23PM -0500, Felix-Antoine Paradis wrote: > > Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? > > > > Not sure if that is a question or not, but you probably want to look > over ata(4) and burncd(8). > > -- > 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 > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Felix-Antoine Paradis . cell: 1-418-261-0865 . . IRC: reel @ DALnet . job: Idemnia Network . . Email: reel@sympatico.ca . *** www.FreeBSD.org *** . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ."1029 push-ups a day keeps the Hells Angels away..." . . --Thomas Jefferson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBOm9ahhcIKY4ZDBRpAQGWKQP/aUYHO2vcA9vPpaAu6J4c3Ht48Ea5ODii uZjM8k9qmJaHef3k0yD662/UPTY0EH4PuucfP2q1fPhMAz0ElXHYdbRr/pWMnABI AQAS/DRNHLkFrIXz1OnMpzLr+bzuvJpNx9uoU2bHvpxXw85OKTreG+/gvmI+tjDo RSQHlDYMeC8= =Zygk -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 14:42: 0 2001 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 7907B37B400 for ; Wed, 24 Jan 2001 14:41:42 -0800 (PST) Received: (qmail 61713 invoked from network); 24 Jan 2001 22:41:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 24 Jan 2001 22:41:40 -0000 Received: (qmail 7382 invoked from network); 24 Jan 2001 22:41:40 -0000 Received: from explorer.rsa.com (10.81.217.59) by spirit.dynas.se with SMTP; 24 Jan 2001 22:41:40 -0000 Received: (from mikko@localhost) by explorer.rsa.com (8.11.1/8.11.1) id f0OMfW813325; Wed, 24 Jan 2001 14:41:32 -0800 (PST) (envelope-from mikko) Date: Wed, 24 Jan 2001 14:41:32 -0800 (PST) From: Mikko Tyolajarvi Message-Id: <200101242241.f0OMfW813325@explorer.rsa.com> To: reel@idemnia.ath.cx Cc: freebsd-hackers@freebsd.org Subject: Re: IDE CDRW Newsgroups: local.freebsd.hackers References: 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: >-----BEGIN PGP SIGNED MESSAGE----- >Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? See burncd(1). I know for a fact that it works with: acd0: CD-RW at ata1-master using WDMA2 Don't think you can use IDE CD/RW with any programs that expect a SCSI drive, though (i.e. the atapi interfacve does not emulate SCSI, AFAIK). $.02, /Mikko -- Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 14:42: 5 2001 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 E7BC737B401 for ; Wed, 24 Jan 2001 14:41:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f0OMfkF01542 for ; Wed, 24 Jan 2001 17:41:46 -0500 (EST) Date: Wed, 24 Jan 2001 17:41:46 -0500 (EST) From: Alwyn Goodloe To: hackers@FreeBSD.ORG Subject: Divert Sockets & Fragmentation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been using divert sockets for a while sending small (< MTU) UDP packets and everything worked fine. Now that the UDP packets are larger (>MTU = 1500) and hence fragmentation is taking place there seems to be a problem. tcpdump tells me that the fragmented packets arrive but it seems that they are never diverted. I say this because after they are received recvfrom () never gets the packet. I've done things like play with the nbytes field of the recvfrom() fn. without any success. Any suggestions, I'm sure its something stupid. Alwyn 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 Jan 24 14:45:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 6E5F237B400 for ; Wed, 24 Jan 2001 14:45:32 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0OMjUX20166; Wed, 24 Jan 2001 14:45:30 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101242245.f0OMjUX20166@iguana.aciri.org> Subject: Re: Divert Sockets & Fragmentation In-Reply-To: from Alwyn Goodloe at "Jan 24, 2001 5:41:46 pm" To: agoodloe@gradient.cis.upenn.edu (Alwyn Goodloe) Date: Wed, 24 Jan 2001 14:45:30 -0800 (PST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG it depends on what template do you use for matching. the firewall acts before reassembly, so for the fragments you will not be able to see the port numbers. cheers luigi > I have been using divert sockets for a while sending small (< MTU) UDP > packets and everything worked fine. Now that the UDP packets are larger > (>MTU = 1500) and hence fragmentation is taking place there seems to be a > problem. tcpdump tells me that the fragmented packets arrive but it seems > that they are never diverted. I say this because after they are received > recvfrom () never gets the packet. I've done things like play with the > nbytes field of the recvfrom() fn. without any success. Any > suggestions, I'm sure its something stupid. > > > Alwyn > 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 Wed Jan 24 15: 0:30 2001 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 C605437B402 for ; Wed, 24 Jan 2001 15:00:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f0ON0AF03518; Wed, 24 Jan 2001 18:00:10 -0500 (EST) Date: Wed, 24 Jan 2001 18:00:10 -0500 (EST) From: Alwyn Goodloe To: Luigi Rizzo Cc: hackers@FreeBSD.ORG Subject: Re: Divert Sockets & Fragmentation In-Reply-To: <200101242245.f0OMjUX20166@iguana.aciri.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 was originally diverting udp packets heading to a particular port then I flushed the ipfw and tried: ipfw add 60000 divert 4422 ip all from any to any in and still no packets are received by recvfrom(). Would the port numbers matter for this case. Alwyn agoodloe@gradient.cis.upenn.edu On Wed, 24 Jan 2001, Luigi Rizzo wrote: > it depends on what template do you use for matching. > the firewall acts before reassembly, so for the fragments you will > not be able to see the port numbers. > > cheers > luigi > > > I have been using divert sockets for a while sending small (< MTU) UDP > > packets and everything worked fine. Now that the UDP packets are larger > > (>MTU = 1500) and hence fragmentation is taking place there seems to be a > > problem. tcpdump tells me that the fragmented packets arrive but it seems > > that they are never diverted. I say this because after they are received > > recvfrom () never gets the packet. I've done things like play with the > > nbytes field of the recvfrom() fn. without any success. Any > > suggestions, I'm sure its something stupid. > > > > > > Alwyn > > 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 Wed Jan 24 15: 1:54 2001 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 7BE9437B401 for ; Wed, 24 Jan 2001 15:01:34 -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 OAA24180; Wed, 24 Jan 2001 14:51:38 -0800 (PST) Message-Id: <200101242251.OAA24180@implode.root.com> To: Dennis Cc: hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-reply-to: Your message of "Wed, 24 Jan 2001 17:08:16 EST." <5.0.0.25.0.20010124170245.03bf6140@mail.etinc.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 24 Jan 2001 14:51:38 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > I'll look into the Linux driver, however, and see if it has anything >> > useful in it. Historically the Linux Pro/100+ driver has totally sucked and >> > was chalk-full of magic numbers being anded and ored. >> >>That's "chock full", and you're confusing the Becker driver (bad) with >>the Intel-supplied driver (slightly less bad). > > >The intel driver seems to cover all the bases and has some nice glue >routines for determining the part and features available. > >I havent tested it under load, but I wonder if intel would consider >supporting it if someone ported it over to freebsd? they have drivers for >just about every other major OS except BSD. it would be nice if the driver >was updated BEFORE cards and MBs that dont work started showing up on the >loading dock. Every time I get a shipment we have to hold our breath until >we try one out. "drivers for every major OS"? They have drivers for Windows, Window/NT, and Linux. Of those Linux is the closest to FreeBSD, but that's like saying that a penguin is similar to a human because they are both mammals. After looking at the driver source, it's my opinion that porting it to FreeBSD would be a major undertaking and it would likely be easier to just rewrite it from scratch. In total it is more than 14,000 lines of code - much of which is highly specific to the Linux internals. The current FreeBSD driver, by comparison, is about 2600 lines of code and a whole lot easier to read and maintain. I do believe that there are some useful tidbits to be gotten out of the Intel/Linux driver, but that's about it. -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 Wed Jan 24 15: 1:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 85C7537B402 for ; Wed, 24 Jan 2001 15:01:40 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0ON1cX21729; Wed, 24 Jan 2001 15:01:38 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101242301.f0ON1cX21729@iguana.aciri.org> Subject: Re: Divert Sockets & Fragmentation In-Reply-To: from Alwyn Goodloe at "Jan 24, 2001 6: 0:10 pm" To: agoodloe@gradient.cis.upenn.edu (Alwyn Goodloe) Date: Wed, 24 Jan 2001 15:01:38 -0800 (PST) Cc: rizzo@aciri.org, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I was originally diverting udp packets heading to a particular port then > I flushed the ipfw and tried: > > ipfw add 60000 divert 4422 ip all from any to any in > and still no packets are received by recvfrom(). Would the port numbers > matter for this case. probably not but better check if you have any former rule which matches fragments luigi > Alwyn > agoodloe@gradient.cis.upenn.edu > > > > > > On Wed, 24 Jan 2001, Luigi Rizzo wrote: > > > it depends on what template do you use for matching. > > the firewall acts before reassembly, so for the fragments you will > > not be able to see the port numbers. > > > > cheers > > luigi > > > > > I have been using divert sockets for a while sending small (< MTU) UDP > > > packets and everything worked fine. Now that the UDP packets are larger > > > (>MTU = 1500) and hence fragmentation is taking place there seems to be a > > > problem. tcpdump tells me that the fragmented packets arrive but it seems > > > that they are never diverted. I say this because after they are received > > > recvfrom () never gets the packet. I've done things like play with the > > > nbytes field of the recvfrom() fn. without any success. Any > > > suggestions, I'm sure its something stupid. > > > > > > > > > Alwyn > > > 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 Wed Jan 24 15: 3:37 2001 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 1E62637B400 for ; Wed, 24 Jan 2001 15:03:20 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0ON3Cl34793; Thu, 25 Jan 2001 00:03:12 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: dg@root.com Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-Reply-To: Your message of "Wed, 24 Jan 2001 14:51:38 PST." <200101242251.OAA24180@implode.root.com> Date: Thu, 25 Jan 2001 00:03:12 +0100 Message-ID: <34791.980377392@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101242251.OAA24180@implode.root.com>, David Greenman writes: > "drivers for every major OS"? They have drivers for Windows, Window/NT, >and Linux. Of those Linux is the closest to FreeBSD, but that's like saying that a penguin is similar to a human because they are both mammals. Pinguins are birds... -- 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 Jan 24 15:55:53 2001 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 E69E537B401 for ; Wed, 24 Jan 2001 15:55:33 -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 PAA24374; Wed, 24 Jan 2001 15:44:23 -0800 (PST) Message-Id: <200101242344.PAA24374@implode.root.com> To: Poul-Henning Kamp Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-reply-to: Your message of "Thu, 25 Jan 2001 00:03:12 +0100." <34791.980377392@critter> From: David Greenman Reply-To: dg@root.com Date: Wed, 24 Jan 2001 15:44:23 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >In message <200101242251.OAA24180@implode.root.com>, David Greenman writes: > >> "drivers for every major OS"? They have drivers for Windows, Window/NT, >>and Linux. Of those Linux is the closest to FreeBSD, but that's like saying >that a penguin is similar to a human because they are both mammals. > >Pinguins are birds... Oh, yeah. Well, even more different, then. :-) -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 Wed Jan 24 16:30:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from temphost.dragondata.com (temphost.dragondata.com [63.167.131.128]) by hub.freebsd.org (Postfix) with ESMTP id EBE3337B404 for ; Wed, 24 Jan 2001 16:29:54 -0800 (PST) Received: (from toasty@localhost) by temphost.dragondata.com (8.9.3/8.9.3) id SAA23574; Wed, 24 Jan 2001 18:29:58 -0600 (CST) (envelope-from toasty) From: Kevin Day Message-Id: <200101250029.SAA23574@temphost.dragondata.com> Subject: Pthreads with sprintf/dtoa To: hackers@freebsd.org Date: Wed, 24 Jan 2001 18:29:58 -0600 (CST) Cc: kevin@stileproject.com 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 After upgrading to FreeBSD 4.2(from 4.1) and MySQL 3.23.32 (from 3.22.32), I kept seeing mysqld crashes after a few minutes of heavy load. I traced it down to one rather situation. Every time it crashed, I was getting a segfault inside __dtoa (which was called by sprintf). If I looked at other threads, I'd always see another thread inside __dtoa at that point too. I went back to 3.22.32, and it still happened, so my current guess is something between 4.1-RELEASE and 4.2-RELEASE. I'm really highly ignorant of pthreads, so I have no idea if they(myslqd) is doing something wrong thread-wise, or something got broken so that it's no longer thread safe inside sprintf or dtoa. Can someone cluefull point me in the right direction? -- Kevin Forwarded message: > From toasty Wed Jan 24 17:55:36 2001 > From: Kevin Day > Message-Id: <200101242355.RAA21536@temphost.dragondata.com> > Subject: Re: Field_float::val_str crash in 3.23.32 > To: mysql@lists.mysql.com > Date: Wed, 24 Jan 2001 17:55:31 -0600 (CST) > Cc: toasty@dragondata.com, stile@stileproject.com > In-Reply-To: <20010124153714.A14455@yahoo-inc.com> from "Jeremy D. Zawodny" at Jan 24, 2001 03:37:14 PM > X-Mailer: ELM [version 2.5 PL3] > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > > > On Wed, Jan 24, 2001 at 03:15:48PM -0600, Jeremy D. Zawodny wrote: > > > > Does this only occur when more than one client is accessing the table > > in question? If so, it's a thread-related problem that has been with > > us since FreeBSD 3.x. :-( > > > > It looks like what I've seen before. > > > > I have a re-produceable case that I sent to one of the MySQL > > developers and he was able to see the problem. Tracing it down, > > however, requires someone who knows a lot about FreeBSD threading. > > > > I've found some FreeBSD gurus here who might be able to help. I just > > need a MySQL developer to point them at... > > > > Well, I did find something interesting... Right now, I crashed in thread #1: > > * 1 process 48183, thread 1 0x282c835c in bcopy () from /usr/lib/libc_r.so.4 > > > with the trace: > > #0 0x282c835c in bcopy () from /usr/lib/libc_r.so.4 > #1 0x282da0a8 in _thread_autoinit_dummy_decl () from /usr/lib/libc_r.so.4 > #2 0x282c9cca in __dtoa () from /usr/lib/libc_r.so.4 > #3 0x282c7b3b in vfprintf () from /usr/lib/libc_r.so.4 > #4 0x282c5c56 in vfprintf () from /usr/lib/libc_r.so.4 > #5 0x282b74cd in sprintf () from /usr/lib/libc_r.so.4 > #6 0x806a779 in Field_float::val_str (this=0x8f6bcb8, val_buffer=0xbf68b30c, val_ptr=0xbf68b30c) at field.cc:1849 > #7 0x80671dd in Field::send (this=0x8f6bcb8, packet=0x8a2b420) at field.cc:257 > #8 0x814ae5f in Item_field::send (this=0x8adab60, str_arg=0x8a2b420) at item.h:119 > #9 0x8072612 in select_send::send_data (this=0x8ada6a8, items=@0x8a2b24c) at sql_class.cc:236 > #10 0x80a9207 in end_send (join=0xbf68b75c, join_tab=0x8c88868, end_of_records=false) at sql_select.cc:4521 > #11 0x80a7bc9 in sub_select (join=0xbf68b75c, join_tab=0x8c88750, end_of_records=false) at sql_select.cc:4033 > #12 0x80a7666 in do_select (join=0xbf68b75c, fields=0x8a2b24c, table=0x0, procedure=0x0) at sql_select.cc:3925 > #13 0x809c82f in mysql_select (thd=0x8a2b000, tables=0x8ada0d8, fields=@0x8a2b24c, conds=0x8ada5c8, ftfuncs=@0x8a2b280, > order=0x8ada688, group=0x0, having=0x0, proc_param=0x0, select_options=8950784, result=0x8ada6a8) at sql_select.cc:755 > #14 0x8082331 in mysql_execute_command () at sql_parse.cc:957 > #15 0x808561f in mysql_parse (thd=0x8a2b000, > inBuf=0x8ada010 "SELECT * FROM cp WHERE C11=1 && C12>=1.0 && C13>=1.0 && PL1 > 0 ORDER BY C4 DESC", length=80) > at sql_parse.cc:2085 > #16 0x8081634 in do_command (thd=0x8a2b000) at sql_parse.cc:668 > #17 0x8080938 in handle_one_connection (arg=0x8a2b000) at sql_parse.cc:403 > #18 0x2825b9a7 in _thread_start () from /usr/lib/libc_r.so.4 > #19 0xbf933ffc in ?? () > #20 0x28292f99 in select () from /usr/lib/libc_r.so.4 > #21 0x807d01d in handle_connections_sockets (arg=0x0) at mysqld.cc:2099 > #22 0x807c440 in main (argc=9, argv=0x81d7228) at mysqld.cc:1830 > #23 0x804b2fd in _start () > Using the running image of child process 48183, thread 1. > Program stopped at 0x282c835c. > It stopped with signal SIGSEGV, Segmentation fault. > > > > Notice frame #2. > > > If I look at other threads, I see this: > > 100 process 48183, thread 100 0x282ca140 in __dtoa () from /usr/lib/libc_r.so.4 > > #0 0x282ca140 in __dtoa () from /usr/lib/libc_r.so.4 > #1 0x282c7b3b in vfprintf () from /usr/lib/libc_r.so.4 > #2 0x282c5c56 in vfprintf () from /usr/lib/libc_r.so.4 > #3 0x282b74cd in sprintf () from /usr/lib/libc_r.so.4 > #4 0x806a779 in Field_float::val_str (this=0x90d3448, val_buffer=0xbf9cc30c, val_ptr=0xbf9cc30c) at field.cc:1849 > #5 0x80671dd in Field::send (this=0x90d3448, packet=0x8ba0420) at field.cc:257 > #6 0x814ae5f in Item_field::send (this=0x92d4ac0, str_arg=0x8ba0420) at item.h:119 > #7 0x8072612 in select_send::send_data (this=0x92d46a8, items=@0x8ba024c) at sql_class.cc:236 > #8 0x80a9207 in end_send (join=0xbf9cc75c, join_tab=0x8bc5868, end_of_records=false) at sql_select.cc:4521 > #9 0x80a7bc9 in sub_select (join=0xbf9cc75c, join_tab=0x8bc5750, end_of_records=false) at sql_select.cc:4033 > #10 0x80a7666 in do_select (join=0xbf9cc75c, fields=0x8ba024c, table=0x0, procedure=0x0) at sql_select.cc:3925 > #11 0x809c82f in mysql_select (thd=0x8ba0000, tables=0x92d40d8, fields=@0x8ba024c, conds=0x92d45c8, ftfuncs=@0x8ba0280, > order=0x92d4688, group=0x0, having=0x0, proc_param=0x0, select_options=8950784, result=0x92d46a8) at sql_select.cc:755 > #12 0x8082331 in mysql_execute_command () at sql_parse.cc:957 > #13 0x808561f in mysql_parse (thd=0x8ba0000, > inBuf=0x92d4010 "SELECT * FROM cp WHERE C11=1 && C12>=1.0 && C13>=1.0 && PL1 > 0 ORDER BY C4 DESC", length=80) > at sql_parse.cc:2085 > #14 0x8081634 in do_command (thd=0x8ba0000) at sql_parse.cc:668 > #15 0x8080938 in handle_one_connection (arg=0x8ba0000) at sql_parse.cc:403 > #16 0x2825b9a7 in _thread_start () from /usr/lib/libc_r.so.4 > #17 0xbf7f0ffc in ?? () > #18 0x28292f99 in select () from /usr/lib/libc_r.so.4 > #19 0x807d01d in handle_connections_sockets (arg=0x0) at mysqld.cc:2099 > #20 0x807c440 in main (argc=9, argv=0x81d7228) at mysqld.cc:1830 > #21 0x804b2fd in _start () > > > Is something with sprintf/dtoa not being done in a reentrant/thread-safe > manner? If I look at what's happening with sprintf there, everything mysql > is doing seems correct. > > > > -- Kevin > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 16:36: 1 2001 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 DAFF537B400 for ; Wed, 24 Jan 2001 16:35:43 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0P0Zch25165; Wed, 24 Jan 2001 16:35:38 -0800 (PST) Date: Wed, 24 Jan 2001 16:35:38 -0800 From: Alfred Perlstein To: Kevin Day Cc: hackers@FreeBSD.ORG, kevin@stileproject.com Subject: Re: Pthreads with sprintf/dtoa Message-ID: <20010124163538.H26076@fw.wintelcom.net> References: <200101250029.SAA23574@temphost.dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101250029.SAA23574@temphost.dragondata.com>; from toasty@temphost.dragondata.com on Wed, Jan 24, 2001 at 06:29:58PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kevin Day [010124 16:30] wrote: > > > After upgrading to FreeBSD 4.2(from 4.1) and MySQL 3.23.32 (from 3.22.32), I > kept seeing mysqld crashes after a few minutes of heavy load. I traced it > down to one rather situation. Every time it crashed, I was getting a > segfault inside __dtoa (which was called by sprintf). If I looked at other > threads, I'd always see another thread inside __dtoa at that point too. > > I went back to 3.22.32, and it still happened, so my current guess is > something between 4.1-RELEASE and 4.2-RELEASE. 4.2 has known issues with threads, please try -stable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 16:54: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hokkshideh.jetcafe.org (hokkshideh.jetcafe.org [205.147.43.4]) by hub.freebsd.org (Postfix) with ESMTP id 34B1D37B402 for ; Wed, 24 Jan 2001 16:53:50 -0800 (PST) Received: from hokkshideh.jetcafe.org (localhost [127.0.0.1]) by hokkshideh.jetcafe.org (8.8.8/8.8.5) with ESMTP id QAA29043 for ; Wed, 24 Jan 2001 16:53:39 -0800 (PST) Message-Id: <200101250053.QAA29043@hokkshideh.jetcafe.org> X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.4 #1[UCI] To: freebsd-hackers@freebsd.org Subject: Running FreeBSD off of CDROM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2001 16:53:39 -0800 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was asked recently if it was possible to run a FreeBSD server entirely off of CDROM. Now I know that things like /var need to be writable, and that the initial question as worded was rather naive. However, modulo writable filesystems which can be mounted separately, has anyone ever done something like this? ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< "There is someone willing to argue about any point." --I don't know, but I'll argue any attribution To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 17: 5: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 57A7037B401 for ; Wed, 24 Jan 2001 17:04:44 -0800 (PST) Received: (qmail 85027 invoked by uid 1142); 25 Jan 2001 01:04:43 -0000 Date: 24 Jan 2001 17:04:43 -0800 Date: Wed, 24 Jan 2001 17:04:07 -0800 From: Jason Evans To: smp@freebsd.org Cc: hackers@freebsd.org Subject: SMP Project Status (24 January 2001) Message-ID: <20010124170407.B87569@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A lot of good progress has been made on the SMP project in the past couple of weeks. We are on the verge of being able to move portions of the kernel out of under the Giant lock, which will be the first improvement in performance due to our work, following a long string of developments over the past 6 months that actually (temporarily) decreased performance. John Baldwin is in the process of committing changes that lock accesses to the proc structure. This allows a number of system calls to run without holding Giant, as well as most signal handling. Additionally, a number of other system calls can be made MP-safe with only a moderate amount of additional effort. Jake Burkholder is in the late stages of testing changes that will make the kernel preemptive. As mentioned in the last status report, a number of other tasks hinge on this development. Bosko Milekic has made some important cleanups to mutexes with regard to recursion, and is in the process of completely revamping the mutex API and code structure (converting to non-inlined functions). Dag-Erling Smorgrav has joined the fray and made the zone allocator MP-safe. He has also expressed interest in doing further work locking the VM. Peter Wemm has been a huge help testing and debugging changes with at least John, Jake, and me. I finally committed Jake's condition variable implementation, and completely removed simplelocks from the kernel. Hopefully the sx lock implementation will be committed soon as well. The SMP project page is still at: http://people.freebsd.org/~jasone/smp/ The previous status email can be found at: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=45111+48223+/usr/local/www/db/text/2001/freebsd-smp/20010114.freebsd-smp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 17:51:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 91A5537B401 for ; Wed, 24 Jan 2001 17:51:15 -0800 (PST) Received: from bellatlantic.net (client-151-198-135-12.nnj.dialup.bellatlantic.net [151.198.135.12]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA18535; Wed, 24 Jan 2001 20:50:48 -0500 (EST) Message-ID: <3A6F8677.84C99A7D@bellatlantic.net> Date: Wed, 24 Jan 2001 20:50:47 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: dg@root.com Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info References: <200101242251.OAA24180@implode.root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > > >supporting it if someone ported it over to freebsd? they have drivers for > >just about every other major OS except BSD. it would be nice if the driver > >was updated BEFORE cards and MBs that dont work started showing up on the > >loading dock. Every time I get a shipment we have to hold our breath until > >we try one out. > > "drivers for every major OS"? They have drivers for Windows, Window/NT, > and Linux. Of those Linux is the closest to FreeBSD, but that's like saying Count in SCO as well - that's at least 3 somewhat different drivers, for OpenServer, UnixWare2 (DLPI), UnixWare7 (MDI), plus perversive customized OEM versions for Compaq and ICL. Plus probably they have drivers for Netware and Solaris too. Though if they did not start supporting FreeBSD as it is I doubt very much that they would support a port of their Linux driver to FreeBSD. Maybe the most productive way would be to find contacts at Intel: they use FreeBSD code in their IA-64 BIOS so there is bound to be someone inside Intel with somewhat better knowledge of FreeBSD. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 18: 1:52 2001 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 E806237B400 for ; Wed, 24 Jan 2001 18:01:32 -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 RAA24775; Wed, 24 Jan 2001 17:52:29 -0800 (PST) Message-Id: <200101250152.RAA24775@implode.root.com> To: Sergey Babkin Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-reply-to: Your message of "Wed, 24 Jan 2001 20:50:47 EST." <3A6F8677.84C99A7D@bellatlantic.net> From: David Greenman Reply-To: dg@root.com Date: Wed, 24 Jan 2001 17:52:29 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >David Greenman wrote: >> >> >supporting it if someone ported it over to freebsd? they have drivers for >> >just about every other major OS except BSD. it would be nice if the driver >> >was updated BEFORE cards and MBs that dont work started showing up on the >> >loading dock. Every time I get a shipment we have to hold our breath until >> >we try one out. >> >> "drivers for every major OS"? They have drivers for Windows, Window/NT, >> and Linux. Of those Linux is the closest to FreeBSD, but that's like saying > >Count in SCO as well - that's at least 3 somewhat different drivers, >for OpenServer, UnixWare2 (DLPI), UnixWare7 (MDI), plus >perversive customized OEM versions for Compaq and ICL. Plus >probably they have drivers for Netware and Solaris too. I don't know what list you are looking at, but the download list that I was looking at did not include SCO, Unixware or any other Unix variant except Linux. -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 Wed Jan 24 18:29:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id 35FCB37B404 for ; Wed, 24 Jan 2001 18:29:21 -0800 (PST) Received: from holly.calldei.com ([208.191.149.190]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G7P00E254FH2S@mta5.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Wed, 24 Jan 2001 20:04:30 -0600 (CST) Received: (from chris@localhost) by holly.calldei.com (8.11.1/8.9.3) id f0P26ds08619; Wed, 24 Jan 2001 20:06:40 -0600 (CST envelope-from chris) Date: Wed, 24 Jan 2001 20:06:18 -0600 From: Chris Costello Subject: Re: Running FreeBSD off of CDROM In-reply-to: <200101250053.QAA29043@hokkshideh.jetcafe.org>; from dave@jetcafe.org on Wed, Jan 24, 2001 at 04:53:39PM -0800 To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20010124200618.C776@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200101250053.QAA29043@hokkshideh.jetcafe.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, January 24, 2001, Dave Hayes wrote: > I was asked recently if it was possible to run a FreeBSD server > entirely off of CDROM. Now I know that things like /var need to be > writable, and that the initial question as worded was rather naive. > However, modulo writable filesystems which can be mounted separately, > has anyone ever done something like this? I've never done it personally, but it is extremely possible. What you'd need is a writable medium, preferable a hard disk, with whatever file system you want to use on it, and a CD with a stripped-down FreeBSD installation, complete with a kernel that matches your hardware. When you boot into your CD, and after the CD is mounted as /, mount the disk as a union with the CD /. The result is that you'll have the executables on the CD, but any data being written will go to the disk. It's the same basic model the FreeBSD 'emergency CD' uses--however, the FreeBSD emergency CD mounts an MFS partition for you, instead. I wouldn't be surprised at all if this works out perfectly for you, for whatever reason you need such a setup. -- +-------------------+--------------------------------+ | Chris Costello | If at first you don't succeed, | | chris@calldei.com | you must be a programmer. | +-------------------+--------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 18:46:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 0D96837B401 for ; Wed, 24 Jan 2001 18:46:04 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0P2n8045625; Wed, 24 Jan 2001 18:49:08 -0800 (PST) (envelope-from kris) Date: Wed, 24 Jan 2001 18:48:07 -0800 From: Kris Kennaway To: Matt Chew Spence Cc: Lawrence Sica , Guillermo Leandro , freebsd-hackers@FreeBSD.ORG Subject: Re: Default users and the passwords Message-ID: <20010124184807.H45221@citusc17.usc.edu> References: <3A6E7F77.6DFC4A3E@interactivate.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3VRmKSg17yJg2MZg" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from matt@nren.nasa.gov on Wed, Jan 24, 2001 at 11:12:24AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --3VRmKSg17yJg2MZg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2001 at 11:12:24AM -0800, Matt Chew Spence wrote: >=20 > Another question in a similar vein: >=20 > Which, if any (besides root and nobody, which are a given), of these > default accounts are critical to the basic functionality of the box? Is > there a list somewhere where I can match these phantom/daemon users to > their functionality/dependencies? I'd just as soon blow away things I'll > never use, (uucp, xten, etc), but I am loathe to do so without a better > understanding of the ramifications thereof.... I believe all of them. Just leave them be, they don't consume any resources except for the abstract numerical resource of one UID number. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --3VRmKSg17yJg2MZg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6b5PnWry0BWjoQKURAjGVAKDKQHUqVb2TaqngssDpUvXcf5z0MQCgutkp ba6lUhItxUXqPEScEgyVUmI= =Ec/K -----END PGP SIGNATURE----- --3VRmKSg17yJg2MZg-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 18:48:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 4C76B37B401 for ; Wed, 24 Jan 2001 18:48:05 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0P2pU945679; Wed, 24 Jan 2001 18:51:30 -0800 (PST) (envelope-from kris) Date: Wed, 24 Jan 2001 18:51:29 -0800 From: Kris Kennaway To: Chris Cc: freebsd-hackers@FreeBSD.ORG, arla-drinkers@stacken.kth.se Subject: Re: FreeBSD Linux emulation / arla 0.34.6 Message-ID: <20010124185129.I45221@citusc17.usc.edu> References: <3A6F2302.1C35E034@137.org> <3A6F23F5.EF559FA0@137.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="itqfrb9Qq3wY07cp" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6F23F5.EF559FA0@137.org>; from cc@137.org on Wed, Jan 24, 2001 at 12:50:29PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --itqfrb9Qq3wY07cp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2001 at 12:50:29PM -0600, Chris wrote: > Silly me--I forgot to mention, this is with FreeBSD 4.2-STABLE. How recent -stable? A bug like this was fixed recently. If it's older than a week, Try upgrading :-) Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --itqfrb9Qq3wY07cp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6b5SxWry0BWjoQKURAlP+AJ43L7cewvHnyveM5TK3PskH1iVbnACg/UpV M52bTukbLJEniaGPfjakyW8= =RNNi -----END PGP SIGNATURE----- --itqfrb9Qq3wY07cp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 18:49:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id CFF5037B401 for ; Wed, 24 Jan 2001 18:49:40 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0P2r5j45716; Wed, 24 Jan 2001 18:53:05 -0800 (PST) (envelope-from kris) Date: Wed, 24 Jan 2001 18:53:05 -0800 From: Kris Kennaway To: Felix-Antoine Paradis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: IDE CDRW Message-ID: <20010124185305.J45221@citusc17.usc.edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="8jNwmpfkpox/fiJK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from reel@idemnia.ath.cx on Wed, Jan 24, 2001 at 05:04:23PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --8jNwmpfkpox/fiJK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2001 at 05:04:23PM -0500, Felix-Antoine Paradis wrote: > Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? It supports them just fine.. Perhaps your question was really "does FreeBSD emulate a SCSI interface to ATAPI drives?", in which case the answer is "no". They are still fully functional however. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --8jNwmpfkpox/fiJK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6b5URWry0BWjoQKURAjmQAKDi5hoiiLxBlNPCRkCRiKj3MnG6nQCeLyjH vFaowBh4dmUZ0BEv6ivAD7c= =n8Y+ -----END PGP SIGNATURE----- --8jNwmpfkpox/fiJK-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 18:51:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 4E3F937B401 for ; Wed, 24 Jan 2001 18:51:12 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0P2sct45748; Wed, 24 Jan 2001 18:54:38 -0800 (PST) (envelope-from kris) Date: Wed, 24 Jan 2001 18:54:38 -0800 From: Kris Kennaway To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Running FreeBSD off of CDROM Message-ID: <20010124185438.K45221@citusc17.usc.edu> References: <200101250053.QAA29043@hokkshideh.jetcafe.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="sdEQJo40s7ofW8iR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101250053.QAA29043@hokkshideh.jetcafe.org>; from dave@jetcafe.org on Wed, Jan 24, 2001 at 04:53:39PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --sdEQJo40s7ofW8iR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2001 at 04:53:39PM -0800, Dave Hayes wrote: > I was asked recently if it was possible to run a FreeBSD server > entirely off of CDROM. Now I know that things like /var need to be > writable, and that the initial question as worded was rather naive. > However, modulo writable filesystems which can be mounted separately, > has anyone ever done something like this? Yes. In fact I think the BSDi CD sets even come with a bootable live filesystem CD which is exactly this (not sure if it takes care of writability issues). If not the release CD sets, then the Toolkit..I've seen it somewhere. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --sdEQJo40s7ofW8iR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6b5VuWry0BWjoQKURAiFEAJ95sLO/DtkVPSV35HGZCcCx2+4idgCgpCmd I+JAVvfiLpQpCTPZ5Thf4+g= =j7ti -----END PGP SIGNATURE----- --sdEQJo40s7ofW8iR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 18:53: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hokkshideh.jetcafe.org (hokkshideh.jetcafe.org [205.147.43.4]) by hub.freebsd.org (Postfix) with ESMTP id 06DC237B401 for ; Wed, 24 Jan 2001 18:52:45 -0800 (PST) Received: from hokkshideh.jetcafe.org (localhost [127.0.0.1]) by hokkshideh.jetcafe.org (8.8.8/8.8.5) with ESMTP id SAA01089; Wed, 24 Jan 2001 18:52:36 -0800 (PST) Message-Id: <200101250252.SAA01089@hokkshideh.jetcafe.org> X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.4 #1[UCI] To: chris@calldei.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Running FreeBSD off of CDROM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2001 18:52:35 -0800 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chris Costello writes: > When you boot into your CD, and after the CD is mounted as /, > mount the disk as a union with the CD /. The result is that > you'll have the executables on the CD, but any data being written > will go to the disk. Hmm, I had considered that strategy. What I noticed was this line in the man pages for mount_union(8): BUGS THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. Naturally, given this information, production systems with that strategy are fairly out of the question. ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>> The opinions expressed above are entirely my own <<< Possession of a system of knowledge, or any part of it, or an interest in it or in discovering one, shouldn't be assumed to confer any license or capacity to operate it. Individual criticisms of a system, incapacity to operate it, or dissatisfaction with it should not be confused with any shortcoming of the system itself. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 18:54:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.orem.verio.net (gatekeeper.orem.verio.net [192.41.0.8]) by hub.freebsd.org (Postfix) with ESMTP id B3A5F37B404 for ; Wed, 24 Jan 2001 18:54:25 -0800 (PST) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.orem.verio.net (Postfix) with ESMTP id 6E0733BF135 for ; Wed, 24 Jan 2001 19:54:25 -0700 (MST) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.1/8.11.1) with ESMTP id f0P2sOn55941; Wed, 24 Jan 2001 19:54:24 -0700 (MST) (envelope-from fclift@verio.net) Date: Wed, 24 Jan 2001 20:18:10 -0700 (MST) From: Fred Clift X-Sender: fred@vespa.dmz.orem.verio.net To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Running FreeBSD off of CDROM In-Reply-To: <200101250053.QAA29043@hokkshideh.jetcafe.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 On Wed, 24 Jan 2001, Dave Hayes wrote: > I was asked recently if it was possible to run a FreeBSD server > entirely off of CDROM. Now I know that things like /var need to be > writable, and that the initial question as worded was rather naive. > However, modulo writable filesystems which can be mounted separately, > has anyone ever done something like this? Well, it should be doable. I have something similar in spirt -- pxe booted (network booted that is, if you dont know pxe) boxes that get their entire OS from a nfs mount that is read-only. Fairly early in the boot, I have some rc stuff that does mount_mfs for /var and /tmp so I have some scratch space that I can write to for this specialized application. At any rate, its not too hard to make bootable cds these days so you could boot an image that mount_mfses critical sections and copies things in that you need... Or you could even boot of an MD image stored on a slice on a CD... eitehr way. When you figure it out and get it working, make a web page giving the step-by-step guide to how to do it... :) Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 19:33:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 7BC6A37B400 for ; Wed, 24 Jan 2001 19:33:01 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0P3mPI02756; Wed, 24 Jan 2001 19:48:29 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101250348.f0P3mPI02756@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Kevin Day Cc: hackers@freebsd.org, kevin@stileproject.com Subject: Re: Pthreads with sprintf/dtoa In-reply-to: Your message of "Wed, 24 Jan 2001 18:29:58 CST." <200101250029.SAA23574@temphost.dragondata.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-7024949920" Date: Wed, 24 Jan 2001 19:48:25 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multipart MIME message. --==_Exmh_-7024949920 Content-Type: text/plain; charset=us-ascii > > > After upgrading to FreeBSD 4.2(from 4.1) and MySQL 3.23.32 (from 3.22.32), I > kept seeing mysqld crashes after a few minutes of heavy load. I traced it > down to one rather situation. Every time it crashed, I was getting a > segfault inside __dtoa (which was called by sprintf). If I looked at other > threads, I'd always see another thread inside __dtoa at that point too. > > I went back to 3.22.32, and it still happened, so my current guess is > something between 4.1-RELEASE and 4.2-RELEASE. > > I'm really highly ignorant of pthreads, so I have no idea if they(myslqd) is > doing something wrong thread-wise, or something got broken so that it's no > longer thread safe inside sprintf or dtoa. > > Can someone cluefull point me in the right direction? Sure. static Bigint *result; static int result_k; __dtoa has static locals. Bad function, no biscuit. I think that it does this in an attempt to avoid malloc thrash if it's called frequently; only resizing the result buffer if it actually needs a larger one. Making this work "right" will be a bit ugly, since you'll need to fix __dtoa to always return a buffer allocated with malloc, and then teach vfprintf how to deal with a volatile string. The handling of the result buffer in __dtoa is truly evil, and the author should most definitely have been shot. Attached is an (untested) patch. The sizing of the return buffer in __dtoa is a guess, based on trying to work out what the original code was doing, and may be off-by-one. --==_Exmh_-7024949920 Content-Type: application/x-patch ; name="dtoa.patch" Content-Description: dtoa.patch Content-Disposition: attachment; filename="dtoa.patch" Index: stdio/vfprintf.c =================================================================== RCS file: /local0/src/src/lib/libc/stdio/vfprintf.c,v retrieving revision 1.23 diff -u -r1.23 vfprintf.c --- stdio/vfprintf.c 2001/01/06 20:48:00 1.23 +++ stdio/vfprintf.c 2001/01/25 03:25:28 @@ -287,6 +287,7 @@ #define SHORTINT 0x040 /* short integer */ #define ZEROPAD 0x080 /* zero (as opposed to blank) pad */ #define FPT 0x100 /* Floating point number */ +#define MUSTFREE 0x200 /* sp must be freed */ int vfprintf(fp, fmt0, ap) FILE *fp; @@ -610,6 +611,7 @@ flags |= FPT; cp = cvt(_double, prec, flags, &softsign, &expt, ch, &ndig); + flags |= MUSTFREE; if (ch == 'g' || ch == 'G') { if (expt <= -4 || expt > prec) ch = (ch == 'g') ? 'e' : 'E'; @@ -861,6 +863,10 @@ ret += prsize; FLUSH(); /* copy out the I/O vectors */ + + /* free cp if it was allocated elsewhere */ + if (flags & MUSTFREE) + free(cp); } done: FLUSH(); Index: stdlib/strtod.c =================================================================== RCS file: /local0/src/src/lib/libc/stdlib/strtod.c,v retrieving revision 1.3 diff -u -r1.3 strtod.c --- stdlib/strtod.c 1996/07/12 18:55:22 1.3 +++ stdlib/strtod.c 2001/01/25 03:43:08 @@ -1890,16 +1890,7 @@ Bigint *b, *b1, *delta, *mlo, *mhi, *S; double d2, ds, eps; char *s, *s0; - static Bigint *result; - static int result_k; - - if (result) { - result->k = result_k; - result->maxwds = 1 << result_k; - Bfree(result); - result = 0; - } - + if (word0(d) & Sign_bit) { /* set sign for everything, including 0's and NaNs */ *sign = 1; @@ -1917,11 +1908,11 @@ { /* Infinity or NaN */ *decpt = 9999; - s = + s = strdup( #ifdef IEEE_Arith !word1(d) && !(word0(d) & 0xfffff) ? "Infinity" : #endif - "NaN"; + "NaN"); if (rve) *rve = #ifdef IEEE_Arith @@ -1936,7 +1927,7 @@ #endif if (!d) { *decpt = 1; - s = "0"; + s = strdup("0"); if (rve) *rve = s + 1; return s; @@ -2057,11 +2048,10 @@ if (i <= 0) i = 1; } - j = sizeof(unsigned long); - for (result_k = 0; sizeof(Bigint) - sizeof(unsigned long) + j < i; - j <<= 1) result_k++; - result = Balloc(result_k); - s = s0 = (char *)result; + /* XXX verify that i is always large enough? Add padding? */ + s = s0 = malloc(i); + if (s0 == NULL) + return s0; if (ilim >= 0 && ilim <= Quick_max && try_quick) { --==_Exmh_-7024949920 Content-Type: text/plain; charset=us-ascii ... 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 --==_Exmh_-7024949920-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 19:58:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 6E89137B400 for ; Wed, 24 Jan 2001 19:58:31 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0P3w8g49073; Wed, 24 Jan 2001 21:58:08 -0600 (CST) (envelope-from jlemon) Date: Wed, 24 Jan 2001 21:58:08 -0600 (CST) From: Jonathan Lemon Message-Id: <200101250358.f0P3w8g49073@prism.flugsvamp.com> To: dennis@etinc.com, hackers@freebsd.org Subject: Re: if_fxp driver info X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: > >> >> > I'll look into the Linux driver, however, and see if it has anything >> > useful in it. Historically the Linux Pro/100+ driver has totally sucked and >> > was chalk-full of magic numbers being anded and ored. >> >>That's "chock full", and you're confusing the Becker driver (bad) with >>the Intel-supplied driver (slightly less bad). > > >The intel driver seems to cover all the bases and has some nice glue >routines for determining the part and features available. > >I havent tested it under load, but I wonder if intel would consider >supporting it if someone ported it over to freebsd? they have drivers for >just about every other major OS except BSD. it would be nice if the driver >was updated BEFORE cards and MBs that dont work started showing up on the >loading dock. Every time I get a shipment we have to hold our breath until >we try one out. The documentation is available, if you want to (or have to) sign an NDA. People who have the NDA documentation are perfectly capable of writing a driver, although the source can't be released. It would probably be possible to release a binary driver, but why do anything to help Intel, given their unhelpful attitude? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 20:16:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from isua5.iastate.edu (isua5.iastate.edu [129.186.1.205]) by hub.freebsd.org (Postfix) with ESMTP id BB73937B402; Wed, 24 Jan 2001 20:15:54 -0800 (PST) Received: from localhost (ccsanady@localhost) by isua5.iastate.edu (8.8.8/8.8.5) with SMTP id WAA20143; Wed, 24 Jan 2001 22:15:53 -0600 (CST) Message-Id: <200101250415.WAA20143@isua5.iastate.edu> To: Kris Kennaway Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD Linux emulation / arla 0.34.6 In-reply-to: Your message of Wed, 24 Jan 2001 18:51:29 -0800. <20010124185129.I45221@citusc17.usc.edu> Date: Wed, 24 Jan 2001 22:15:53 CST From: Chris Csanady Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Wed, Jan 24, 2001 at 12:50:29PM -0600, Chris wrote: >> Silly me--I forgot to mention, this is with FreeBSD 4.2-STABLE. > >How recent -stable? A bug like this was fixed recently. If it's older >than a week, Try upgrading :-) > >Kris Hmm, are you referring to this commit? It appears to been MFC'd on 11/07, so I hope not. :) I will rebuild and find out though.. Thanks, Chris marcel 2000/11/04 23:31:18 PST Modified files: sys/compat/linux linux_file.c Log: Fix getdents syscall. The offset field in struct dirent was set to the offset of the next dirent in rev 1.36. The offset was calculated from the current offset and the record length. This offset does not necessarily match the real offset when we are using cookies. Therefore, also use the cookies to set the offset field in struct dirent if we're using cookies to iterate through the dirents. Revision Changes Path 1.43 +5 -2 src/sys/compat/linux/linux_file.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 20:26:46 2001 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 9BC7F37B400 for ; Wed, 24 Jan 2001 20:26:29 -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 f0P4QHt79094; Wed, 24 Jan 2001 20:26:17 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: chris@calldei.com Cc: Dave Hayes , freebsd-hackers@FreeBSD.ORG Subject: Re: Running FreeBSD off of CDROM In-Reply-To: Message from Chris Costello of "Wed, 24 Jan 2001 20:06:18 CST." <20010124200618.C776@holly.calldei.com> Date: Wed, 24 Jan 2001 20:26:17 -0800 Message-ID: <79090.980396777@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What you'd need is a writable medium, preferable a hard disk, > with whatever file system you want to use on it, and a CD with a > stripped-down FreeBSD installation, complete with a kernel that > matches your hardware. You don't even need a disk if you have enough memory. You can come up with an MFS and put everything you need to write on in that (via union mount or symlinks or whatever). - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 20:58:37 2001 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 97E2837B400; Wed, 24 Jan 2001 20:58:18 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 8C7F46AB73; Thu, 25 Jan 2001 15:28:15 +1030 (CST) Date: Thu, 25 Jan 2001 15:28:15 +1030 From: Greg Lehey To: Dennis Cc: Mike Smith , dg@root.com, hackers@FreeBSD.ORG Subject: Re: if_fxp driver info Message-ID: <20010125152815.K44155@wantadilla.lemis.com> References: <200101232033.f0NKXHS01892@mass.dis.org> <5.0.0.25.0.20010124170245.03bf6140@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20010124170245.03bf6140@mail.etinc.com>; from dennis@etinc.com on Wed, Jan 24, 2001 at 05:08:16PM -0500 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 Wednesday, 24 January 2001 at 17:08:16 -0500, Dennis wrote: > >> >>> I'll look into the Linux driver, however, and see if it has anything >>> useful in it. Historically the Linux Pro/100+ driver has totally sucked and >>> was chalk-full of magic numbers being anded and ored. >> >> That's "chock full", and you're confusing the Becker driver (bad) with >> the Intel-supplied driver (slightly less bad). > > The intel driver seems to cover all the bases and has some nice glue > routines for determining the part and features available. We recently did some testing of these drivers at my company. We found both drivers to be very bad, and the consensus was that the Intel driver was worse. We were not able to keep a link up under load for more than a few hours. > I havent tested it under load, but I wonder if intel would consider > supporting it if someone ported it over to freebsd? they have drivers for > just about every other major OS except BSD. it would be nice if the driver > was updated BEFORE cards and MBs that dont work started showing up on the > loading dock. Every time I get a shipment we have to hold our breath until > we try one out. I've come in in the middle of this discussion, so maybe there's something I don't know, but on the same hardware and running FreeBSD, I had no problems. Why should we want to replace the driver with something which doesn't work well? 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 Wed Jan 24 21: 8:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9716437B402; Wed, 24 Jan 2001 21:08:04 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id VAA19760; Wed, 24 Jan 2001 21:07:44 -0800 Date: Wed, 24 Jan 2001 21:07:45 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Greg Lehey Cc: Dennis , Mike Smith , dg@root.com, hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-Reply-To: <20010125152815.K44155@wantadilla.lemis.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've come in in the middle of this discussion, so maybe there's > something I don't know, but on the same hardware and running FreeBSD, > I had no problems. Why should we want to replace the driver with > something which doesn't work well? There's been a hint of 'vendor supported'.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 21: 9:29 2001 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 7CBF537B401; Wed, 24 Jan 2001 21:09:12 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 55EB96AB74; Thu, 25 Jan 2001 15:39:10 +1030 (CST) Date: Thu, 25 Jan 2001 15:39:10 +1030 From: Greg Lehey To: Matthew Jacob Cc: Dennis , Mike Smith , dg@root.com, hackers@FreeBSD.ORG Subject: Re: if_fxp driver info Message-ID: <20010125153910.M44155@wantadilla.lemis.com> References: <20010125152815.K44155@wantadilla.lemis.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 mjacob@feral.com on Wed, Jan 24, 2001 at 09:07:45PM -0800 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 Wednesday, 24 January 2001 at 21:07:45 -0800, Matt Jacob wrote: >> >> I've come in in the middle of this discussion, so maybe there's >> something I don't know, but on the same hardware and running FreeBSD, >> I had no problems. Why should we want to replace the driver with >> something which doesn't work well? > > There's been a hint of 'vendor supported'.... We saw no evidence of that. 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 Wed Jan 24 21: 9:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0803A37B69B for ; Wed, 24 Jan 2001 21:09:24 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0P59D964664; Wed, 24 Jan 2001 22:09:13 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101250509.f0P59D964664@harmony.village.org> To: chris@calldei.com Subject: Re: Running FreeBSD off of CDROM Cc: Dave Hayes , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 24 Jan 2001 20:06:18 CST." <20010124200618.C776@holly.calldei.com> References: <20010124200618.C776@holly.calldei.com> <200101250053.QAA29043@hokkshideh.jetcafe.org> Date: Wed, 24 Jan 2001 22:09:13 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010124200618.C776@holly.calldei.com> Chris Costello writes: : What you'd need is a writable medium, preferable a hard disk, : with whatever file system you want to use on it, and a CD with a : stripped-down FreeBSD installation, complete with a kernel that : matches your hardware. You don't need a writable medium to run FreeBSD. Well, I take that back, you do need a writable partition, but that can be mfs. We run off CF which is mounted read only with the usual rc.diskless tricks for creating /var and /dev. Similar techniques could be used for booting off of cdrom. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 21:11: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 437F437B402; Wed, 24 Jan 2001 21:10:45 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id VAA19786; Wed, 24 Jan 2001 21:10:37 -0800 Date: Wed, 24 Jan 2001 21:10:38 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Greg Lehey Cc: Dennis , Mike Smith , dg@root.com, hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-Reply-To: <20010125153910.M44155@wantadilla.lemis.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 Wednesday, 24 January 2001 at 21:07:45 -0800, Matt Jacob wrote: > >> > >> I've come in in the middle of this discussion, so maybe there's > >> something I don't know, but on the same hardware and running FreeBSD, > >> I had no problems. Why should we want to replace the driver with > >> something which doesn't work well? > > > > There's been a hint of 'vendor supported'.... > > We saw no evidence of that. No- I think in this discussion there was a hint or hope of that. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 21:11:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id BB26237B69D for ; Wed, 24 Jan 2001 21:11:29 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0P5BP964711; Wed, 24 Jan 2001 22:11:26 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101250511.f0P5BP964711@harmony.village.org> To: Fred Clift Subject: Re: Running FreeBSD off of CDROM Cc: Dave Hayes , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 24 Jan 2001 20:18:10 MST." References: Date: Wed, 24 Jan 2001 22:11:25 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Fred Clift writes: : When you figure it out and get it working, make a web page giving the : step-by-step guide to how to do it... :) We get pretty far by having root_rw_mount=NO diskless_mount=/etc/rc.diskless2 varsize=8192 update_motd=NO in rc.conf and a slightly hackd rc.diskless2 to create some log files that we need. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 21:14:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D19B237B69D for ; Wed, 24 Jan 2001 21:13:56 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0P5Dn964730; Wed, 24 Jan 2001 22:13:49 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101250513.f0P5Dn964730@harmony.village.org> To: Jordan Hubbard Subject: Re: Running FreeBSD off of CDROM Cc: chris@calldei.com, Dave Hayes , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 24 Jan 2001 20:26:17 PST." <79090.980396777@winston.osd.bsdi.com> References: <79090.980396777@winston.osd.bsdi.com> Date: Wed, 24 Jan 2001 22:13:49 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <79090.980396777@winston.osd.bsdi.com> Jordan Hubbard writes: : You don't even need a disk if you have enough memory. You can come up : with an MFS and put everything you need to write on in that (via union : mount or symlinks or whatever). At timing solutions we found union mount to be a non-starter. Too unstable for long term operations. symlinks are what we use. I actually lied a little in a previous message. We do have a RW partition, but we only store application sepcific data on it. Of course our application doesn't have users who need to change their passwords.... And even if they did, a simple mount -uw / ; passwd ; mount -ur / would do the trick. Can't do that with cdrom :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 21:29:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by hub.freebsd.org (Postfix) with ESMTP id C976C37B400 for ; Wed, 24 Jan 2001 21:29:18 -0800 (PST) Received: from holly.calldei.com ([208.191.149.190]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G7P00K3BDLMQZ@mta5.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Wed, 24 Jan 2001 23:22:35 -0600 (CST) Received: (from chris@localhost) by holly.calldei.com (8.11.1/8.9.3) id f0P5Ohu09016; Wed, 24 Jan 2001 23:24:43 -0600 (CST envelope-from chris) Date: Wed, 24 Jan 2001 23:23:41 -0600 From: Chris Costello Subject: Re: Running FreeBSD off of CDROM In-reply-to: <200101250509.f0P59D964664@harmony.village.org>; from imp@harmony.village.org on Wed, Jan 24, 2001 at 10:09:13PM -0700 To: Warner Losh Cc: Dave Hayes , freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20010124232341.D776@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20010124200618.C776@holly.calldei.com> <200101250053.QAA29043@hokkshideh.jetcafe.org> <20010124200618.C776@holly.calldei.com> <200101250509.f0P59D964664@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, January 24, 2001, Warner Losh wrote: > You don't need a writable medium to run FreeBSD. Well, I take that > back, you do need a writable partition, but that can be mfs. We run > off CF which is mounted read only with the usual rc.diskless tricks > for creating /var and /dev. Similar techniques could be used for > booting off of cdrom. I'm assuming that there's some data he wants to permenantly store on a disk. But yes, just like the live FS CDROM, MFS can easily be used. -- +-------------------+------------------------------------------+ | Chris Costello | If the code and the comments disagree, | | chris@calldei.com | then both are probably wrong. - Schryer | +-------------------+------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 22:45:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 01E5F37B400 for ; Wed, 24 Jan 2001 22:44:53 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f0P6ig927135; Wed, 24 Jan 2001 22:44:46 -0800 (PST) Date: Wed, 24 Jan 2001 22:44:42 -0800 (PST) From: Doug White To: Kevin Mills Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads and kqueue In-Reply-To: <85ofwwkfkm.fsf@diablo.in.a6l.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 24 Jan 2001, Kevin Mills wrote: > My question: Is it considered "safe" to have a number of threads each > waiting on a call to kevent() using the same kqueue? Or do I need to > have one thread waiting on the kevent() call and have it dispatch jobs > to the waiting threads? You should probably assume that kqueue/kevent() & friends are not thread-safe. I would suggest using a separate dispatcher thread that sits on the kqueue and wakes up threads as needed. This would be much more efficient than per-thread kqueues. This seems like a strange way to implement your solution, though ... from the sounds of it, you can only have one concurrent connection to your authentication server via this library, which sounds extremely lame. Do the clients just sit around forever until the server returns? The serialization this library forces isn't too scalable. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 24 23:47:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 6A31137B400 for ; Wed, 24 Jan 2001 23:46:56 -0800 (PST) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id NAA07034 for ; Thu, 25 Jan 2001 13:16:49 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Thu, 25 Jan 2001 13:16:49 +0000 (IST) Received: from localhost (sumahr@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id NAA27863; Thu, 25 Jan 2001 13:16:48 +0530 (IST) Date: Thu, 25 Jan 2001 13:16:48 +0530 (IST) From: Suma H R To: Cc: Brahma Naidu Golla Subject: Pseudo ethernet interface 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, Is it possible to provide pseudo ethernet interfaces? Can we associate an IP and MAC address with a psuedo ethernet interface to facilitate data packet transmission & reception through that? If so, how does it work? Pointers to any documentation in this regard will be appreciated. Thanks, Suma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 3: 5:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from csunb0.leeds.ac.uk (csunb0.leeds.ac.uk [129.11.144.2]) by hub.freebsd.org (Postfix) with SMTP id 800C537B6B4; Thu, 25 Jan 2001 03:05:36 -0800 (PST) Received: from cslin.leeds.ac.uk (csunc0.leeds.ac.uk [129.11.144.3]) by csunb0.leeds.ac.uk (8.6.12/8.6.12) with ESMTP id KAA15292; Thu, 25 Jan 2001 10:54:03 GMT Received: from cslin006.leeds.ac.uk (cslin006 [129.11.146.6]) by cslin.leeds.ac.uk (8.9.3+Sun/) with ESMTP id KAA26833; Thu, 25 Jan 2001 10:54:04 GMT Date: Thu, 25 Jan 2001 10:54:03 +0000 From: Ben Smithurst To: n_hibma@FreeBSD.org, hackers@FreeBSD.org Subject: ugen(4) manual page Message-ID: <20010125105402.E8727@comp.leeds.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How accurately does the NetBSD ugen(4) manual page describe FreeBSD's ugen(4)? If it's accurate as it is, or can easily be fixed (any volunteers?), I think we should just take it. :-) Perhaps my removing of the .Xr ugen 4 from usb(4) was a bit premature... never mind. http://www.FreeBSD.org/cgi/man.cgi?query=ugen&apropos=0&sektion=0&manpath=NetBSD+1.5&format=html -- Ben Smithurst / csxbcs@comp.leeds.ac.uk / ben@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 Jan 25 3:16:29 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcs113.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id BFFF337B401 for ; Thu, 25 Jan 2001 03:16:03 -0800 (PST) Received: from localhost (pmk@localhost) by pcs113.sasi.com (8.9.3/8.9.3) with ESMTP id QAA06293 for ; Thu, 25 Jan 2001 16:45:59 +0530 X-Authentication-Warning: pcs113.sasi.com: pmk owned process doing -bs Date: Thu, 25 Jan 2001 16:45:59 +0530 (IST) From: Mohana Krishna Penumetcha To: freebsd-hackers@FreeBSD.ORG Subject: Re: interrupt handling routine not called!!! 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 we have done some further testing and verified the intr_handler table and corresponding mask values. everything seems to be correct. this leaves us with the hardware. the problem could be either the device is not activating the interrupt line(i.e. not conssitent with status register values) or the interrupt is getting lost while being propogated to the interrupt controller. in our setup, device is connected to pci bus, which is connected to host-pci bridge, but is it possible for the interrupts to get lost? if i want to check the interrupt register of the controller, to see what interrupts are active, which part of the o.s. code i needs to modify. considering this is very critical code, i would like to go through some documentation, is there any thing available? thanks, mohan On Wed, 24 Jan 2001, Mohana Krishna Penumetcha wrote: > hi, > > we are writing a driver(FreeBSD 4.0) for a switch connected to a PCI port. > the interrupt handling routine is not getting called. we checked the > switch IRQ status register and find some interrupts to be pending. we > have no clue about what is happening, can someone give a few ideas about > what could be wrong? > > some info you may ask for: > > vmstat -i doesn't show any thing about the device > > there doen't seem to be any conflicts while assigning the IRQ numbers. and > the IRQ info in dmesg matches with the interrupt line configuration > register of the device. > > code to register to interrupt routine: > > rid = 0; > sc->edge_irq = bus_alloc_resource(dev,SYS_RES_IRQ, > &rid, 0, > ~0, 1, > RF_SHAREABLE|RF_ACTIVE); > if(!sc->edge_irq){ > /*release all resources*/ > return -1; > } > error = bus_setup_intr(dev, sc->edge_irq, > INTR_TYPE_NET, > edge_intr, /*interrupt handler*/ > sc, > &sc->edge_intrhand); > if(error){ > /*release all resources*/ > return -1; > } > > > thanks, > mohan > > --------------------------------------------------------------------------- > Creativity is allowing yourself to make mistakes and Art is > knowing which ones to keep. > -Dilbert > > Mohana Krishna P. > ph:- 527 6100/6108 x6352 > Telecom ODC, Sasken Communication Technologies, INDIA. > http://www.sasken.com > --------------------------------------------------------------------------- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 4:24:15 2001 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 5CF2D37B400 for ; Thu, 25 Jan 2001 04:23:58 -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 <01JZBQMH93O4000757@research.kpn.com> for hackers@FreeBSD.ORG; Thu, 25 Jan 2001 13:23:56 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jan 2001 13:23:55 +0100 Content-return: allowed Date: Thu, 25 Jan 2001 13:23:48 +0100 From: "Koster, K.J." Subject: RE: Pseudo ethernet interface To: 'Suma H R' Cc: Brahma Naidu Golla , hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7B57@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 Suma, > > Is it possible to provide pseudo ethernet interfaces? > Can we associate an IP and MAC address with a psuedo ethernet > interface > to facilitate data packet transmission & reception through that? > If so, how does it work? > Pointers to any documentation in this regard will be appreciated. > Have you looked at the tun device? 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 Thu Jan 25 4:38:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 11E1037B400; Thu, 25 Jan 2001 04:38:03 -0800 (PST) Received: from wiliam.alcove-int ([10.16.110.19] ident=mail) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 14LkIT-0003C9-00; Thu, 25 Jan 2001 12:10:33 +0100 Received: from nsouch by wiliam.alcove-int with local (Exim 3.12 #1 (Debian)) id 14LkIS-0004cZ-00; Thu, 25 Jan 2001 12:10:32 +0100 Date: Thu, 25 Jan 2001 12:10:32 +0100 From: Nicolas Souchu To: Maxim Sobolev Cc: hackers@FreeBSD.org Subject: Re: [RFC] New features for libvgl Message-ID: <20010125121032.B17571@wiliam.alcove-int> References: <3A6C7FBF.251B4C89@FreeBSD.org> <20010124185013.G12375@ontario.alcove-int> <3A6F1B68.9AA53C0B@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <3A6F1B68.9AA53C0B@FreeBSD.org>; from sobomax@FreeBSD.org on Wed, Jan 24, 2001 at 08:14:01PM +0200 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 08:14:01PM +0200, Maxim Sobolev wrote: > > > > Isn't your list of modes redundant with the internal data structures of the > > VGA/VESA driver? Why do you list modes if it's not to query a specific one? > > I believe that there should be possibility to do both these things, i.e. (1) query > list of available modes using some filter, so the aplication/toolkit will be able to > select one that matches its needs, and (2) let the video driver select the best one > given certain constrains. For example SDL provides a possibility to at least emulate > mode if is not directly available from video hardware, so it need to know what the > alternatives are. All this is done by GGI. I agree that you may need it for SDL. > > I'm not very adamant about using internal data structures of video driver, because > they are too generic and include too much irrelevant details. Probably we should > extent VGLBitmap to include missing bits (depth, masks, etc). Maybe you should rather put it in your VGL<->SDL interface driver and just consider VGL as a drawing library. > > > [skip] > > > > ++++++++++++++++++++++++ > > Well, it's nice, but I'm not sure how it would work in the case of more high level > toolkit (like SDL). As I said earlier, application can request an arbitrary mode, > i.e. 349x246x19, so we have to do some adjustments before passing these parameters > to the video driver- to do this we should know what the alternatives are. See above. > > > About the mouse stuff, what is the exact usage of MousePointerShow? It's > > not documented in the manpage. > > It's internal VGL function used to draw a mouse pointer at the screen. So, the mousehandler is called each time the mouse is moving? The SDL library is synchronous with input peripheral? How will you handle acceleration with SDL? Nicholas -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 7:13:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id DAD9637B402 for ; Thu, 25 Jan 2001 07:13:30 -0800 (PST) Received: from wiliam.alcove-int ([10.16.110.19] ident=mail) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 14Lo4q-00056f-00; Thu, 25 Jan 2001 16:12:44 +0100 Received: from nsouch by wiliam.alcove-int with local (Exim 3.12 #1 (Debian)) id 14Lo4p-0004tp-00; Thu, 25 Jan 2001 16:12:43 +0100 Date: Thu, 25 Jan 2001 16:12:43 +0100 From: Nicolas Souchu To: Andrew Gallatin Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, freebsd-hackers@freebsd.org Subject: Re: AMD System Management driver and Newbus Message-ID: <20010125161242.E18032@wiliam.alcove-int> References: <20001228091913.C26574@wiliam.alcove-int> <14923.39062.862177.106870@grasshopper.cs.duke.edu> <20001229094022.C29262@wiliam.alcove-int> <14924.44189.741374.795171@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <14924.44189.741374.795171@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Dec 29, 2000 at 02:26:39PM -0500 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Dec 29, 2000 at 02:26:39PM -0500, Andrew Gallatin wrote: > > I know what chips they are (From the UP1000 Tech. Ref. Manual): > > The UP1000 has one main SM bus and two sub-SM busses. Acces to the > sub-SM bus is controlled by a multiplexer (MUX) which sits on the main > SM bus. > > The SM bus from the Alpha Slot B Module [processor module, akin to a > Slot A Athlon] connects the first sub-SM bus; the DIMM EEPROMs are > connected to the second sub-SM bus. > > SM bus addresses for all UP1000 devices are provided in Table 4-3. > > Table 4-3: SM Bus Address of Each Device: > > Device Address > ---------------------------------- ------------------- > ADM 9240 (system mgmnt unit) 0101 100X > > ICS9179-06 (Zero delay clock buffer) 1011 001X > > PCF8574AT (LED Controller) 1010 001X > > PCF8574AT (I2C bus MUX Controller) 1010 010X Usually, PCF8574A addresses most significant bits are 0111 and others are programmable. Considering that the documentation may be wrong the 0x74 and 0x78 chips are certainly PCF8574AT. > > PCF8582 (MB revision EEPROM) 1010 001X > > Revision EEPROM on Alpha Slot B 1010 000X > Module > LM79 (Thermal Detector on Alpha 0101 111X > Slot B Module) > Dimm0 1010 000X > > Dimm1 1010 001X > > Dimm2 1010 010X > > > This knowledge doesn't seem to help me much.. Is the I2C bus MUX > controller common? Could that be why the "detect" program shows > device addresses which are different than those given in the table? Maybe. One way to know this would be to access the chips by forcing the address and look in their register if we cannot find a kind of LM79 signature. > > What software would you suggest for dealing with the mux and accessing > the lm79? Controlling the mux seems permitted by one of the PCF8574A. But this chip is only a serial/parallel converter that will allow you to trig the mux lines. So we have no more info about the mux and how it is connected to the PCF outputs... > > BTW, do I need the iic stuff? All I've got for smb in my config file > is: Only if you want to send I2C commands. The alpm driver only support SMB commands, so it's useless in your case. > > device smbus # Bus support, required for smb below. > device alpm 1 > device smb > > > Thanks again, Sorry for the delay. Nicholas -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 7:57:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 20E8B37B400 for ; Thu, 25 Jan 2001 07:57:36 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 14LomM-0000vV-00 for freebsd-hackers@freebsd.org; Thu, 25 Jan 2001 17:57:42 +0200 Date: Thu, 25 Jan 2001 17:57:42 +0200 (IST) From: Roman Shterenzon To: Subject: ugen 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, Where (besides ugen.c) can I find some information about generic USB devices aka ugen? There's usb(3), but it only talks about hid devices. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 9: 4:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from whalers.digisle.net (whalers.digisle.net [167.216.128.32]) by hub.freebsd.org (Postfix) with ESMTP id 4E7C037B401 for ; Thu, 25 Jan 2001 09:04:33 -0800 (PST) Received: from chef.digisle.com (chef.digisle.com [167.216.152.38]) by whalers.digisle.net (8.9.3/8.9.3/mx) with ESMTP id RAA27735; Thu, 25 Jan 2001 17:06:34 GMT Received: from guinness.digisle.com (guinness.digisle.com [167.216.152.33]) by chef.digisle.com (8.9.3/8.9.3/digisle) with ESMTP id RAA06326; Thu, 25 Jan 2001 17:04:15 GMT Received: from digisle.com (peahi.digisle.com [206.220.227.147]) by guinness.digisle.com (8.9.3/8.9.3) with ESMTP id RAA26866; Thu, 25 Jan 2001 17:04:14 GMT Message-ID: <3A705B4D.C0D2E678@digisle.com> Date: Thu, 25 Jan 2001 08:58:53 -0800 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Koster, K.J." Cc: "'Suma H R'" , Brahma Naidu Golla , hackers@FreeBSD.ORG Subject: Re: Pseudo ethernet interface References: <59063B5B4D98D311BC0D0001FA7E4522026D7B57@l04.research.kpn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Is it possible to provide pseudo ethernet interfaces? > > Can we associate an IP and MAC address with a psuedo ethernet > > interface > > to facilitate data packet transmission & reception through that? yes. > > If so, how does it work? > > Pointers to any documentation in this regard will be appreciated. > > $ man tap $ man ng_ether > Have you looked at the tun device? this is IP only. thanks, emax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 9:31:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 2E2BA37B69C for ; Thu, 25 Jan 2001 09:31:21 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0PHV2T26175; Thu, 25 Jan 2001 19:31:16 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0PHV6607430; Thu, 25 Jan 2001 19:31:06 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A7062C5.482DA161@FreeBSD.org> Date: Thu, 25 Jan 2001 19:30:46 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Nicolas Souchu Cc: hackers@FreeBSD.org Subject: Re: [RFC] New features for libvgl References: <3A6C7FBF.251B4C89@FreeBSD.org> <20010124185013.G12375@ontario.alcove-int> <3A6F1B68.9AA53C0B@FreeBSD.org> <20010125121032.B17571@wiliam.alcove-int> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nicolas Souchu wrote: > On Wed, Jan 24, 2001 at 08:14:01PM +0200, Maxim Sobolev wrote: > > > > > > Isn't your list of modes redundant with the internal data structures of the > > > VGA/VESA driver? Why do you list modes if it's not to query a specific one? > > > > I believe that there should be possibility to do both these things, i.e. (1) query > > list of available modes using some filter, so the aplication/toolkit will be able to > > select one that matches its needs, and (2) let the video driver select the best one > > given certain constrains. For example SDL provides a possibility to at least emulate > > mode if is not directly available from video hardware, so it need to know what the > > alternatives are. > > All this is done by GGI. I agree that you may need it for SDL. So why not to put it into libvgl and allow any toolkit use this code? > > > > I'm not very adamant about using internal data structures of video driver, because > > they are too generic and include too much irrelevant details. Probably we should > > extent VGLBitmap to include missing bits (depth, masks, etc). > > Maybe you should rather put it in your VGL<->SDL interface driver and just consider VGL as > a drawing library. > > > > > > [skip] > > > > > > ++++++++++++++++++++++++ > > > > Well, it's nice, but I'm not sure how it would work in the case of more high level > > toolkit (like SDL). As I said earlier, application can request an arbitrary mode, > > i.e. 349x246x19, so we have to do some adjustments before passing these parameters > > to the video driver- to do this we should know what the alternatives are. > > See above. I see. ;) > > > > > About the mouse stuff, what is the exact usage of MousePointerShow? It's > > > not documented in the manpage. > > > > It's internal VGL function used to draw a mouse pointer at the screen. > > So, the mousehandler is called each time the mouse is moving? Yes, each time mouse is moving syscons driver sends a signal specified by the CONS_MOUSECTL ioctl. What I'm proposing here is to add a knob to allow vgl-using apps to assign their own handlers for this. > The SDL library is > synchronous with input peripheral? It depends on specific driver implementation. You can make it to either query mouse position periodically or be synchronous with input peripheral. Matter of taste ;). > How will you handle acceleration with SDL? There are not much you can do about acceleration with vgl, hovewer SDL in general contains a provision for hardware accelerated blits. Ok, do you have any patches for vgl yet? I would like to take a look at it if possible. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 9:36:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from sttlpop3.sttl.uswest.net (sttlpop3.sttl.uswest.net [206.81.192.3]) by hub.freebsd.org (Postfix) with SMTP id 43CAE37B699 for ; Thu, 25 Jan 2001 09:35:57 -0800 (PST) Received: (qmail 23574 invoked by alias); 25 Jan 2001 17:35:49 -0000 Delivered-To: fixup-freebsd-hackers@FreeBSD.ORG@fixme Received: (qmail 23514 invoked by uid 0); 25 Jan 2001 17:35:49 -0000 Received: from www.a6l.net (HELO a6l.net) (63.229.13.49) by sttlpop3.sttl.uswest.net with SMTP; 25 Jan 2001 17:35:49 -0000 Received: (qmail 72790 invoked by uid 1002); 25 Jan 2001 17:36:06 -0000 To: "Doug White" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads and kqueue References: From: Kevin Mills Date: 25 Jan 2001 09:36:05 -0800 In-Reply-To: "Doug White"'s message of "Wed, 24 Jan 2001 22:44:42 -0800 (PST)" Message-ID: <857l3jv8je.fsf@diablo.in.a6l.net> Lines: 28 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Doug White" writes: > On 24 Jan 2001, Kevin Mills wrote: > > You should probably assume that kqueue/kevent() & friends are not > thread-safe. I would suggest using a separate dispatcher thread that sits > on the kqueue and wakes up threads as needed. This would be much more > efficient than per-thread kqueues. Well, there are wrappers in the libc_r code (libc_r/uthread/uthread_kevent.c) and I seem to recall posts on -stable saying that kqueue could now be used with user threads (around the 4.1.1 time frame, I think). > This seems like a strange way to implement your solution, though ... from > the sounds of it, you can only have one concurrent connection to your > authentication server via this library, which sounds extremely lame. Do > the clients just sit around forever until the server returns? The > serialization this library forces isn't too scalable. The library is reentrant and will allow different threads to call into it (there isn't a mutex serializing the entry point or anything like that). However, the call to the backend is done with a blocking call. The communication with the backend is generally very quick. However, if the backend gets too busy I want to make sure I don't starve the other connections. A thread pool seemed the best way to tackle this. I'd be very open to other suggestions if you have any! Thanks for your reply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 9:39:55 2001 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 97A2337B400 for ; Thu, 25 Jan 2001 09:39:37 -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 MAA73170; Thu, 25 Jan 2001 12:41:57 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010125124655.01e705d0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 25 Jan 2001 12:49:08 -0500 To: dg@root.com, Sergey Babkin From: Dennis Subject: Re: if_fxp driver info Cc: hackers@FreeBSD.ORG In-Reply-To: <200101250152.RAA24775@implode.root.com> References: 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 08:52 PM 01/24/2001, David Greenman wrote: > >David Greenman wrote: > >> > >> >supporting it if someone ported it over to freebsd? they have drivers for > >> >just about every other major OS except BSD. it would be nice if the > driver > >> >was updated BEFORE cards and MBs that dont work started showing up on the > >> >loading dock. Every time I get a shipment we have to hold our breath > until > >> >we try one out. > >> > >> "drivers for every major OS"? They have drivers for Windows, Window/NT, > >> and Linux. Of those Linux is the closest to FreeBSD, but that's like > saying > > > >Count in SCO as well - that's at least 3 somewhat different drivers, > >for OpenServer, UnixWare2 (DLPI), UnixWare7 (MDI), plus > >perversive customized OEM versions for Compaq and ICL. Plus > >probably they have drivers for Netware and Solaris too. > > I don't know what list you are looking at, but the download list that > I was >looking at did not include SCO, Unixware or any other Unix variant except >Linux. This is the list. NDIS2, NDIS3, NDIS4 and NDIS5 drivers Novell Netware* Client 3.11, 3.12 Novell Netware Server 4.1x, 5 SunSoft Solaris* SCO Unix 3, 5 SCO UnixWare* 2, 7, OpenDesktop*, OpenServer* These are "licensed" drivers. The linux driver is free. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 9:52:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 3CDD537B6A0 for ; Thu, 25 Jan 2001 09:52:19 -0800 (PST) Received: by smtp.nettoll.com; Thu, 25 Jan 2001 18:49:57 +0100 (MET) Message-ID: <3A706788.5040509@enition.com> Date: Thu, 25 Jan 2001 18:51:04 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: freebsd-hackers@FreeBSD.ORG, Alfred Perlstein Subject: Re: Kernel memory allocation bug ... References: <200101191524.f0JFOtk14877@mobile.wemm.org> <3A6861DF.8060108@enition.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Xavier Galleri wrote: > Peter Wemm wrote: > >> Xavier Galleri wrote: >> >>> Hi everybody, >>> >>> This mail is related to the 'Need help for crash dump analysis' >>> mail serie and the more recent 'Information on kernel crash dump >>> analysis' mail. >> >> What kernel version again? Any unusual options? (eg: SMP etc) >> >> 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 > > uname -a says FreeBSD 4.1-RELEASE. Concerning options, here are the > first line of the kernel Makefile: > > KERN_IDENT=GENERIC > IDENT= > DEBUG=-g > > Regards > > X. Galleri Well, I am a bit disappointed to get no answer at all to my issue. Is it because this is not the correct fashion to ask for support on what has been identified as a potential kernel bug ? Please, let me know what I am supposed to do to get progress, since this is of prime importance to our product ... Regards X. Galleri To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 9:57:55 2001 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 5FA5137B6A0 for ; Thu, 25 Jan 2001 09:57:38 -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 JAA27288; Thu, 25 Jan 2001 09:48:30 -0800 (PST) Message-Id: <200101251748.JAA27288@implode.root.com> To: Dennis Cc: Sergey Babkin , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-reply-to: Your message of "Thu, 25 Jan 2001 12:49:08 EST." <5.0.0.25.0.20010125124655.01e705d0@mail.etinc.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Jan 2001 09:48:29 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I don't know what list you are looking at, but the download list that >> I was >>looking at did not include SCO, Unixware or any other Unix variant except >>Linux. > >This is the list. > >NDIS2, NDIS3, NDIS4 and NDIS5 drivers > Novell Netware* Client 3.11, 3.12 > Novell Netware Server 4.1x, 5 > SunSoft Solaris* > SCO Unix 3, 5 > SCO UnixWare* 2, 7, OpenDesktop*, OpenServer* > >These are "licensed" drivers. The linux driver is free. How do you know that the above drivers are developed by Intel? The above could easily be OS vendor supplied. It's anybody's guess without the source. -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 Thu Jan 25 10: 3:23 2001 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 ECC9F37B6A6 for ; Thu, 25 Jan 2001 10:03:04 -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 NAA73379; Thu, 25 Jan 2001 13:05:31 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010125130845.030de0f0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 25 Jan 2001 13:12:42 -0500 To: Jonathan Lemon , hackers@FreeBSD.ORG From: Dennis Subject: Re: if_fxp driver info In-Reply-To: <200101250358.f0P3w8g49073@prism.flugsvamp.com> References: 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:58 PM 01/24/2001, Jonathan Lemon wrote: >In article > >you write: > > > >> > >> > I'll look into the Linux driver, however, and see if it has anything > >> > useful in it. Historically the Linux Pro/100+ driver has totally > sucked and > >> > was chalk-full of magic numbers being anded and ored. > >> > >>That's "chock full", and you're confusing the Becker driver (bad) with > >>the Intel-supplied driver (slightly less bad). > > > > > >The intel driver seems to cover all the bases and has some nice glue > >routines for determining the part and features available. > > > >I havent tested it under load, but I wonder if intel would consider > >supporting it if someone ported it over to freebsd? they have drivers for > >just about every other major OS except BSD. it would be nice if the driver > >was updated BEFORE cards and MBs that dont work started showing up on the > >loading dock. Every time I get a shipment we have to hold our breath until > >we try one out. > >The documentation is available, if you want to (or have to) sign an >NDA. People who have the NDA documentation are perfectly capable of >writing a driver, although the source can't be released. It would >probably be possible to release a binary driver, but why do anything >to help Intel, given their unhelpful attitude? If they have a published, freely distributable driver for linux. why would you have to sign an NDA to port it to FreeBSD? I dont think so. Not anymore anyway. Thats the whole point of this thread... Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:17:34 2001 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 6226137B6E7 for ; Thu, 25 Jan 2001 10:17:06 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PIH0R23835; Thu, 25 Jan 2001 10:17:00 -0800 (PST) Date: Thu, 25 Jan 2001 10:17:00 -0800 From: Alfred Perlstein To: Xavier Galleri Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel memory allocation bug ... Message-ID: <20010125101659.N26076@fw.wintelcom.net> References: <200101191524.f0JFOtk14877@mobile.wemm.org> <3A6861DF.8060108@enition.com> <3A706788.5040509@enition.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A706788.5040509@enition.com>; from xgalleri@enition.com on Thu, Jan 25, 2001 at 06:51:04PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Xavier Galleri [010125 09:53] wrote: > > Well, I am a bit disappointed to get no answer at all to my issue. Is it > because this is not the correct fashion to ask for support on what has > been identified as a potential kernel bug ? Please, let me know what I > am supposed to do to get progress, since this is of prime importance to > our product ... I told you about 3 times to provide us with a stipped down source code module which reproduces this "bug". You haven't done this. Therefore I can't help you. Sorry, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:24:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8B78E37B6A7 for ; Thu, 25 Jan 2001 10:24:13 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA22224; Thu, 25 Jan 2001 10:24:01 -0800 Date: Thu, 25 Jan 2001 10:24:00 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dennis Cc: Jonathan Lemon , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-Reply-To: <5.0.0.25.0.20010125130845.030de0f0@mail.etinc.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 > If they have a published, freely distributable driver for linux. why would > you have to sign an NDA to port it to FreeBSD? You don't. But reverse engineering isn't always complete. I should know- having gone through hell for the Gigabit NIC for *BSD... mostly reverse engineered from the Linux driver. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:36:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 70AE837B404 for ; Thu, 25 Jan 2001 10:36:19 -0800 (PST) Received: by smtp.nettoll.com; Thu, 25 Jan 2001 19:34:54 +0100 (MET) Message-ID: <3A707211.2080801@enition.com> Date: Thu, 25 Jan 2001 19:36:01 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel memory allocation bug ... References: <200101191524.f0JFOtk14877@mobile.wemm.org> <3A6861DF.8060108@enition.com> <3A706788.5040509@enition.com> <20010125101659.N26076@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Xavier Galleri [010125 09:53] wrote: > >> Well, I am a bit disappointed to get no answer at all to my issue. Is it >> because this is not the correct fashion to ask for support on what has >> been identified as a potential kernel bug ? Please, let me know what I >> am supposed to do to get progress, since this is of prime importance to >> our product ... > > > I told you about 3 times to provide us with a stipped down source > code module which reproduces this "bug". > > You haven't done this. > > Therefore I can't help you. > > Sorry, > -Alfred I did not expect to make trouble to anyone, just sorry for the inconvenience ... I am not sure that we could easily provide for some code sample on this issue since this could be expensive, but I will see for sure (I easily understand that this is easier for anybody to track down a problem in such conditions ;-). That said, I still remain astonished not to get any comments or questions or hints or any other reactions about the analysis I have already provided. I have seen other mails in this list that exposed different kind of issues without requiring code sample to feed a constructive discussion. Did I miss something ? Regards X. Galleri To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:39:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id 39A7237B6A7; Thu, 25 Jan 2001 10:39:11 -0800 (PST) Received: from wiliam.alcove-int ([10.16.110.19] ident=mail) by smtp.alcove.fr with esmtp (Exim 3.12 #1 (Debian)) id 14LrIc-00077Q-00; Thu, 25 Jan 2001 19:39:10 +0100 Received: from nsouch by wiliam.alcove-int with local (Exim 3.12 #1 (Debian)) id 14LrIb-0005yW-00; Thu, 25 Jan 2001 19:39:09 +0100 Date: Thu, 25 Jan 2001 19:39:09 +0100 From: Nicolas Souchu To: Maxim Sobolev Cc: hackers@FreeBSD.org Subject: Re: [RFC] New features for libvgl Message-ID: <20010125193909.G18032@wiliam.alcove-int> References: <3A6C7FBF.251B4C89@FreeBSD.org> <20010124185013.G12375@ontario.alcove-int> <3A6F1B68.9AA53C0B@FreeBSD.org> <20010125121032.B17571@wiliam.alcove-int> <3A7062C5.482DA161@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <3A7062C5.482DA161@FreeBSD.org>; from sobomax@FreeBSD.org on Thu, Jan 25, 2001 at 07:30:46PM +0200 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 07:30:46PM +0200, Maxim Sobolev wrote: > Nicolas Souchu wrote: > > > On Wed, Jan 24, 2001 at 08:14:01PM +0200, Maxim Sobolev wrote: > > > > > > > > Isn't your list of modes redundant with the internal data structures of the > > > > VGA/VESA driver? Why do you list modes if it's not to query a specific one? > > > > > > I believe that there should be possibility to do both these things, i.e. (1) query > > > list of available modes using some filter, so the aplication/toolkit will be able to > > > select one that matches its needs, and (2) let the video driver select the best one > > > given certain constrains. For example SDL provides a possibility to at least emulate > > > mode if is not directly available from video hardware, so it need to know what the > > > alternatives are. > > > > All this is done by GGI. I agree that you may need it for SDL. > > So why not to put it into libvgl and allow any toolkit use this code? I think we should rather consider GGI or SDL has the future graphic standard in FreeBSD and rewrite VGL on top of it :) The port of GGI on top of VGL is just an intermediate step before moving everything in the kernel like KGI does. But, I hesitate a bit now with moving everything in the kernel and add the overhead of context switches. > > So, the mousehandler is called each time the mouse is moving? > > Yes, each time mouse is moving syscons driver sends a signal specified by the CONS_MOUSECTL > ioctl. What I'm proposing here is to add a knob to allow vgl-using apps to assign their own > handlers for this. > > > The SDL library is synchronous with input peripheral? > > It depends on specific driver implementation. You can make it to either query mouse position > periodically or be synchronous with input peripheral. Matter of taste ;). > > > How will you handle acceleration with SDL? > > There are not much you can do about acceleration with vgl, hovewer SDL in general contains a > provision for hardware accelerated blits. Yes, performance is a big caveat of vgl. But, it was not designed for this. As far as I could understand libvgl was rather a quick implementation. Building a true graphic library on top of it may not be a good choice. What is SDL typical backend in Linux, fb, X11? > > Ok, do you have any patches for vgl yet? I would like to take a look at it if possible. No, everything has been commited to -current after review by Soren. Nicholas -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:40:20 2001 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 69C8D37B402 for ; Thu, 25 Jan 2001 10:40:00 -0800 (PST) Received: from victoria-221.budapest.interware.hu ([195.70.63.221] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LrJG-0004vZ-00; Thu, 25 Jan 2001 19:39:50 +0100 Message-ID: <3A7072EA.5107A85E@elischer.org> Date: Thu, 25 Jan 2001 10:39:38 -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: Maksim Yevmenkin Cc: "Koster, K.J." , 'Suma H R' , Brahma Naidu Golla , hackers@FreeBSD.ORG Subject: Re: Pseudo ethernet interface References: <59063B5B4D98D311BC0D0001FA7E4522026D7B57@l04.research.kpn.com> <3A705B4D.C0D2E678@digisle.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 Maksim Yevmenkin wrote: > > > > Is it possible to provide pseudo ethernet interfaces? > > > Can we associate an IP and MAC address with a psuedo ethernet > > > interface > > > to facilitate data packet transmission & reception through that? > > yes. > > > > If so, how does it work? > > > Pointers to any documentation in this regard will be appreciated. > > > > > $ man tap > $ man ng_ether > > > Have you looked at the tun device? there is a pseudo ethernet netgraph node available from: http://www.riss-telecom.ru/~vitaly/ > > this is IP only. > > thanks, > emax > > 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_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:51:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailman.packetdesign.com (dns.PACKETDESIGN.NET [216.15.46.10]) by hub.freebsd.org (Postfix) with ESMTP id 6749537B6A7; Thu, 25 Jan 2001 10:50:56 -0800 (PST) Received: from bubba.packetdesign.com (bubba.packetdesign.com [192.168.0.223]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f0PIosI77362; Thu, 25 Jan 2001 10:50:54 -0800 (PST) (envelope-from archie@packetdesign.com) Received: (from archie@localhost) by bubba.packetdesign.com (8.11.1/8.11.1) id f0PIoUw67420; Thu, 25 Jan 2001 10:50:30 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101251850.f0PIoUw67420@bubba.packetdesign.com> Subject: sf driver problem? To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Date: Thu, 25 Jan 2001 10:50:30 -0800 (PST) Cc: wpaul@freebsd.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anyone had any luck in figuring out why the Adaptec ANA four-port Ethernet cards dramatically slow down the machine when all four ports are in use? http://www.freebsd.org/cgi/query-pr.cgi?pr=22624 (nevermind the video interrupt conflict theory, that doesn't seem to have anything to do with it) Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:51:43 2001 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 4012737B6A9 for ; Thu, 25 Jan 2001 10:51:12 -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 NAA73761; Thu, 25 Jan 2001 13:53:38 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010125135815.03ce21b0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 25 Jan 2001 14:00:47 -0500 To: mjacob@feral.com From: Dennis Subject: Re: if_fxp driver info Cc: Jonathan Lemon , hackers@FreeBSD.ORG In-Reply-To: References: <5.0.0.25.0.20010125130845.030de0f0@mail.etinc.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 01:24 PM 01/25/2001, Matthew Jacob wrote: > > If they have a published, freely distributable driver for linux. why would > > you have to sign an NDA to port it to FreeBSD? > >You don't. But reverse engineering isn't always complete. there is a difference between "reverse engineering" and porting a commented source driver with a spec for the part available. >I should know- having gone through hell for the Gigabit NIC for *BSD... mostly >reverse engineered from the Linux driver. Your problem here was that the LINUX driver was reverse engineered. So your source was faulty. The case with the intel driver is the "ASSumption" that its been done correctly and that the procedures for using the functions available are correct. Dennis >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:53:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 589B637B6A9 for ; Thu, 25 Jan 2001 10:52:50 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA22449; Thu, 25 Jan 2001 10:52:46 -0800 Date: Thu, 25 Jan 2001 10:52:45 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dennis Cc: Jonathan Lemon , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info In-Reply-To: <5.0.0.25.0.20010125135815.03ce21b0@mail.etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Jan 2001, Dennis wrote: > At 01:24 PM 01/25/2001, Matthew Jacob wrote: > > > > If they have a published, freely distributable driver for linux. why would > > > you have to sign an NDA to port it to FreeBSD? > > > >You don't. But reverse engineering isn't always complete. > > > there is a difference between "reverse engineering" and porting a commented > source driver with a spec for the part available. That's the crux - the spec isn't available w/o NDA. > > > > >I should know- having gone through hell for the Gigabit NIC for *BSD... mostly > >reverse engineered from the Linux driver. > > > Your problem here was that the LINUX driver was reverse engineered. So your > source was faulty. The case with the intel driver is the "ASSumption" that > its been done correctly and that the procedures for using the functions > available are correct. > > Dennis > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:53:35 2001 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 2911137B6AE for ; Thu, 25 Jan 2001 10:53:15 -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 f0PIqft83850; Thu, 25 Jan 2001 10:52:41 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Xavier Galleri Cc: Alfred Perlstein , Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel memory allocation bug ... In-Reply-To: Message from Xavier Galleri of "Thu, 25 Jan 2001 19:36:01 +0100." <3A707211.2080801@enition.com> Date: Thu, 25 Jan 2001 10:52:41 -0800 Message-ID: <83845.980448761@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > That said, I still remain astonished not to get any comments or > questions or hints or any other reactions about the analysis I have > already provided. I have seen other mails in this list that exposed > different kind of issues without requiring code sample to feed a > constructive discussion. Did I miss something ? Some types of problems simply lend themselves to being analyzed without code and others do not. Perhaps the code in question is similar to other code someone is familiar with, or perhaps they're doing parallel work and can related it to the missing code sample, either way it's pretty clear when you get NO feedback on something that your problem does not fall into that category. Feedback in FreeBSD (or in any other open source community) is driven by a very Darwinian process: Those questions which can generate a productive response given the ambient developer time-and-skill conditions generally do, whereas those which can't, don't. It's not an issue to be taken personally, but rather scientifically. If your question generated absolutely no response then the question was simply not "strong" enough and was ruthlessly culled from the question pool through the selection pressure of evolution. Of course, if you're a Creationist rather than a Darwinist then other equally compelling explanations apply. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:55: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 6C89037B6AE for ; Thu, 25 Jan 2001 10:54:46 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0PIsHl77720; Thu, 25 Jan 2001 12:54:17 -0600 (CST) (envelope-from jlemon) Date: Thu, 25 Jan 2001 12:54:17 -0600 From: Jonathan Lemon To: Dennis Cc: Jonathan Lemon , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info Message-ID: <20010125125417.L29115@prism.flugsvamp.com> References: <200101250358.f0P3w8g49073@prism.flugsvamp.com> <5.0.0.25.0.20010125130845.030de0f0@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <5.0.0.25.0.20010125130845.030de0f0@mail.etinc.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 01:12:42PM -0500, Dennis wrote: > At 10:58 PM 01/24/2001, Jonathan Lemon wrote: > >In article > > > >you write: > > > > > >> > > >> > I'll look into the Linux driver, however, and see if it has anything > > >> > useful in it. Historically the Linux Pro/100+ driver has totally > > sucked and > > >> > was chalk-full of magic numbers being anded and ored. > > >> > > >>That's "chock full", and you're confusing the Becker driver (bad) with > > >>the Intel-supplied driver (slightly less bad). > > > > > > > > >The intel driver seems to cover all the bases and has some nice glue > > >routines for determining the part and features available. > > > > > >I havent tested it under load, but I wonder if intel would consider > > >supporting it if someone ported it over to freebsd? they have drivers for > > >just about every other major OS except BSD. it would be nice if the driver > > >was updated BEFORE cards and MBs that dont work started showing up on the > > >loading dock. Every time I get a shipment we have to hold our breath until > > >we try one out. > > > >The documentation is available, if you want to (or have to) sign an > >NDA. People who have the NDA documentation are perfectly capable of > >writing a driver, although the source can't be released. It would > >probably be possible to release a binary driver, but why do anything > >to help Intel, given their unhelpful attitude? > > If they have a published, freely distributable driver for linux. why would > you have to sign an NDA to port it to FreeBSD? > > I dont think so. Not anymore anyway. Thats the whole point of this thread... Having looked at the Linux driver, the FreeBSD driver, and the documentation, I can tell you that assuredly not all of the features are documented in the Linux driver. Also, porting requires changing things, and without an understanding of _WHY_ things are done the way they are, you can end up invaderdently changing something that turns out to be critical. Also, the Intel driver isn't put together very well, so you might end up with a lower performance driver after all is said and done. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:55:46 2001 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 ACA0637B6A7 for ; Thu, 25 Jan 2001 10:55:27 -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 NAA73809; Thu, 25 Jan 2001 13:57:52 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010125140121.03ce1400@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 25 Jan 2001 14:05:02 -0500 To: dg@root.com From: Dennis Subject: Re: if_fxp driver info Cc: Sergey Babkin , hackers@FreeBSD.ORG In-Reply-To: <200101251748.JAA27288@implode.root.com> References: 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 12:48 PM 01/25/2001, David Greenman wrote: > >> I don't know what list you are looking at, but the download list that > >> I was > >>looking at did not include SCO, Unixware or any other Unix variant except > >>Linux. > > > >This is the list. > > > >NDIS2, NDIS3, NDIS4 and NDIS5 drivers > > Novell Netware* Client 3.11, 3.12 > > Novell Netware Server 4.1x, 5 > > SunSoft Solaris* > > SCO Unix 3, 5 > > SCO UnixWare* 2, 7, OpenDesktop*, OpenServer* > > > >These are "licensed" drivers. The linux driver is free. > > How do you know that the above drivers are developed by Intel? The above >could easily be OS vendor supplied. It's anybody's guess without the source. I dont know that the linux driver is actually maintained by intel either. But I doubt that intel would license a driver that they dont support. It seems unlikely that intel would write their own driver for linux (when one was available) and not for other OS's. Part of selling a hardware only solution is having a working driver for the major OSs. Whether they are developed by intel or not it not relevant. Only that they are kept up to date by intel or verified to be up to date is what is important. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 10:57: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 8C10D37B6B2 for ; Thu, 25 Jan 2001 10:56:47 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0PIuGc77776; Thu, 25 Jan 2001 12:56:16 -0600 (CST) (envelope-from jlemon) Date: Thu, 25 Jan 2001 12:56:16 -0600 From: Jonathan Lemon To: Dennis Cc: mjacob@feral.com, Jonathan Lemon , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info Message-ID: <20010125125616.M29115@prism.flugsvamp.com> References: <5.0.0.25.0.20010125130845.030de0f0@mail.etinc.com> <5.0.0.25.0.20010125135815.03ce21b0@mail.etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <5.0.0.25.0.20010125135815.03ce21b0@mail.etinc.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 02:00:47PM -0500, Dennis wrote: > The case with the intel driver is the "ASSumption" that > its been done correctly and that the procedures for using the functions > available are correct. Bahwhahahahah. Right. Yeah, right. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 11:46:27 2001 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 1F9BB37B6B4 for ; Thu, 25 Jan 2001 11:46:07 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PJk2B26688; Thu, 25 Jan 2001 11:46:02 -0800 (PST) Date: Thu, 25 Jan 2001 11:46:02 -0800 From: Alfred Perlstein To: Xavier Galleri Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel memory allocation bug ... Message-ID: <20010125114602.Q26076@fw.wintelcom.net> References: <200101191524.f0JFOtk14877@mobile.wemm.org> <3A6861DF.8060108@enition.com> <3A706788.5040509@enition.com> <20010125101659.N26076@fw.wintelcom.net> <3A707211.2080801@enition.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A707211.2080801@enition.com>; from xgalleri@enition.com on Thu, Jan 25, 2001 at 07:36:01PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Xavier Galleri [010125 10:36] wrote: > Alfred Perlstein wrote: > > > I told you about 3 times to provide us with a stipped down source > > code module which reproduces this "bug". > > > > You haven't done this. > > > > Therefore I can't help you. > > > > I did not expect to make trouble to anyone, just sorry for the > inconvenience ... I am not sure that we could easily provide for some > code sample on this issue since this could be expensive, but I will see > for sure (I easily understand that this is easier for anybody to track > down a problem in such conditions ;-). > > That said, I still remain astonished not to get any comments or > questions or hints or any other reactions about the analysis I have > already provided. I have seen other mails in this list that exposed > different kind of issues without requiring code sample to feed a > constructive discussion. Did I miss something ? You missed the two other people reporting "bugs" the same week you began to. I spend a couple of hours trying to track them down and they wound up being errors in thier code and not FreeBSD's. Honestly the symptoms you describe lean towards error on your part. Even if they are not your error they seem pretty hard to reproduce. You've been complaining about this problem for at least a week. Producing some code so that we can test couldn't take more than a couple of hours and would have probably had your issue resolved by now. This is why I'm irritated that you still haven't provided any code to reproduce it. I do appreciate your mini-kernel debug howto, I've got it saved for future reference. -- -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 Jan 25 11:48:50 2001 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 38A3437B69F for ; Thu, 25 Jan 2001 11:48:33 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PJmRe26734; Thu, 25 Jan 2001 11:48:27 -0800 (PST) Date: Thu, 25 Jan 2001 11:48:27 -0800 From: Alfred Perlstein To: Jordan Hubbard Cc: Xavier Galleri , Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel memory allocation bug ... Message-ID: <20010125114827.R26076@fw.wintelcom.net> References: <83845.980448761@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: <83845.980448761@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Thu, Jan 25, 2001 at 10:52:41AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jordan Hubbard [010125 10:52] wrote: > > That said, I still remain astonished not to get any comments or > > questions or hints or any other reactions about the analysis I have > > already provided. I have seen other mails in this list that exposed > > different kind of issues without requiring code sample to feed a > > constructive discussion. Did I miss something ? > > Some types of problems simply lend themselves to being analyzed > without code and others do not. Perhaps the code in question is > similar to other code someone is familiar with, or perhaps they're > doing parallel work and can related it to the missing code sample, > either way it's pretty clear when you get NO feedback on something > that your problem does not fall into that category. Three requests for sample code to make sure it's not pilot error and to assist in finding the bug isn't "not responding", it's expecting the problem reporter to be responsible and give us something we can work with. No offence Jordan, but you don't owe Xavier an apology, _yet_. :) -- -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 Jan 25 11:53:12 2001 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 0C00837B699 for ; Thu, 25 Jan 2001 11:52:54 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PJqrn26990 for hackers@freebsd.org; Thu, 25 Jan 2001 11:52:53 -0800 (PST) Date: Thu, 25 Jan 2001 11:52:53 -0800 From: Alfred Perlstein To: hackers@freebsd.org Subject: SYSINIT for userland? Message-ID: <20010125115253.T26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anyone done any work for FreeBSD or GNU C that allows for SYSINITs in userland, meaning just having to specify a function and arg to be called at a certain time during program startup? I know you can do some evil magic with overloading special shared object symbols, but it is evil magic. :) Anyone know of another OS that supports this? Any standards for it on the way? -- -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 Jan 25 12: 8:52 2001 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 EC70637B402 for ; Thu, 25 Jan 2001 12:08:31 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0PK8Lx36621; Thu, 25 Jan 2001 12:08:21 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0PK7sF01565; Thu, 25 Jan 2001 12:07:54 -0800 (PST) (envelope-from jhb) 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: <20010125115253.T26076@fw.wintelcom.net> Date: Thu, 25 Jan 2001 12:07:54 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Alfred Perlstein Subject: RE: SYSINIT for userland? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25-Jan-01 Alfred Perlstein wrote: > Has anyone done any work for FreeBSD or GNU C that allows for > SYSINITs in userland, meaning just having to specify a function > and arg to be called at a certain time during program startup? > > I know you can do some evil magic with overloading special shared > object symbols, but it is evil magic. :) > > Anyone know of another OS that supports this? Any standards for > it on the way? Use C++ with static instances of classes that have constructors. -- 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 Jan 25 12:16:29 2001 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 0FD9237B402; Thu, 25 Jan 2001 12:16:08 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PKG7C27857; Thu, 25 Jan 2001 12:16:07 -0800 (PST) Date: Thu, 25 Jan 2001 12:16:07 -0800 From: Alfred Perlstein To: John Baldwin Cc: hackers@FreeBSD.ORG Subject: Re: SYSINIT for userland? Message-ID: <20010125121607.V26076@fw.wintelcom.net> References: <20010125115253.T26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Thu, Jan 25, 2001 at 12:07:54PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010125 12:09] wrote: > > On 25-Jan-01 Alfred Perlstein wrote: > > Has anyone done any work for FreeBSD or GNU C that allows for > > SYSINITs in userland, meaning just having to specify a function > > and arg to be called at a certain time during program startup? > > > > I know you can do some evil magic with overloading special shared > > object symbols, but it is evil magic. :) > > > > Anyone know of another OS that supports this? Any standards for > > it on the way? > > Use C++ with static instances of classes that have constructors. I've got a pretty good idea of how it could be done in C++. Have a global list that each object adds itself to in sorted order (via static constructor), the manipulation should be serialized, but this still isn't a solution for C. -- -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 Jan 25 12:16:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id E4ADB37B69B for ; Thu, 25 Jan 2001 12:16:18 -0800 (PST) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.1/8.11.1) id f0PKG9u02737; Thu, 25 Jan 2001 15:16:10 -0500 (EST) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.4.6-3 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010125115253.T26076@fw.wintelcom.net> Date: Thu, 25 Jan 2001 15:16:09 -0500 (EST) Organization: Verizon Laboratories Inc. From: "Alexander N. Kabaev" To: Alfred Perlstein Subject: RE: SYSINIT for userland? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Will functions marked with __attribute__((__constructor__)) or __attribute__((__destructor__)) satisfy your needs? Compiler will insert calls to these functions gets into .init section of the resulting ELF module which in turn will be called automatically at the program startup time. I do not remember exactly, but there might be even priority parameter you can specify with these attributes to manage the order in which these functions will be called. On 25-Jan-2001 Alfred Perlstein wrote: > Has anyone done any work for FreeBSD or GNU C that allows for > SYSINITs in userland, meaning just having to specify a function > and arg to be called at a certain time during program startup? > > I know you can do some evil magic with overloading special shared > object symbols, but it is evil magic. :) > > Anyone know of another OS that supports this? Any standards for > it on the way? > > -- > -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 ---------------------------------- E-Mail: Alexander N. Kabaev Date: 25-Jan-2001 Time: 15:10:40 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 12:20:31 2001 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 30EC237B6A2 for ; Thu, 25 Jan 2001 12:20:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PKJxQ27939; Thu, 25 Jan 2001 12:19:59 -0800 (PST) Date: Thu, 25 Jan 2001 12:19:59 -0800 From: Alfred Perlstein To: "Alexander N. Kabaev" Cc: hackers@FreeBSD.ORG Subject: Re: SYSINIT for userland? Message-ID: <20010125121959.W26076@fw.wintelcom.net> References: <20010125115253.T26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ak03@gte.com on Thu, Jan 25, 2001 at 03:16:09PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alexander N. Kabaev [010125 12:16] wrote: > Will functions marked with __attribute__((__constructor__)) or > __attribute__((__destructor__)) satisfy your needs? > Compiler will insert calls to these functions gets into .init section of the > resulting ELF module which in turn will be called automatically at the program > startup time. I do not remember exactly, but there might be even priority > parameter you can specify with these attributes to manage the order in which > these functions will be called. Actually, the order can be kludged by just having these __constructors__ sort themselves into a list. Then all you need is a function call in main() to actually start these puppies up. :) It's still a bit off what I was looking for which would be putting these hooks into shared libaries hinged on pthread initialization, dns init, etc... -- -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 Jan 25 12:34:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (unknown [169.237.8.131]) by hub.freebsd.org (Postfix) with ESMTP id 1E80D37B698 for ; Thu, 25 Jan 2001 12:34:35 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0PKoD801434; Thu, 25 Jan 2001 12:50:13 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101252050.f0PKoD801434@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: "Alexander N. Kabaev" , hackers@FreeBSD.ORG Subject: Re: SYSINIT for userland? In-reply-to: Your message of "Thu, 25 Jan 2001 12:19:59 PST." <20010125121959.W26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 12:50:13 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Alexander N. Kabaev [010125 12:16] wrote: > > Will functions marked with __attribute__((__constructor__)) or > > __attribute__((__destructor__)) satisfy your needs? > > Compiler will insert calls to these functions gets into .init section of the > > resulting ELF module which in turn will be called automatically at the program > > startup time. I do not remember exactly, but there might be even priority > > parameter you can specify with these attributes to manage the order in which > > these functions will be called. > > Actually, the order can be kludged by just having these __constructors__ > sort themselves into a list. Then all you need is a function call > in main() to actually start these puppies up. :) > > It's still a bit off what I was looking for which would be putting > these hooks into shared libaries hinged on pthread initialization, > dns init, etc... You can actually do almost all of this with the ELF evilness that the loader uses (on i386) for doing its version of sysinits. Then you would just need to teach the C startup code to go looking for the appropriate section(s). -- ... 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 Jan 25 13: 0:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.delanet.com (mail-20.delanet.com [216.226.64.26]) by hub.freebsd.org (Postfix) with SMTP id B1F2337B69B for ; Thu, 25 Jan 2001 13:00:22 -0800 (PST) Received: (qmail 81450 invoked from network); 25 Jan 2001 21:00:15 -0000 Received: from unknown (HELO delanet.com) (216.226.64.52) by mail.delanet.com with SMTP; 25 Jan 2001 21:00:15 -0000 Message-ID: <3A7096AA.68FBBA90@delanet.com> Date: Thu, 25 Jan 2001 16:12:10 -0500 From: Delanet Administration Reply-To: admin@delanet.com Organization: Delanet, Inc. X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: NFS server out of mbuf's? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I run a FreeBSD 3.2s nfs server which recently crashed with a panic 'Out of mbuf clusters'. I found this odd since the normal peak is always below 200 and I compiled the kernel with users at 256 (4608 max mbufs). The server had an uptime of 118 days prior to this crash, and has no entries in the logs out of the norm up until this crash. Just curious if anyone knows of any reason this would happen? The server has no other use at all..no one even logs into it except me on occasion to go over logs and such. Thanks and regards, -- ------------------------------------------------------------ Stephen Comoletti - Network Engineer / Systems Administrator Delanet Inc. http://www.delanet.com Frontline Communications Corp. http://www.fcc.net phone: (302) 326-5800 fax: (302) 326-5802 x312 262 Quigley Blvd, New Castle, DE 19720, USA ------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 16:55:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 65CBD37B6A0 for ; Thu, 25 Jan 2001 16:55:13 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-148.nnj.dialup.bellatlantic.net [151.198.117.148]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA15319; Thu, 25 Jan 2001 19:55:05 -0500 (EST) Message-ID: <3A70CAE8.2F3CFB2E@bellatlantic.net> Date: Thu, 25 Jan 2001 19:55:04 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: dg@root.com Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info References: <200101251748.JAA27288@implode.root.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > > >> I don't know what list you are looking at, but the download list that > >> I was > >>looking at did not include SCO, Unixware or any other Unix variant except > >>Linux. > > > >This is the list. > > > >NDIS2, NDIS3, NDIS4 and NDIS5 drivers > > Novell Netware* Client 3.11, 3.12 > > Novell Netware Server 4.1x, 5 > > SunSoft Solaris* > > SCO Unix 3, 5 > > SCO UnixWare* 2, 7, OpenDesktop*, OpenServer* > > > >These are "licensed" drivers. The linux driver is free. > > How do you know that the above drivers are developed by Intel? The above > could easily be OS vendor supplied. It's anybody's guess without the source. The drivers for SCO are developed by Intel, and bug reports are usually redirected to Intel. SCO just does build and packaging. If SCO produces some fixes, they are sent back to Intel as well. I get occasionally involved in this process and know for sure. Though I don't know if SCO pays anything to Intel for that, probably not, considering that Intel loans their hardware to SCO for free. These drivers contain some code ifdef-ed for Compaq and ICL builds, so I suppose Compaq and ICL also do their own packagind when they supply these drivers with UnixWare on their machines. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 17: 9:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id 0410D37B6A6; Thu, 25 Jan 2001 17:09:13 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA08439; Thu, 25 Jan 2001 17:09:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f0Q19AL25724; Thu, 25 Jan 2001 17:09:10 -0800 X-Virus-Scanned: Thu, 25 Jan 2001 17:09:10 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from vijay.iprg.nokia.com (205.226.11.157, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdD34CH0; Thu, 25 Jan 2001 17:09:00 PST Message-ID: <3A70CE2E.40CA6E58@iprg.nokia.com> Date: Thu, 25 Jan 2001 17:09:02 -0800 From: vijay Organization: Nokia - IMN X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hackers , Questions Subject: resource overheads 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 was wondering if there was any literature (maybe specific to FreeBSD or in general) about the overheads of various programming techniques etc. For eg, reducing the number of system calls, and mapping them to Library function calls, or say use of inline fucntions vs otherwise. v. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 18: 9:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 3EA2137B400; Thu, 25 Jan 2001 18:09:19 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0Q2P4101239; Thu, 25 Jan 2001 18:25:05 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101260225.f0Q2P4101239@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: hardware@freebsd.org Cc: hackers@freebsd.org Reply-To: hardware@freebsd.org Subject: 3ware ATA RAID 3DM management utility available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 18:25:04 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (Please trim cc's on any followups to remove -hackers, thanks.) I'm happy to announce a quick public BETA cycle for the 3ware 3DM management utility for their family of ATA RAID controllers and FreeBSD. 3DM allows you to monitor and repair RAID arrays on 3ware controllers using a web browser, as well as generate email alerts on events and so forth. See http://www.3ware.com/products/3dm.shtml for more details. The product is not available in source form (sorry folks), but is compiled statically and should run on any FreeBSD system supporting the 3ware controllers (4.2 or later recommended). Thanks to 3ware for their support, and to my beta testers for their valuable input and persistence. -- ... 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 Jan 25 19: 3:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-d02.mx.aol.com (imo-d02.mx.aol.com [205.188.157.34]) by hub.freebsd.org (Postfix) with ESMTP id 414C737B404 for ; Thu, 25 Jan 2001 19:03:39 -0800 (PST) Received: from GLOBALLINK2001@aol.com by imo-d02.mx.aol.com (mail_out_v29.5.) id n.8c.189517c (7866) for ; Thu, 25 Jan 2001 22:03:36 -0500 (EST) From: GLOBALLINK2001@aol.com Message-ID: <8c.189517c.27a24307@aol.com> Date: Thu, 25 Jan 2001 22:03:35 EST Subject: Kernel Hacking (i tried not to make it lame) To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 59 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hey guys i know you probably get this question all the time but i am looking into getting into doing somekernel hacking first i will tell you some thing i have assumed about it: 1.) you should know atleast more programming language well (probably C would be best) 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System that is about it the rest really is a blur and is so complex and huge i have no idea where to begin hope i wasn't to lame guys :-) Arthur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 19:48:32 2001 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 104D337B402 for ; Thu, 25 Jan 2001 19:48:11 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 9F8226AB73; Fri, 26 Jan 2001 14:18:08 +1030 (CST) Date: Fri, 26 Jan 2001 14:18:08 +1030 From: Greg Lehey To: Jonathan Lemon Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: if_fxp driver info Message-ID: <20010126141808.D1222@wantadilla.lemis.com> References: <200101250358.f0P3w8g49073@prism.flugsvamp.com> <5.0.0.25.0.20010125130845.030de0f0@mail.etinc.com> <20010125125417.L29115@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: <20010125125417.L29115@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Jan 25, 2001 at 12:54:17PM -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 Thursday, 25 January 2001 at 12:54:17 -0600, Jonathan Lemon wrote: > On Thu, Jan 25, 2001 at 01:12:42PM -0500, Dennis wrote: >> At 10:58 PM 01/24/2001, Jonathan Lemon wrote: >>> In article >>> >>> you write: >>>> >>>>> >>>>>> I'll look into the Linux driver, however, and see if it has anything >>>>>> useful in it. Historically the Linux Pro/100+ driver has totally >>> sucked and >>>>>> was chalk-full of magic numbers being anded and ored. >>>>> >>>>> That's "chock full", and you're confusing the Becker driver (bad) with >>>>> the Intel-supplied driver (slightly less bad). >>>> >>>> >>>> The intel driver seems to cover all the bases and has some nice glue >>>> routines for determining the part and features available. >>>> >>>> I havent tested it under load, but I wonder if intel would consider >>>> supporting it if someone ported it over to freebsd? they have drivers for >>>> just about every other major OS except BSD. it would be nice if the driver >>>> was updated BEFORE cards and MBs that dont work started showing up on the >>>> loading dock. Every time I get a shipment we have to hold our breath until >>>> we try one out. >>> >>> The documentation is available, if you want to (or have to) sign an >>> NDA. People who have the NDA documentation are perfectly capable of >>> writing a driver, although the source can't be released. It would >>> probably be possible to release a binary driver, but why do anything >>> to help Intel, given their unhelpful attitude? >> >> If they have a published, freely distributable driver for linux. why would >> you have to sign an NDA to port it to FreeBSD? >> >> I dont think so. Not anymore anyway. Thats the whole point of this thread... > > Having looked at the Linux driver, the FreeBSD driver, and the > documentation, I can tell you that assuredly not all of the features > are documented in the Linux driver. Also, porting requires changing > things, and without an understanding of _WHY_ things are done the > way they are, you can end up invaderdently changing something that > turns out to be critical. > > Also, the Intel driver isn't put together very well, so you might end > up with a lower performance driver after all is said and done. Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? 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 Thu Jan 25 19:59:48 2001 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 0B4A637B400 for ; Thu, 25 Jan 2001 19:59:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f0Q3xRF09275 for ; Thu, 25 Jan 2001 22:59:27 -0500 (EST) Date: Thu, 25 Jan 2001 22:59:27 -0500 (EST) From: Alwyn Goodloe To: hackers@FreeBSD.org Subject: Divert Sockets & Fragmentation revisited 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 Guys still having problems with divert sockets and fragmentation. As I said in a previous post the divert operations and corresponding program work fine when the datagram sent have size < MTU (1500) but when the datagram has size > MTU and hence get fragmented the recfrom just waits never receiving anything. I am attaching the relevent code fragments below. tcpdump tells me that the packets arrive on the interface. Hence I know the fragments arrive. Now my ipfw commands are: ipfw add 60000 divert 4422 udp from any to any 3322 in ipfw add 65000 allow ip from any to any Now I thought that that maybe the divert being so specific was a problem so I tried flushing ipfw and using the command: ipfw add 60000 divert 4422 ip from any to any thus diverting any ip packets and still nothing. Now according to the man page on divert: Incomming packets which get diverted are fully reassembled before delivery of any one fragment. Diversion of any one packet causes the entire packet to get diverted. I different fragments get diverted to different ports, then which port ultimately gets diverted is unpredictable. I was under the impression that the packets wern't reassemblembed before diversion. Am I wrong here? If the packets are reassembled before the diversion but as it says about that it may be unpredictable as to where they are sent could explain the case where I was redirecting udp packets heading toward 3322 but not the case where I was redirecting all IP packets. Any suggestions as to what stupid thing I have failed to do here. Alwyn Goodloe agoodloe@gradient.cis.upenn.edu Here is the important code fragments: Note: I have played with the MAX_PACKET_SIZE in hopes that it would make some difference but to no avail. #define MAX_PACKET_SIZE 300000 #define DIVERTPort 4422 #define ACTIVE_UDP_PORT 3322 if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) sys_error("divert socket error"); set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); printf("Step 1 \n"); /* Register address and port with the system */ if (bind(divert_sock, (struct sockaddr*) &server_divert,sizeof(server_divert)) < 0) sys_error("server_divert bind error"); for ( ; ; ) { n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, ( struct sockaddr * ) &client_add,&clilen); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 20:24:42 2001 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 347CE37B400 for ; Thu, 25 Jan 2001 20:24:21 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id E27F56AB74; Fri, 26 Jan 2001 14:54:17 +1030 (CST) Date: Fri, 26 Jan 2001 14:54:17 +1030 From: Greg Lehey To: GLOBALLINK2001@aol.com Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Hacking (i tried not to make it lame) Message-ID: <20010126145417.H1222@wantadilla.lemis.com> References: <8c.189517c.27a24307@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8c.189517c.27a24307@aol.com>; from GLOBALLINK2001@aol.com on Thu, Jan 25, 2001 at 10:03:35PM -0500 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 Thursday, 25 January 2001 at 22:03:35 -0500, GLOBALLINK2001@aol.com wrote: > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Correct on both counts. > that is about it the rest really is a blur and is so complex and > huge i have no idea where to begin hope i wasn't to lame guys :-) Well, once you have the book, look at something you might find interesting, and play around with it a bit. If you keep a "diary of a learning hacker" on the web, you might do a great favour to a number of people like yourself. If you run into trouble, ask here. 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 Thu Jan 25 20:32:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from imo-d09.mx.aol.com (imo-d09.mx.aol.com [205.188.157.41]) by hub.freebsd.org (Postfix) with ESMTP id 45C0F37B404 for ; Thu, 25 Jan 2001 20:32:27 -0800 (PST) Received: from GLOBALLINK2001@aol.com by imo-d09.mx.aol.com (mail_out_v29.5.) id n.7c.10c50264 (7866) for ; Thu, 25 Jan 2001 23:32:15 -0500 (EST) From: GLOBALLINK2001@aol.com Message-ID: <7c.10c50264.27a257ce@aol.com> Date: Thu, 25 Jan 2001 23:32:14 EST Subject: Re: Kernel Hacking (i tried not to make it lame) To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 59 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG so you mean like take one section at a time? like device drivers, smp etc? whatever catches my interest? ok i see just like programming when you got something big break it into parts, and wow can't belive the author of a great book and a core team member answered my question in less than an hour, try getting that from another OS :-) thanks greg! -Arthur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 25 22: 1:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 6118737B400 for ; Thu, 25 Jan 2001 22:01:16 -0800 (PST) Received: (qmail 49155 invoked from network); 26 Jan 2001 06:01:15 -0000 Received: from cognac.local.mindstep.com (HELO cognac) (192.168.10.9) by jacuzzi.local.mindstep.com with SMTP; 26 Jan 2001 06:01:15 -0000 From: "Patrick Bihan-Faou" To: Cc: Subject: Re: Divert Sockets & Fragmentation revisited Date: Fri, 26 Jan 2001 01:02:33 -0500 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.2911.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 Hi, Sorry to state something that is obvious, but when you bind your socket to the port, you have the port in the correct (network) order ? i.e. do you use htons(DIVERTPort) ? If you have lsof installed, run it and look at the port number that your program listens on. Patrick. > Here is the important code fragments: > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make some > difference but to no avail. > > #define MAX_PACKET_SIZE 300000 > #define DIVERTPort 4422 > #define ACTIVE_UDP_PORT 3322 > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > sys_error("divert socket error"); > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > printf("Step 1 \n"); /* Register address and port with the system */ > if (bind(divert_sock, (struct sockaddr*) &server_divert,sizeof(server_divert)) < 0) > sys_error("server_divert bind error"); > for ( ; ; ) { > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > ( struct sockaddr * ) &client_add,&clilen); > > > > > 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 Jan 26 1:11:12 2001 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 BEC9737B400 for ; Fri, 26 Jan 2001 01:10:54 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0Q9Arq18352; Fri, 26 Jan 2001 01:10:53 -0800 (PST) Date: Fri, 26 Jan 2001 01:10:53 -0800 From: Alfred Perlstein To: GLOBALLINK2001@aol.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Hacking (i tried not to make it lame) Message-ID: <20010126011053.C26076@fw.wintelcom.net> References: <8c.189517c.27a24307@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8c.189517c.27a24307@aol.com>; from GLOBALLINK2001@aol.com on Thu, Jan 25, 2001 at 10:03:35PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * GLOBALLINK2001@aol.com [010125 19:04] wrote: > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) C is necessary including a strong understanding of the pre-precessor, knowing a bit about 'make' is also pretty important. > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Well more than 'basic' hopefully. :) Good choice on a book, others to look at are: "UNIX Internals 'the new frontiers'" Vahalia "The Basic Kernel Source Secrets" Jolitz and of course "The UNIX Hater's Handbook" > that is about it the rest really is a blur and is so complex and huge i have > no idea where to begin hope i wasn't to lame guys :-) Find a local user group, find and talk to some kernel hackers, but step away at the first sign of dizzyness or lightheadness. Feel free to ask on the mailing lists if something is confounding you, just be sure to check the mailing list archives first. best of luck, -- -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 Jan 26 1:29:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from FreeBSD.mine.nu (unknown [203.106.101.254]) by hub.freebsd.org (Postfix) with ESMTP id 7EE6F37B698 for ; Fri, 26 Jan 2001 01:29:05 -0800 (PST) Received: (from root@localhost) by FreeBSD.mine.nu (8.8.8/8.8.8) id RAA17270; Fri, 26 Jan 2001 17:41:22 +0800 (MYT) (envelope-from root) From: Ariff Abdullah Reply-To: skywizard@time.net.my Organization: FreeBSD 2.2.8-RELEASE To: Alfred Perlstein Subject: Re: Kernel Hacking (i tried not to make it lame) Date: Fri, 26 Jan 2001 17:30:15 +0800 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <8c.189517c.27a24307@aol.com> <20010126011053.C26076@fw.wintelcom.net> In-Reply-To: <20010126011053.C26076@fw.wintelcom.net> Cc: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Message-Id: <01012617412102.17166@FreeBSD.mine.nu> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Jan 2001, you wrote: > * GLOBALLINK2001@aol.com [010125 19:04] wrote: > > hey guys i know you probably get this question all the time but i am looking > > into getting into doing somekernel hacking first i will tell you some thing i > > have assumed about it: > > > 1.) you should know atleast more programming language well (probably C would > > be best) > > C is necessary including a strong understanding of the pre-precessor, > knowing a bit about 'make' is also pretty important. > > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > > on getting The Design and Implementation of the 4.4BSD Operating System > > Well more than 'basic' hopefully. :) > > Good choice on a book, others to look at are: > "UNIX Internals 'the new frontiers'" Vahalia > "The Basic Kernel Source Secrets" Jolitz > and of course "The UNIX Hater's Handbook" > > > that is about it the rest really is a blur and is so complex and huge i have > > no idea where to begin hope i wasn't to lame guys :-) > > Find a local user group, find and talk to some kernel hackers, but > step away at the first sign of dizzyness or lightheadness. > > Feel free to ask on the mailing lists if something is > confounding you, just be sure to check the mailing list archives > first. > > best of luck, The manual pages are very helpfull although not the complete references, the sources itself is the saviour. I remembered porting back cd9660 to 2.2.x tree, and now look forward porting softupdates (If anybody can give me some light I really appreciate that). I'm reviewing sources from current, stable and from other BSD project such OpenBSD to pick all the good stuffs. I'm a happy 2.2.x user. -- /\_____ / ./__ / __/ < I do understand.. / ___/ / / ^^^^^^^^^^^^^^^^^^^^^^ *warf* *warf* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 2:20:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 88DA637B400 for ; Fri, 26 Jan 2001 02:19:55 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0QANKD75091; Fri, 26 Jan 2001 02:23:20 -0800 (PST) (envelope-from kris) Date: Fri, 26 Jan 2001 02:23:20 -0800 From: Kris Kennaway To: Chris Csanady Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD Linux emulation / arla 0.34.6 Message-ID: <20010126022320.A75008@citusc17.usc.edu> References: <20010124185129.I45221@citusc17.usc.edu> <200101250415.WAA20143@isua5.iastate.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101250415.WAA20143@isua5.iastate.edu>; from ccsanady@iastate.edu on Wed, Jan 24, 2001 at 10:15:53PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2001 at 10:15:53PM -0600, Chris Csanady wrote: >=20 > >On Wed, Jan 24, 2001 at 12:50:29PM -0600, Chris wrote: > >> Silly me--I forgot to mention, this is with FreeBSD 4.2-STABLE. > > > >How recent -stable? A bug like this was fixed recently. If it's older > >than a week, Try upgrading :-) > > > >Kris >=20 > Hmm, are you referring to this commit? It appears to been MFC'd on > 11/07, so I hope not. :) I will rebuild and find out though.. That could be the one I'm thinking of. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6cVAYWry0BWjoQKURAoTGAJ4uhJO2AXC342RXcSaeGIPYnurwbQCgw2IN QRwUt2uYTBlJenS0D/e6vgc= =gorV -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 2:31:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 135AD37B400 for ; Fri, 26 Jan 2001 02:30:57 -0800 (PST) Received: by smtp.nettoll.com; Fri, 26 Jan 2001 11:29:40 +0100 (MET) Message-ID: <3A7151D5.2040405@enition.com> Date: Fri, 26 Jan 2001 11:30:45 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel memory allocation bug ... References: <200101191524.f0JFOtk14877@mobile.wemm.org> <3A6861DF.8060108@enition.com> <3A706788.5040509@enition.com> <20010125101659.N26076@fw.wintelcom.net> <3A707211.2080801@enition.com> <20010125114602.Q26076@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Xavier Galleri [010125 10:36] wrote: > >> Alfred Perlstein wrote: >> >>> I told you about 3 times to provide us with a stipped down source >>> code module which reproduces this "bug". >>> >>> You haven't done this. >>> >>> Therefore I can't help you. >>> >> I did not expect to make trouble to anyone, just sorry for the >> inconvenience ... I am not sure that we could easily provide for some >> code sample on this issue since this could be expensive, but I will see >> for sure (I easily understand that this is easier for anybody to track >> down a problem in such conditions ;-). >> >> That said, I still remain astonished not to get any comments or >> questions or hints or any other reactions about the analysis I have >> already provided. I have seen other mails in this list that exposed >> different kind of issues without requiring code sample to feed a >> constructive discussion. Did I miss something ? > > > You missed the two other people reporting "bugs" the same week you > began to. I spend a couple of hours trying to track them down and > they wound up being errors in thier code and not FreeBSD's. > > Honestly the symptoms you describe lean towards error on your part. > Even if they are not your error they seem pretty hard to reproduce. > > You've been complaining about this problem for at least a week. > Producing some code so that we can test couldn't take more than a > couple of hours and would have probably had your issue resolved > by now. > > This is why I'm irritated that you still haven't provided any code > to reproduce it. I wish I could avoid this misunderstanding ! The fact is that I was expecting some hints to track down the problem on myown, especially concerning the FreeBSD behaviour in case of free list shortage. Also, I would appreciate to know if my understanding of the figures I got from 'cnt' or of the scheduling behaviour with regard to kernel preemption is correct. I think this would be helpful for me to build the code sample you are requesting. > I do appreciate your mini-kernel debug howto, I've got it saved > for future reference. I am sincerely happy that I could provide something helpful ... Well, actually, it sounds that I did go to far to be able to retract myself, so I will let you know of any progress I will make asap ;-) Cheers, Xavier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 4:32:11 2001 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 5856D37B698 for ; Fri, 26 Jan 2001 04:31:54 -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 <01JZD56NU4WS00070O@research.kpn.com> for freebsd-hackers@FreeBSD.ORG; Fri, 26 Jan 2001 13:31:52 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jan 2001 13:31:51 +0100 Content-return: allowed Date: Fri, 26 Jan 2001 13:31:50 +0100 From: "Koster, K.J." Subject: RE: Kernel Hacking (i tried not to make it lame) To: "'skywizard@time.net.my'" Cc: freebsd-hackers@FreeBSD.ORG Message-id: <59063B5B4D98D311BC0D0001FA7E4522026D7B63@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 Ariff, > > I remembered porting back cd9660 to 2.2.x tree, and now look > forward porting softupdates (If anybody can give me some light > I really appreciate that). I'm reviewing sources from current, > stable and from other BSD project such OpenBSD to pick all > the good stuffs. > I'm a happy 2.2.x user. > I think Yahoo! is using still on 2.2.8. There are some people on this list who work for Yahoo!, so you could try to drop them a line. I can imagine that they are interested in softupdates. 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 Fri Jan 26 5:53: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from net-ninja.com (cc213180-a.plymr1.tn.home.com [65.8.203.28]) by hub.freebsd.org (Postfix) with ESMTP id 2AF7837B6A6 for ; Fri, 26 Jan 2001 05:52:47 -0800 (PST) Received: by net-ninja.com (Postfix, from userid 1000) id 7A2D16E989; Fri, 26 Jan 2001 08:51:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by net-ninja.com (Postfix) with ESMTP id 632DB176165; Fri, 26 Jan 2001 08:51:32 -0500 (EST) Date: Fri, 26 Jan 2001 08:51:32 -0500 (EST) From: Mike Wade X-Sender: mwade@net-ninja.com To: Greg Lehey Cc: hackers@FreeBSD.ORG Subject: Re: if_fxp driver info (which card then?) In-Reply-To: <20010126141808.D1222@wantadilla.lemis.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, 26 Jan 2001, Greg Lehey wrote: > Performance isn't even the main thing. As I said earlier, it's plain > bloody unreliable. Linux people avoid the EtherExpress because they > think something is wrong with the card. They were surprised when I > reported that it works without any problems under FreeBSD. Do we > really want to change that? Slightly off subject but with all the discussion about not Intel playing nicely with the FreeBSD developers... I've always had the best reliability, performance, and lower CPU usage with the Intel EtherExpress Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there better cards out there that I should be looking at? --- Mike Wade (mwade@cdc.net) Chief Technical Officer CDC Internet, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 6:48: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from federation.addy.com (federation.addy.com [208.11.142.20]) by hub.freebsd.org (Postfix) with ESMTP id 3B78737B401 for ; Fri, 26 Jan 2001 06:47:44 -0800 (PST) Received: from localhost (jim@localhost) by federation.addy.com (8.9.3/8.9.3) with ESMTP id JAA16791 for ; Fri, 26 Jan 2001 09:47:38 -0500 (EST) (envelope-from jim@federation.addy.com) Date: Fri, 26 Jan 2001 09:47:38 -0500 (EST) From: Jim Sander Cc: hackers@FreeBSD.ORG Subject: Re: if_fxp driver info (which card then?) 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 > > Linux people avoid the EtherExpress because they think something is > > wrong with the card. > Intel EtherExpress Pro 10/100B cards in FreeBSD These cards work well in our many 3.x and 4.x systems. But I just built up a Redhat 6.2 box with one, and all seemed to be working fine, but after a while I started having various problems starting net services. The box would boot, but often would "hang" indefinitely when "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro NIC, new MB, different RAM, other cables, everything, but no change. After I switched to a linksys NIC, voila- everything worked without a problem. (so far) Of course the Intel NICs still work perfectly when put into a spare BSD system. So it's *not* that the cards themselves are unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC conflict of some sort? -=Jim=- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 7: 2: 1 2001 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 AFDBE37B400 for ; Fri, 26 Jan 2001 07:01:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f0QF1fF25778; Fri, 26 Jan 2001 10:01:41 -0500 (EST) Date: Fri, 26 Jan 2001 10:01:41 -0500 (EST) From: Alwyn Goodloe To: Patrick Bihan-Faou Cc: freebsd-hackers@freebsd.org Subject: Re: Divert Sockets & Fragmentation revisited 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 Thanks for the suggestion I will give lsof a shot to see. I think the port binding is correct, otherwise I don't think it would work when datagrams aren't fragmented. Like I said the code works fine for datagrams < MTU ==> not fragmented but fails when they are. That being said it NEVER HURTS TO CHECK. Alwyn agoodloe@gradient.cis.upenn.edu On Fri, 26 Jan 2001, Patrick Bihan-Faou wrote: > Hi, > > Sorry to state something that is obvious, but when you bind your socket to > the port, you have the port in the correct (network) order ? > > i.e. do you use htons(DIVERTPort) ? > > If you have lsof installed, run it and look at the port number that your > program listens on. > > > > Patrick. > > > > Here is the important code fragments: > > > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make > some > > difference but to no avail. > > > > #define MAX_PACKET_SIZE 300000 > > #define DIVERTPort 4422 > > #define ACTIVE_UDP_PORT 3322 > > > > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > > sys_error("divert socket error"); > > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > > printf("Step 1 \n"); /* Register address and port with the system */ > > if (bind(divert_sock, (struct sockaddr*) > &server_divert,sizeof(server_divert)) < 0) > > sys_error("server_divert bind error"); > > for ( ; ; ) { > > > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > > ( struct sockaddr * ) &client_add,&clilen); > > > > > > > > > > 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 Jan 26 7:28: 7 2001 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 A20A137B401 for ; Fri, 26 Jan 2001 07:27:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f0QFRkF28061; Fri, 26 Jan 2001 10:27:46 -0500 (EST) Date: Fri, 26 Jan 2001 10:27:46 -0500 (EST) From: Alwyn Goodloe To: Patrick Bihan-Faou Cc: freebsd-hackers@freebsd.org Subject: Re: Divert Sockets & Fragmentation revisited 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 Having run lsof I can verify that the program IS reading on that port number. Has anyone else on the hacker list had problems with diverting fragmented datagrams?? Alwyn Goodloe agoodloe@gradient.cis.upenn.edu On Fri, 26 Jan 2001, Patrick Bihan-Faou wrote: > Hi, > > Sorry to state something that is obvious, but when you bind your socket to > the port, you have the port in the correct (network) order ? > > i.e. do you use htons(DIVERTPort) ? > > If you have lsof installed, run it and look at the port number that your > program listens on. > > > > Patrick. > > > > Here is the important code fragments: > > > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make > some > > difference but to no avail. > > > > #define MAX_PACKET_SIZE 300000 > > #define DIVERTPort 4422 > > #define ACTIVE_UDP_PORT 3322 > > > > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > > sys_error("divert socket error"); > > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > > printf("Step 1 \n"); /* Register address and port with the system */ > > if (bind(divert_sock, (struct sockaddr*) > &server_divert,sizeof(server_divert)) < 0) > > sys_error("server_divert bind error"); > > for ( ; ; ) { > > > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > > ( struct sockaddr * ) &client_add,&clilen); > > > > > > > > > > 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 Jan 26 7:38:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from 1upmc-msx1.isdip.upmc.edu (1upmc-msx1.isdip.upmc.edu [128.147.16.38]) by hub.freebsd.org (Postfix) with ESMTP id 83F7A37B400 for ; Fri, 26 Jan 2001 07:37:53 -0800 (PST) Received: by 1upmc-msx1.isdip.upmc.edu with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 10:38:29 -0500 Message-ID: From: "Person, Roderick" To: freebsd-hackers@freebsd.org Subject: gpc Pascal Compiler from FreeBSD Date: Fri, 26 Jan 2001 10:38:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C087AE.06D6891A" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C087AE.06D6891A Content-Type: text/plain; charset="iso-8859-1" Is anyone using this? I can seem to get the compiler to find any of the units. I have set the GPC_INCLUDE_DIR to where the units are but still no luck. Roderick P. Person Programmer II personrp@ccbh.com "I'm not indecisive. Am I indecisive?" - Jim Scheibel, mayor of St. Paul Minnesota ------_=_NextPart_001_01C087AE.06D6891A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable gpc Pascal Compiler from FreeBSD

Is anyone using this?

I can seem to get the compiler to find any of the = units. I have set the GPC_INCLUDE_DIR to where the units are but still = no luck.

Roderick P. Person
Programmer II
personrp@ccbh.com


"I'm not indecisive. Am I = indecisive?"

        - Jim = Scheibel, mayor of St. Paul Minnesota

------_=_NextPart_001_01C087AE.06D6891A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 8:44: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id 5828D37B404 for ; Fri, 26 Jan 2001 08:43:50 -0800 (PST) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id TAA07260; Fri, 26 Jan 2001 19:43:11 +0300 (MSK) Message-Id: <200101261643.TAA07260@aaz.links.ru> Subject: Re: if_fxp driver info (which card then?) In-Reply-To: from "Mike Wade" at "Jan 26, 1 08:51:32 am" To: mwade@cdc.net (Mike Wade) Date: Fri, 26 Jan 2001 19:43:10 +0300 (MSK) Cc: grog@lemis.com, hackers@FreeBSD.ORG From: "Aleksandr A.Babaylov" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Wade writes: > On Fri, 26 Jan 2001, Greg Lehey wrote: > > Performance isn't even the main thing. As I said earlier, it's plain > > bloody unreliable. Linux people avoid the EtherExpress because they > > think something is wrong with the card. They were surprised when I > > reported that it works without any problems under FreeBSD. Do we > > really want to change that? > Slightly off subject but with all the discussion about not Intel playing > nicely with the FreeBSD developers... I've always had the best > reliability, performance, and lower CPU usage with the Intel EtherExpress > Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there > better cards out there that I should be looking at? 3C905 -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 9:11:28 2001 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 9854A37B401 for ; Fri, 26 Jan 2001 09:11:07 -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 MAA78062; Fri, 26 Jan 2001 12:13:34 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010126120015.0228fc90@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 26 Jan 2001 12:20:25 -0500 To: Mike Wade , Greg Lehey From: Dennis Subject: Re: if_fxp driver info (which card then?) Cc: hackers@FreeBSD.ORG In-Reply-To: References: <20010126141808.D1222@wantadilla.lemis.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 08:51 AM 01/26/2001, Mike Wade wrote: >On Fri, 26 Jan 2001, Greg Lehey wrote: > > > Performance isn't even the main thing. As I said earlier, it's plain > > bloody unreliable. Linux people avoid the EtherExpress because they > > think something is wrong with the card. They were surprised when I > > reported that it works without any problems under FreeBSD. Do we > > really want to change that? > >Slightly off subject but with all the discussion about not Intel playing >nicely with the FreeBSD developers... I've always had the best >reliability, performance, and lower CPU usage with the Intel EtherExpress >Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there >better cards out there that I should be looking at? Why dont some people get the point even when you hit them in the head with a hammer? The point is that the driver quality is more important than the "card" To get completely off base, this is which is why we SELL our software. Implementation technique is usually more decisive in determining functionality and performance than the hardware itself. its something that people in the know are willing to pay for (sometimes). Certainly some hardware is better than others, but a bad driver with good hardware is useless. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 9:13:35 2001 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 130A637B698 for ; Fri, 26 Jan 2001 09:13:15 -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 MAA78078; Fri, 26 Jan 2001 12:15:55 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010126122046.022922f0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 26 Jan 2001 12:22:46 -0500 To: Jim Sander From: Dennis Subject: Re: if_fxp driver info (which card then?) Cc: hackers@FreeBSD.ORG In-Reply-To: References: 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 09:47 AM 01/26/2001, Jim Sander wrote: > > > Linux people avoid the EtherExpress because they think something is > > > wrong with the card. > > > Intel EtherExpress Pro 10/100B cards in FreeBSD > > These cards work well in our many 3.x and 4.x systems. > > But I just built up a Redhat 6.2 box with one, and all seemed to be >working fine, but after a while I started having various problems starting >net services. The box would boot, but often would "hang" indefinitely when >"Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro >NIC, new MB, different RAM, other cables, everything, but no change. the eepro100 driver is badly broken in linux (havent you been paying attention?). it took me a few hours to fix it. They dont reset the card properly on an overrun, which causes it to lock up. Clearly the driver as is is unusable in a heavy use environment. DB > After I switched to a linksys NIC, voila- everything worked without a >problem. (so far) Of course the Intel NICs still work perfectly when put >into a spare BSD system. So it's *not* that the cards themselves are >unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC >conflict of some sort? > >-=Jim=- > > > >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 Jan 26 9:16:33 2001 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 B7A5637B698 for ; Fri, 26 Jan 2001 09:16:14 -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 MAA78094; Fri, 26 Jan 2001 12:18:40 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010126122411.02291430@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 26 Jan 2001 12:25:32 -0500 To: "Aleksandr A.Babaylov" , mwade@cdc.net (Mike Wade) From: Dennis Subject: Re: if_fxp driver info (which card then?) Cc: hackers@FreeBSD.ORG In-Reply-To: <200101261643.TAA07260@aaz.links.ru> References: 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 11:43 AM 01/26/2001, Aleksandr A.Babaylov wrote: >Mike Wade writes: > > On Fri, 26 Jan 2001, Greg Lehey wrote: > > > Performance isn't even the main thing. As I said earlier, it's plain > > > bloody unreliable. Linux people avoid the EtherExpress because they > > > think something is wrong with the card. They were surprised when I > > > reported that it works without any problems under FreeBSD. Do we > > > really want to change that? > > Slightly off subject but with all the discussion about not Intel playing > > nicely with the FreeBSD developers... I've always had the best > > reliability, performance, and lower CPU usage with the Intel EtherExpress > > Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there > > better cards out there that I should be looking at? >3C905 I disagree. The if_fxp driver is far superior to the if_xl driver. In other OS's your mileage may vary. DB >-- >@BABOLO http://links.ru/ > > >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 Jan 26 10:20:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id C2E6E37B402 for ; Fri, 26 Jan 2001 10:20:18 -0800 (PST) Received: by smtp.nettoll.com; Fri, 26 Jan 2001 19:19:14 +0100 (MET) Message-Id: <4.3.0.20010126193228.06e2a200@bluesun> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 26 Jan 2001 19:32:34 +0100 To: hackers@FreeBSD.ORG From: mouss Subject: [kernel patch] fcntl(...) to close many descriptors 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 Hi, I've modified the kerenl to add F_CLOSEM functionality to fcntl. (I've seen this in some AIX docs). The purpose is allow a process to close all its filedescriptors starting from a given value without issuing thousands of close() syscalls. This may be used for programs that daemonize themselves (or one of their children) after some amount of work, when many fd's has been opened. The program would simply call fcntl(minclose, F_CLOSEM, 0); The patch concerns /sys/kern/kern_descriptors.c and fcntl.h (and of course the corresponding manpage). Is this functionality worth inclusion in the kernel (or should I throw away the patch)? are there any kind souls to review the patch? cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 10:34: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B93BC37B401 for ; Fri, 26 Jan 2001 10:33:47 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0QIXi434137; Fri, 26 Jan 2001 10:33:44 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Jan 2001 10:33:44 -0800 (PST) From: Matt Dillon Message-Id: <200101261833.f0QIXi434137@earth.backplane.com> To: mouss Cc: hackers@FreeBSD.ORG Subject: Re: [kernel patch] fcntl(...) to close many descriptors References: <4.3.0.20010126193228.06e2a200@bluesun> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think it is worth doing. A quick google search shows that the linux folks discussed the AIX thingy in March 1999, but I don't think they actually implemented. From the discussion, it appears that the fcntl would be useful and (not having seen your patches), almost certainly trivial to implement. -Matt :Hi, : :I've modified the kerenl to add F_CLOSEM functionality to fcntl. :(I've seen this in some AIX docs). : :The purpose is allow a process to close all its filedescriptors starting :from a given value without issuing thousands of close() syscalls. :This may be used for programs that daemonize themselves (or one of :their children) after some amount of work, when many fd's has been :opened. The program would simply call : fcntl(minclose, F_CLOSEM, 0); : :The patch concerns /sys/kern/kern_descriptors.c and fcntl.h :(and of course the corresponding manpage). : :Is this functionality worth inclusion in the kernel (or should I throw :away the patch)? are there any kind souls to review the patch? : :cheers, :mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 10:37: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 305BD37B698 for ; Fri, 26 Jan 2001 10:36:42 -0800 (PST) Received: by smtp.nettoll.com; Fri, 26 Jan 2001 19:35:10 +0100 (MET) Message-ID: <3A71C39F.8060109@enition.com> Date: Fri, 26 Jan 2001 19:36:15 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel memory allocation bug ... References: <200101191524.f0JFOtk14877@mobile.wemm.org> <3A6861DF.8060108@enition.com> <3A706788.5040509@enition.com> <20010125101659.N26076@fw.wintelcom.net> <3A707211.2080801@enition.com> <20010125114602.Q26076@fw.wintelcom.net> <3A7151D5.2040405@enition.com> Content-Type: multipart/mixed; boundary="------------010304000009040600000002" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------010304000009040600000002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Xavier Galleri wrote: [...] >> You've been complaining about this problem for at least a week. >> Producing some code so that we can test couldn't take more than a >> couple of hours and would have probably had your issue resolved >> by now. >> >> This is why I'm irritated that you still haven't provided any code >> to reproduce it. > [...] > Well, actually, it sounds that I did go to far to be able to retract > myself, so I will let you know of any progress I will make asap ;-) Ok, I'm back again ;-) and this time, I got something for you ... Basically, what I did, is to write a little SYSCALL kld module to allow controlling calls to MALLOC/FREE from user space. This way, I can issue some filesystem-intensive command (tar something-bigger-than-memory-size) in order to create the free list shortage. Then, I use my test program to issue several MALLOC in kernel space. What I actually noticed is that, when the free list felt below 120 or alike, I can issue several thousands successful MALLOC as long as the asked size is no more than one or a few pages. But, when I ask for numerous pages (32Kb), then the process is falling asleep (this is analysed with my manual stack analysis process ;-), whilst the M_NOWAIT flag has been set (of course !). Everything is almost entirely self-documented in the attached kmem.tar.gz file. I hope this will help and I am eager to hear from you soon. Have a nice WE, Regards Xavier --------------010304000009040600000002 Content-Type: application/gzip; name="kmem.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="kmem.tar.gz" H4sICEe+cToCA2ttZW0udGFyAO0ba1PbSJKv6Ff0kk2wWGH0sGUb1tkj4Gxxy+MKwt5tJZRL lkZGZ0vySbLBl/Dfr3tmZMsPSMgu3D6sCrKmp2emp9/TUnohC3fWnvaCil6rVmHNsKtGtSJ+ K/gLk0sHqJlWxTLtionPhmFatTWorj3DNUwzJwFYu+06/T5LgvvwEifyvLU/3dUj+Z/88q51 8W7ndyD/Ckoe5W+atrmS/3PLPxxnLM3K7m+9hqHrdqVyr/zNij6Rv2XoNZR/Ra9U10Bfyf/J L+VFELn9ocfg+zTzgrh8/XoW1A86BCsCx+kO/rnIrzls7MjGA5YugsPYG/bZ3ETh2EtGHIYy yAIXgiiDcCznbkfDcO+eriAKMiiN4sBTlY8KQJolQxcR+CptGgJ02+NdTlYesSQN4giakAb/ ZbFfIqhK3TiEnkv46weRV9rgRG2o2qspSpEimoJm9JzMKSNRI6e/p9wpygx9UKKmG3oap5vW FE/9OB4IiqmVsEzMjyu2naSbtjOgH9w18IcyTgG4Iv7s5SCaTO5jAqNpEUY/fCxOTCiCmNIM /Rq8oiF8Y4EPJURVYcCSJE5o7xJzQ83nGSaRoDPfoxNEYns4jauBe+0kW/Q8en8ldjaM0qAb MY93EelNfU9uWDBiQuasPEtiTSKKpv7eUrFFEwIMEhztlzY6jkdLgRsPo+xDtMF3AcBucfS2 wVt3NIdkG6fKuHqvX3FFEIxzsjgo8R7zio+QzJvCrStBSXoTZO41lHC2KSmukzLYDDd3C62T mVZnpvVGtsTo6VYmey+d7B8fnx1oLz38p+KmtAKbBCF0FfB/OTg5bMtRS3GJhcSCZpMohU+f IG+dbKrQSZjTA8G5uwKl/iYUCX+bN++n/O15q6U+lnAatByTE1aky2O+M+xny8m4jHpRfBOh LoQhuuZdeOlyGkha9015V1Bqnau0svYXv4rx/8TpMT/os2eO/5ju1+biv1Wr1Vbx/1niv0j6 diFP/qBcRn04PP95R4ZnZd11YfsMtgfBgE3RtmP5DNtH+ZCVOf1R7Z/k/Xs4/1cMvUrnP8Oy V+e/Z5b/U7n/L/D/xpz8LcRf+f9n8f8X5wcXTeHqXeWnk7ND0VB+Omt++5Had+VerPx0fEhd maKUJ8e3TuqVe3huKoe91yvP/8e3fxnv157d/i19kv9VdNsk+6+aq/zvmeo/eMoKIgbFY+V6 Sb89bO0fqnO9dHajvjet1ltVUajWg/2T6sukjjGpcMjCRX72z59FBeButvKBh7bpaqiP7f3z Hy/ap2+gJGs2RWx1RwJxOlVdeZ/fzv7dZ7d/26SYP2f/q/rv89d/7y/fDpzECZeAk9h9qNa7 UDNmUbYI77EkYv2l+Fm4pPY8CkOWsWTJwijBZQTlZN5TeubOa+B2ttAfucMEn/ZyqFyKfvcU KjdvbQFZTGfoQ5NKSIXytCL8E24xGaPPktPi0lsw0EAOHjqF+m866w/FMy/FipLpfGGYl7Xc eDCmEuwWTiWKuVpe1MZnVQWONS3W4RS7nKZdXgXUb1/eilLoS0+UPl96vG6Gg8u8Yk0PojxH T9MSXV4OlYhzJdFi+LivbkikCBntTrj4cgCC5/T0/qV3xYmRvZrs06DdPj46bbXbs0VOiaZK 0EdlXXAPWkenP+8f7ynrhQKgLP/RlVJ1fNCPGC86Pw2ZefVTDmtCrlqiAzWKYFGWAwTr8i1p Ql+0XARbUsQcrGon7cPWz28u3+LD6dk/94/ePdk2FrndbOoFhi9f7+3+0fHleSufeRf8hHGN uwkS/uu4WTDiT0E0fXYd95pJhVTWOZPKozaNbfOSvyYhNMssRMwxC8tnnoXyNQQIt7eOanBb otchE9U5PTtpndyrOn6cQIkkgiYq7Of7iZ0IwHffFdhTEPP6rITfE+6VkLM2sbllglXWC9wX w7gM1j8Sj75IACTqrxEC3xAXxbMIA2AqDoB5gUzK+et381IpmJmei2wy1YOWcXF5cNC6uChY yFfxKTchLvEnZtN9r0sKfpgS9Ye8MJFX9ArFPcwa/Tdf62MfaSgLKq4CbaJUch3PSzDhnzWb 3E7UhXWXjtKgMOABjvxxtaGQlcAj36gJeebi/OyLM47OX57J3EemOiK9k0mLbDR5rmNoeKOT WmlLnUmMZFqESUshd8Jz4exr/9j3U/5C+/SsffHLxQG60WWJVz92vEneJXLQLfrVYPIynq/G X5lPk7BJvjVJcZa88D05O2wfn+0fPmRTtP4uEBbQ606GDUm51ArRUvcetl9c6fL0y9YSeF+5 2m+rClIubST/8rgljuraK0GD9qqoE9pUWtrp5fExqfDqGP7/Pf+ft/YPT1pPtsbD53/DpJdD 4vxv1XTb4N//VY3V+f9Zzv/vMGyRM2ZpClmMlo0Nb+gyyERHp89CCFJwUgzpmDPdpLuKYmB0 DpKUfDMg29DFpulQDNkMnR7bzD/LSGEYeXiA5hUmQACIbw1gb1tVFFOFo4wmH6bMH/Zx/Zho uImTHobb7BocEMUBnNnJ4Bpp8Fhn2IV4kAVxlJJTmqErrygTDRKHmoetN5c/Nre7k/5CH+8/ fKMolgp/R2UAx6cTfxChXvT7QdTlu/JYihHby8mhjSSsE8dZjhBiUA4iRpGuwAxBGeHk/EAi X0Ov7/FoVay79WLsmPkQEzpQ0Rs2GLpZUWDx2vnAb8u6Pn3ityVd/OjP07G5q+T6ZRSefL2/ CfQmUJUcff/uGoV0E/T74AWYVztjSOOQ5WILUXecLkOewc7ISXb6cXdHwlINWDpgboC8HEty Nigd2iDBcX0ppke0LOt7pFabLjVnpCsrRbuwpKrhMeQn3xznGd8hZ9zcoPkTsZ4fiPVbt+6a DV3X4b1lX33VuEr18+NuXd2vMUJfNkHj3gnmU9PpRDJFNa26URVZqlWr6nmeathWY5qpmkat JnNVw3iQoR1Glf3PM3T2KDGlajneU+wC7YZc+K2PK213gu42qW6Ze/XZ6wXgmcSJxhCj4iVc w6nGyMJtzK1YlNLU0k41rpvd2OlDh3Ebf9A855ZxMWXKpAegTfUDRE+v4yQjMymXy8rC5380 lUZTqcr8B3aFrtd/GiMwrN/ICOREUn0MUxfKU7XsBkzURbcLymPqZiPXnppdfxorkGR9sRX8 +m3AV107nz585Uj49MiBS0zhmx++Ub7Arl6ACECYF2A8oDALbMQiDLpozFmAseZXGdXC+paJ DBVyXpiT94mRM8ThnoYYuaI4y09HmMmk1wxjJmZR4SDjJCo4aj9Dz0AjiAUaHKGbIVzyFi4m JXGfUbObOB0Ow+Qkn4HSDpFcOBy8OXCiwJ0kWzh9Fafn+YsbJwlzM5ml8JEyd3ETJ70GbxgO hJ+i7+I7Y9hMnRHDUWyTSKKkOOPpFWx2vQ5s9zYhxZBOyDwXc3hQxtDPaWWZIF8Yc0yeeJpU XifxsHtNk/FMiham+B6mXdT9wVyML/VwORUGsCX7lW8NPPp/xFY7dLp44m+ielRt3dSAYPKr bpRKpS4gOOgWIbZp2BNAgoBqTa9RekagQUYQCj513SKns3EQD8ZJ0L3OMBFSwWg0zG2TOig9 fouK++biEP6RxP9GnpY/RPPYtYaG97rO7xa/2/xe53fe2zD43eR3jtOofIg+ZLTCOeui20mJ L8Sjyyjg/2MhGxPkwOkHfpxEgVOGfVQnvnCKkk1ZMmIekpMTWCkb2+et4w3UtLuck7ewkxZ2 +h2xgbamCFilWrd2ZV6GbsT8ED0YV4RlTNxgjv2lAeVR+BhI7sX/XAD5EBETptq0cwtbpVLh XZ86HaAq35qkYghuu4nFFcN0PB+7NMJtMy/gQF9eEpoKqFs3GDIox+0MJNQ1Haa7OW4BijPn uLccmjcDiaQbDVs3KgLqJbpEUt7jlq7yPQWRH6NLddACp6sVRisXmeP2JAYa7BRpV4H5pSh1 D4N2/oqvXN7Bf+Qv+K2djiP3uuzu1qt1dQ/IUXh8CjFBtdapKrIKRZ5kYUmr/lnSrXpxMsIG ltG3yDiKPMdRJIKGJlxnHxUyzZ3m9JCV8i2Th5l6kodY9EKH4rZVIvqBvSv4xy3lPhw4RZc/ xKkotaRk0wvICcfJuLycnNltEzlZ2mdsAKXAQwtschv1DJ2RiiRBnKBLaKJi3GDI6/Jey/J9 y4CNURgPnGRDo3AYN/UHt1KxGwr+iRp/dB/acoptnVNsNhq+aXGKR2E77pBfbA8wnrUTFsaY npQETNDYqFrkG3lQaVatWg3jd+ThU72qgYvCjNpx1B/PkD0K8R+fsny9W63UFPwrMH+m+9F8 b7hyF3bFtvNdhM6g7bE+w8y9hM856Zho5aRbZsVE1eFOnDZAbdNs1OxFwnEC5LRRN3SFbvOE i+5H0+3WJd0Vu+NzuskjtoV7XEI1uuymSFjA7zvdtGksEEoiR1Is5AP+LXBYdj+aUl9qdp1Z Xo1TOm1ybyNJLpJIH58I+u1KnRzqIs1TLZUfexCP68ji5YY5QXos/b7pyrOpj+F7Qr9oEv0/ /ID+YvlQR5oIczp2dTJUNGmoTChNKPFxzY+Z3/bpk4QK2gU+s8KzV4TzMJTzypcBaNvQa7WG VTPMuiYTcurjYSjvwyF8RMDD0HbDtGt21aDwxlEpClE0l6vczq7i8m6rUjXoP2cLmEMwPI/w VpY4gygmJLNIQUIplinwebixa4atV7j1I8ylnVmG6OeCJpRqQ26tSL5lCPJTwYw78dpwohOB VbfFjSghjTBMW6HbVCUWcB6hEB2/4/udekWI0es4tYJUeZOk+q8gyvTbut6e/B9QUT0ThwPG QszYHF53SIMw6DsJr3RSKk0HgIzbxJgy+QH3QPwkwqJRkMRRSK/S+OlhP+IooUgWE/jPENEo J3fwrHjD+m7ME/JdyKvZf2NRQAhl7Fm9Z1ldq2t1ra7VtbpW1+paXatrda2uv/D1P0dA6cYA UAAA --------------010304000009040600000002-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 10:43:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 0081F37B401 for ; Fri, 26 Jan 2001 10:43:05 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA67365; Fri, 26 Jan 2001 10:43:00 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id KAA09789; Fri, 26 Jan 2001 10:43:00 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101261843.KAA09789@curve.dellroad.org> Subject: Re: Divert Sockets & Fragmentation revisited In-Reply-To: "from Alwyn Goodloe at Jan 25, 2001 10:59:27 pm" To: Alwyn Goodloe Date: Fri, 26 Jan 2001 10:43:00 -0800 (PST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alwyn Goodloe writes: > Guys still having problems with divert sockets and fragmentation. > > As I said in a previous post the divert operations and corresponding program > work fine when the datagram sent have size < MTU (1500) but when the > datagram has size > MTU and hence get fragmented the recfrom just > waits never receiving anything. I am attaching the relevent code > fragments below. > > tcpdump tells me that the packets arrive on the interface. > Hence I know the fragments arrive. > > Now my ipfw commands are: > > ipfw add 60000 divert 4422 udp from any to any 3322 in > ipfw add 65000 allow ip from any to any I think the problem is that the first fragment is matching your rule, but not subsequent fragments (because the port number is only contained in the first fragment..) > Now I thought that that maybe the divert being so specific was > a problem so I tried flushing ipfw and using the command: > ipfw add 60000 divert 4422 ip from any to any > > thus diverting any ip packets and still nothing. That doesn't make sense.. Try adding the "log" keyword to your ipfw commands, or checking the stats with "ipfw show" so you can see exactly what's being diverted. > Now according to the man page on divert: > > Incomming packets which get diverted are fully reassembled before > delivery of any one fragment. Diversion of any one packet causes > the entire packet to get diverted. I different fragments get > diverted to different ports, then which port ultimately gets > diverted is unpredictable. > > I was under the impression that the packets wern't reassemblembed before > diversion. Am I wrong here? Yes... but all fragments must match. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 11:13:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 5939637B400 for ; Fri, 26 Jan 2001 11:13:02 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f0QJCx101741; Fri, 26 Jan 2001 11:12:59 -0800 (PST) Date: Fri, 26 Jan 2001 11:12:59 -0800 (PST) From: Doug White To: Kevin Mills Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads and kqueue In-Reply-To: <857l3jv8je.fsf@diablo.in.a6l.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 25 Jan 2001, Kevin Mills wrote: > Well, there are wrappers in the libc_r code (libc_r/uthread/uthread_kevent.c) > and I seem to recall posts on -stable saying that kqueue could now be used > with user threads (around the 4.1.1 time frame, I think). I could be wrong :) > > This seems like a strange way to implement your solution, though ... from > > the sounds of it, you can only have one concurrent connection to your > > authentication server via this library, which sounds extremely lame. Do > > the clients just sit around forever until the server returns? The > > serialization this library forces isn't too scalable. > > The library is reentrant and will allow different threads to call into > it (there isn't a mutex serializing the entry point or anything like that). > However, the call to the backend is done with a blocking call. The > communication with the backend is generally very quick. However, if the > backend gets too busy I want to make sure I don't starve the other connections. > A thread pool seemed the best way to tackle this. I'd be very open to other > suggestions if you have any! Also, your proprietary library has to be threadsafe too. Particularly if it blocks... it'll probably block the whole process instead of the individual thread. Unless we figured out a way to fix that :) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 11:19:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 364DD37B400 for ; Fri, 26 Jan 2001 11:19:17 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f0QJJEC02103; Fri, 26 Jan 2001 11:19:14 -0800 (PST) Date: Fri, 26 Jan 2001 11:19:14 -0800 (PST) From: Doug White To: Delanet Administration Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NFS server out of mbuf's? In-Reply-To: <3A7096AA.68FBBA90@delanet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Jan 2001, Delanet Administration wrote: > I run a FreeBSD 3.2s nfs server which recently crashed with a panic 'Out > of mbuf clusters'. I found this odd since the normal peak is always > below 200 and I compiled the kernel with users at 256 (4608 max mbufs). > The server had an uptime of 118 days prior to this crash, and has no > entries in the logs out of the norm up until this crash. Just curious if > anyone knows of any reason this would happen? The server has no other > use at all..no one even logs into it except me on occasion to go over > logs and such. Sudden network outages during periods of high activity will cause mbuf cluser consumption to increase. 'netstat -m' is your friend. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 11:37:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 03B2A37B404 for ; Fri, 26 Jan 2001 11:37:32 -0800 (PST) Received: by smtp.nettoll.com; Fri, 26 Jan 2001 20:36:20 +0100 (MET) Message-Id: <4.3.0.20010126204903.06d58910@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 26 Jan 2001 20:49:40 +0100 To: Matt Dillon From: mouss Subject: Re: [kernel patch] fcntl(...) to close many descriptors Cc: hackers@FreeBSD.ORG In-Reply-To: <200101261833.f0QIXi434137@earth.backplane.com> References: <4.3.0.20010126193228.06e2a200@bluesun> 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:33 26/01/01 -0800, Matt Dillon wrote: > I think it is worth doing. A quick google search shows that > the linux folks discussed the AIX thingy in March 1999, but > I don't think they actually implemented. From the discussion, > it appears that the fcntl would be useful and (not having seen > your patches), almost certainly trivial to implement. you're right. (I can resend it as a tar file...) *** kern_descrip.c Fri Jan 26 19:42:18 2001 --- kern_descrip.c.new Fri Jan 26 20:24:07 2001 *************** *** 364,369 **** --- 364,387 ---- (caddr_t)(intptr_t)uap->arg, sizeof(fl)); } return(error); + + /* close all descriptors starting from a given value */ + case F_CLOSEM: + { + i = uap->fd; + + p->p_retval[0] = 0; + if ((unsigned)i >= fdp->fd_nfiles) { + return (EBADF); + } + for (; i<=fdp->fd_lastfile; i++) { + struct close_args uap; /* XXX. requires _SYS_SYSPROTO_H_ */ + uap.fd = i; + close(p, &uap); + } + return 0; + } + default: return (EINVAL); } The F_CLOSEM is added to fcntl.diff *** fcntl.h Fri Jan 26 20:24:45 2001 --- fcntl.h.new Fri Jan 26 20:25:39 2001 *************** *** 156,161 **** --- 156,162 ---- #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW 9 /* F_SETLK; wait if blocked */ + #define F_CLOSEM 10 /* close open fd's larger >= arg */ /* file descriptor flags (F_GETFD, F_SETFD) */ #define FD_CLOEXEC 1 /* close-on-exec flag */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 11:49:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 8BA0837B402 for ; Fri, 26 Jan 2001 11:49:01 -0800 (PST) Received: by smtp.nettoll.com; Fri, 26 Jan 2001 20:47:34 +0100 (MET) Message-Id: <4.3.0.20010126202555.06e24350@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 26 Jan 2001 21:00:54 +0100 To: Archie Cobbs , Alwyn Goodloe From: mouss Subject: packet redirection design problem [Divert Sockets & Fragmentation revisited] Cc: hackers@FreeBSD.ORG In-Reply-To: <200101261843.KAA09789@curve.dellroad.org> References: 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 "IP filtering engines" that do something to packet based on rule matching have a problem when fragmentation comes to play. In the case of a "packet redirector' such as divert, the problem is that only the first fragment will match the rule, if the rule uses ports or whatever info contained in the payload. The problem occurs if the packet (that should match) is subject to change by the engine (either redirection, nat, blocking, ...) IP Filter handles such situation with specific code. It would be a nice thing if this is added to standard code so that packet filters writers do not need to add their own. Any opinions? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 12: 0:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B04AC37B401 for ; Fri, 26 Jan 2001 12:00:30 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0QK0HJ35675; Fri, 26 Jan 2001 12:00:17 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Jan 2001 12:00:17 -0800 (PST) From: Matt Dillon Message-Id: <200101262000.f0QK0HJ35675@earth.backplane.com> To: mouss Cc: hackers@FreeBSD.ORG Subject: Re: [kernel patch] fcntl(...) to close many descriptors References: <4.3.0.20010126193228.06e2a200@bluesun> <4.3.0.20010126204903.06d58910@pop.free.fr> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :At 10:33 26/01/01 -0800, Matt Dillon wrote: :> I think it is worth doing. A quick google search shows that :> the linux folks discussed the AIX thingy in March 1999, but :> I don't think they actually implemented. From the discussion, :> it appears that the fcntl would be useful and (not having seen :> your patches), almost certainly trivial to implement. : : :you're right. (I can resend it as a tar file...) : : :*** kern_descrip.c Fri Jan 26 19:42:18 2001 :--- kern_descrip.c.new Fri Jan 26 20:24:07 2001 :... Yah, something like that. You can test whether the descriptor is valid before calling close() on it, which should make it a lot faster. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 12: 8:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mh-a05.dmz.another.com (www.funmail.co.uk [212.62.7.9]) by hub.freebsd.org (Postfix) with SMTP id BA2C737B404 for ; Fri, 26 Jan 2001 12:07:31 -0800 (PST) Received: (qmail 31844 invoked from network); 26 Jan 2001 20:00:36 -0000 Received: from ad-a02.backend.another.com (HELO ad-a02.dmz.another.com) (172.16.100.15) by mh-a05.dmz.another.com with SMTP; 26 Jan 2001 20:00:36 -0000 Message-ID: <-253653191.980539550384.JavaMail.root@ad-a02.dmz.another.com> Date: Fri, 26 Jan 2001 20:05:50 +0000 (GMT+00:00) From: postmaster@another.com To: hackers@FreeBSD.ORG Subject: Your message has been bounced by another.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=-433746122.980539550302.JavaMail.root.ad-a02.dmz.another.com X-Another-Bounce: The mail has passed through the Bounce module. X-Funmail-UID: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ---433746122.980539550302.JavaMail.root.ad-a02.dmz.another.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, this is an automated message from another.com. We have tried to send your email to the address below, but we cannot find a user with that address. Please check the address of the person you are emailing and try again. moneytalks@showmethemoney.co.uk If you need further help, email us at support@another.com and a real, live human being will be happy to assist you. If you want to open your own another.com account then go to http://www.another.com/ Thanks, The another.crew ---433746122.980539550302.JavaMail.root.ad-a02.dmz.another.com Content-Type: message/rfc822 X-FunMail-size: 65807 X-Envelope-To: moneytalks@showmethemoney.co.uk Received: (qmail 9718 invoked from network); 26 Jan 2001 20:00:18 -0000 Received: from mx1.freebsd.org (216.136.204.125) by qm-a02 with SMTP; 26 Jan 2001 20:00:18 -0000 Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18])by mx1.FreeBSD.org (Postfix) with ESMTPid 1BC136E26EA; Fri, 26 Jan 2001 12:01:06 -0800 (PST) Received: by hub.freebsd.org (Postfix, from userid 538)id 7702B37B404; Fri, 26 Jan 2001 12:01:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org (Postfix) with SMTPid 645F52E8193; Fri, 26 Jan 2001 12:01:05 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Fri, 26 Jan 2001 12:01:05 -0800 From: owner-freebsd-hackers-digest@FreeBSD.ORG (freebsd-hackers-digest) To: freebsd-hackers-digest@FreeBSD.ORG Subject: freebsd-hackers-digest V5 #20 Reply-To: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers-digest@FreeBSD.ORG Precedence: bulk Message-ID: Date: Fri, 26 Jan 2001 12:01:05 -0800 (PST) freebsd-hackers-digest Friday, January 26 2001 Volume 05 : Number 020 In this issue: SYSINIT for userland? RE: SYSINIT for userland? Re: SYSINIT for userland? RE: SYSINIT for userland? Re: SYSINIT for userland? Re: SYSINIT for userland? NFS server out of mbuf's? Re: if_fxp driver info resource overheads 3ware ATA RAID 3DM management utility available Kernel Hacking (i tried not to make it lame) Re: if_fxp driver info Divert Sockets & Fragmentation revisited Re: Kernel Hacking (i tried not to make it lame) Re: Kernel Hacking (i tried not to make it lame) Re: Divert Sockets & Fragmentation revisited Re: Kernel Hacking (i tried not to make it lame) Re: Kernel Hacking (i tried not to make it lame) Re: FreeBSD Linux emulation / arla 0.34.6 Re: Kernel memory allocation bug ... RE: Kernel Hacking (i tried not to make it lame) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: Divert Sockets & Fragmentation revisited Re: Divert Sockets & Fragmentation revisited gpc Pascal Compiler from FreeBSD Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) Re: if_fxp driver info (which card then?) [kernel patch] fcntl(...) to close many descriptors Re: [kernel patch] fcntl(...) to close many descriptors Re: Kernel memory allocation bug ... Re: Divert Sockets & Fragmentation revisited Re: pthreads and kqueue Re: NFS server out of mbuf's? Re: [kernel patch] fcntl(...) to close many descriptors packet redirection design problem [Divert Sockets & Fragmentation revisited] Re: [kernel patch] fcntl(...) to close many descriptors ---------------------------------------------------------------------- Date: Thu, 25 Jan 2001 11:52:53 -0800 From: Alfred Perlstein Subject: SYSINIT for userland? Has anyone done any work for FreeBSD or GNU C that allows for SYSINITs in userland, meaning just having to specify a function and arg to be called at a certain time during program startup? I know you can do some evil magic with overloading special shared object symbols, but it is evil magic. :) Anyone know of another OS that supports this? Any standards for it on the way? - -- - -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 ------------------------------ Date: Thu, 25 Jan 2001 12:07:54 -0800 (PST) From: John Baldwin Subject: RE: SYSINIT for userland? On 25-Jan-01 Alfred Perlstein wrote: > Has anyone done any work for FreeBSD or GNU C that allows for > SYSINITs in userland, meaning just having to specify a function > and arg to be called at a certain time during program startup? > > I know you can do some evil magic with overloading special shared > object symbols, but it is evil magic. :) > > Anyone know of another OS that supports this? Any standards for > it on the way? Use C++ with static instances of classes that have constructors. - -- 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 ------------------------------ Date: Thu, 25 Jan 2001 12:16:07 -0800 From: Alfred Perlstein Subject: Re: SYSINIT for userland? * John Baldwin [010125 12:09] wrote: > > On 25-Jan-01 Alfred Perlstein wrote: > > Has anyone done any work for FreeBSD or GNU C that allows for > > SYSINITs in userland, meaning just having to specify a function > > and arg to be called at a certain time during program startup? > > > > I know you can do some evil magic with overloading special shared > > object symbols, but it is evil magic. :) > > > > Anyone know of another OS that supports this? Any standards for > > it on the way? > > Use C++ with static instances of classes that have constructors. I've got a pretty good idea of how it could be done in C++. Have a global list that each object adds itself to in sorted order (via static constructor), the manipulation should be serialized, but this still isn't a solution for C. - -- - -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 ------------------------------ Date: Thu, 25 Jan 2001 15:16:09 -0500 (EST) From: "Alexander N. Kabaev" Subject: RE: SYSINIT for userland? Will functions marked with __attribute__((__constructor__)) or __attribute__((__destructor__)) satisfy your needs? Compiler will insert calls to these functions gets into .init section of the resulting ELF module which in turn will be called automatically at the program startup time. I do not remember exactly, but there might be even priority parameter you can specify with these attributes to manage the order in which these functions will be called. On 25-Jan-2001 Alfred Perlstein wrote: > Has anyone done any work for FreeBSD or GNU C that allows for > SYSINITs in userland, meaning just having to specify a function > and arg to be called at a certain time during program startup? > > I know you can do some evil magic with overloading special shared > object symbols, but it is evil magic. :) > > Anyone know of another OS that supports this? Any standards for > it on the way? > > -- > -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 - ---------------------------------- E-Mail: Alexander N. Kabaev Date: 25-Jan-2001 Time: 15:10:40 - ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 12:19:59 -0800 From: Alfred Perlstein Subject: Re: SYSINIT for userland? * Alexander N. Kabaev [010125 12:16] wrote: > Will functions marked with __attribute__((__constructor__)) or > __attribute__((__destructor__)) satisfy your needs? > Compiler will insert calls to these functions gets into .init section of the > resulting ELF module which in turn will be called automatically at the program > startup time. I do not remember exactly, but there might be even priority > parameter you can specify with these attributes to manage the order in which > these functions will be called. Actually, the order can be kludged by just having these __constructors__ sort themselves into a list. Then all you need is a function call in main() to actually start these puppies up. :) It's still a bit off what I was looking for which would be putting these hooks into shared libaries hinged on pthread initialization, dns init, etc... - -- - -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 ------------------------------ Date: Thu, 25 Jan 2001 12:50:13 -0800 From: Mike Smith Subject: Re: SYSINIT for userland? > * Alexander N. Kabaev [010125 12:16] wrote: > > Will functions marked with __attribute__((__constructor__)) or > > __attribute__((__destructor__)) satisfy your needs? > > Compiler will insert calls to these functions gets into .init section of the > > resulting ELF module which in turn will be called automatically at the program > > startup time. I do not remember exactly, but there might be even priority > > parameter you can specify with these attributes to manage the order in which > > these functions will be called. > > Actually, the order can be kludged by just having these __constructors__ > sort themselves into a list. Then all you need is a function call > in main() to actually start these puppies up. :) > > It's still a bit off what I was looking for which would be putting > these hooks into shared libaries hinged on pthread initialization, > dns init, etc... You can actually do almost all of this with the ELF evilness that the loader uses (on i386) for doing its version of sysinits. Then you would just need to teach the C startup code to go looking for the appropriate section(s). - -- ... 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 ------------------------------ Date: Thu, 25 Jan 2001 16:12:10 -0500 From: Delanet Administration Subject: NFS server out of mbuf's? I run a FreeBSD 3.2s nfs server which recently crashed with a panic 'Out of mbuf clusters'. I found this odd since the normal peak is always below 200 and I compiled the kernel with users at 256 (4608 max mbufs). The server had an uptime of 118 days prior to this crash, and has no entries in the logs out of the norm up until this crash. Just curious if anyone knows of any reason this would happen? The server has no other use at all..no one even logs into it except me on occasion to go over logs and such. Thanks and regards, - -- - ------------------------------------------------------------ Stephen Comoletti - Network Engineer / Systems Administrator Delanet Inc. http://www.delanet.com Frontline Communications Corp. http://www.fcc.net phone: (302) 326-5800 fax: (302) 326-5802 x312 262 Quigley Blvd, New Castle, DE 19720, USA - ------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 19:55:04 -0500 From: Sergey Babkin Subject: Re: if_fxp driver info David Greenman wrote: > > >> I don't know what list you are looking at, but the download list that > >> I was > >>looking at did not include SCO, Unixware or any other Unix variant except > >>Linux. > > > >This is the list. > > > >NDIS2, NDIS3, NDIS4 and NDIS5 drivers > > Novell Netware* Client 3.11, 3.12 > > Novell Netware Server 4.1x, 5 > > SunSoft Solaris* > > SCO Unix 3, 5 > > SCO UnixWare* 2, 7, OpenDesktop*, OpenServer* > > > >These are "licensed" drivers. The linux driver is free. > > How do you know that the above drivers are developed by Intel? The above > could easily be OS vendor supplied. It's anybody's guess without the source. The drivers for SCO are developed by Intel, and bug reports are usually redirected to Intel. SCO just does build and packaging. If SCO produces some fixes, they are sent back to Intel as well. I get occasionally involved in this process and know for sure. Though I don't know if SCO pays anything to Intel for that, probably not, considering that Intel loans their hardware to SCO for free. These drivers contain some code ifdef-ed for Compaq and ICL builds, so I suppose Compaq and ICL also do their own packagind when they supply these drivers with UnixWare on their machines. - -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 17:09:02 -0800 From: vijay Subject: resource overheads Hi, I was wondering if there was any literature (maybe specific to FreeBSD or in general) about the overheads of various programming techniques etc. For eg, reducing the number of system calls, and mapping them to Library function calls, or say use of inline fucntions vs otherwise. v. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Thu, 25 Jan 2001 18:25:04 -0800 From: Mike Smith Subject: 3ware ATA RAID 3DM management utility available (Please trim cc's on any followups to remove -hackers, thanks.) I'm happy to announce a quick public BETA cycle for the 3ware 3DM management utility for their family of ATA RAID controllers and FreeBSD. 3DM allows you to monitor and repair RAID arrays on 3ware controllers using a web browser, as well as generate email alerts on events and so forth. See http://www.3ware.com/products/3dm.shtml for more details. The product is not available in source form (sorry folks), but is compiled statically and should run on any FreeBSD system supporting the 3ware controllers (4.2 or later recommended). Thanks to 3ware for their support, and to my beta testers for their valuable input and persistence. - -- ... 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 ------------------------------ Date: Thu, 25 Jan 2001 22:03:35 EST From: GLOBALLINK2001@aol.com Subject: Kernel Hacking (i tried not to make it lame) hey guys i know you probably get this question all the time but i am looking into getting into doing somekernel hacking first i will tell you some thing i have assumed about it: 1.) you should know atleast more programming language well (probably C would be best) 2.) you should know some basic stuff about FreeBSD internels (i am planning on getting The Design and Implementation of the 4.4BSD Operating System that is about it the rest really is a blur and is so complex and huge i have no idea where to begin hope i wasn't to lame guys :-) Arthur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 14:18:08 +1030 From: Greg Lehey Subject: Re: if_fxp driver info On Thursday, 25 January 2001 at 12:54:17 -0600, Jonathan Lemon wrote: > On Thu, Jan 25, 2001 at 01:12:42PM -0500, Dennis wrote: >> At 10:58 PM 01/24/2001, Jonathan Lemon wrote: >>> In article >>> >>> you write: >>>> >>>>> >>>>>> I'll look into the Linux driver, however, and see if it has anything >>>>>> useful in it. Historically the Linux Pro/100+ driver has totally >>> sucked and >>>>>> was chalk-full of magic numbers being anded and ored. >>>>> >>>>> That's "chock full", and you're confusing the Becker driver (bad) with >>>>> the Intel-supplied driver (slightly less bad). >>>> >>>> >>>> The intel driver seems to cover all the bases and has some nice glue >>>> routines for determining the part and features available. >>>> >>>> I havent tested it under load, but I wonder if intel would consider >>>> supporting it if someone ported it over to freebsd? they have drivers for >>>> just about every other major OS except BSD. it would be nice if the driver >>>> was updated BEFORE cards and MBs that dont work started showing up on the >>>> loading dock. Every time I get a shipment we have to hold our breath until >>>> we try one out. >>> >>> The documentation is available, if you want to (or have to) sign an >>> NDA. People who have the NDA documentation are perfectly capable of >>> writing a driver, although the source can't be released. It would >>> probably be possible to release a binary driver, but why do anything >>> to help Intel, given their unhelpful attitude? >> >> If they have a published, freely distributable driver for linux. why would >> you have to sign an NDA to port it to FreeBSD? >> >> I dont think so. Not anymore anyway. Thats the whole point of this thread... > > Having looked at the Linux driver, the FreeBSD driver, and the > documentation, I can tell you that assuredly not all of the features > are documented in the Linux driver. Also, porting requires changing > things, and without an understanding of _WHY_ things are done the > way they are, you can end up invaderdently changing something that > turns out to be critical. > > Also, the Intel driver isn't put together very well, so you might end > up with a lower performance driver after all is said and done. Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? 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 ------------------------------ Date: Thu, 25 Jan 2001 22:59:27 -0500 (EST) From: Alwyn Goodloe Subject: Divert Sockets & Fragmentation revisited Guys still having problems with divert sockets and fragmentation. As I said in a previous post the divert operations and corresponding program work fine when the datagram sent have size < MTU (1500) but when the datagram has size > MTU and hence get fragmented the recfrom just waits never receiving anything. I am attaching the relevent code fragments below. tcpdump tells me that the packets arrive on the interface. Hence I know the fragments arrive. Now my ipfw commands are: ipfw add 60000 divert 4422 udp from any to any 3322 in ipfw add 65000 allow ip from any to any Now I thought that that maybe the divert being so specific was a problem so I tried flushing ipfw and using the command: ipfw add 60000 divert 4422 ip from any to any thus diverting any ip packets and still nothing. Now according to the man page on divert: Incomming packets which get diverted are fully reassembled before delivery of any one fragment. Diversion of any one packet causes the entire packet to get diverted. I different fragments get diverted to different ports, then which port ultimately gets diverted is unpredictable. I was under the impression that the packets wern't reassemblembed before diversion. Am I wrong here? If the packets are reassembled before the diversion but as it says about that it may be unpredictable as to where they are sent could explain the case where I was redirecting udp packets heading toward 3322 but not the case where I was redirecting all IP packets. Any suggestions as to what stupid thing I have failed to do here. Alwyn Goodloe agoodloe@gradient.cis.upenn.edu Here is the important code fragments: Note: I have played with the MAX_PACKET_SIZE in hopes that it would make some difference but to no avail. #define MAX_PACKET_SIZE 300000 #define DIVERTPort 4422 #define ACTIVE_UDP_PORT 3322 if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) sys_error("divert socket error"); set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); printf("Step 1 \n"); /* Register address and port with the system */ if (bind(divert_sock, (struct sockaddr*) &server_divert,sizeof(server_divert)) < 0) sys_error("server_divert bind error"); for ( ; ; ) { n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, ( struct sockaddr * ) &client_add,&clilen); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 14:54:17 +1030 From: Greg Lehey Subject: Re: Kernel Hacking (i tried not to make it lame) On Thursday, 25 January 2001 at 22:03:35 -0500, GLOBALLINK2001@aol.com wrote: > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Correct on both counts. > that is about it the rest really is a blur and is so complex and > huge i have no idea where to begin hope i wasn't to lame guys :-) Well, once you have the book, look at something you might find interesting, and play around with it a bit. If you keep a "diary of a learning hacker" on the web, you might do a great favour to a number of people like yourself. If you run into trouble, ask here. 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 ------------------------------ Date: Thu, 25 Jan 2001 23:32:14 EST From: GLOBALLINK2001@aol.com Subject: Re: Kernel Hacking (i tried not to make it lame) so you mean like take one section at a time? like device drivers, smp etc? whatever catches my interest? ok i see just like programming when you got something big break it into parts, and wow can't belive the author of a great book and a core team member answered my question in less than an hour, try getting that from another OS :-) thanks greg! - -Arthur To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 01:02:33 -0500 From: "Patrick Bihan-Faou" Subject: Re: Divert Sockets & Fragmentation revisited Hi, Sorry to state something that is obvious, but when you bind your socket to the port, you have the port in the correct (network) order ? i.e. do you use htons(DIVERTPort) ? If you have lsof installed, run it and look at the port number that your program listens on. Patrick. > Here is the important code fragments: > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make some > difference but to no avail. > > #define MAX_PACKET_SIZE 300000 > #define DIVERTPort 4422 > #define ACTIVE_UDP_PORT 3322 > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > sys_error("divert socket error"); > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > printf("Step 1 \n"); /* Register address and port with the system */ > if (bind(divert_sock, (struct sockaddr*) &server_divert,sizeof(server_divert)) < 0) > sys_error("server_divert bind error"); > for ( ; ; ) { > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > ( struct sockaddr * ) &client_add,&clilen); > > > > > 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 ------------------------------ Date: Fri, 26 Jan 2001 01:10:53 -0800 From: Alfred Perlstein Subject: Re: Kernel Hacking (i tried not to make it lame) * GLOBALLINK2001@aol.com [010125 19:04] wrote: > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) C is necessary including a strong understanding of the pre-precessor, knowing a bit about 'make' is also pretty important. > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Well more than 'basic' hopefully. :) Good choice on a book, others to look at are: "UNIX Internals 'the new frontiers'" Vahalia "The Basic Kernel Source Secrets" Jolitz and of course "The UNIX Hater's Handbook" > that is about it the rest really is a blur and is so complex and huge i have > no idea where to begin hope i wasn't to lame guys :-) Find a local user group, find and talk to some kernel hackers, but step away at the first sign of dizzyness or lightheadness. Feel free to ask on the mailing lists if something is confounding you, just be sure to check the mailing list archives first. best of luck, - -- - -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 ------------------------------ Date: Fri, 26 Jan 2001 17:30:15 +0800 From: Ariff Abdullah Subject: Re: Kernel Hacking (i tried not to make it lame) On Fri, 26 Jan 2001, you wrote: > * GLOBALLINK2001@aol.com [010125 19:04] wrote: > > hey guys i know you probably get this question all the time but i am looking > > into getting into doing somekernel hacking first i will tell you some thing i > > have assumed about it: > > > 1.) you should know atleast more programming language well (probably C would > > be best) > > C is necessary including a strong understanding of the pre-precessor, > knowing a bit about 'make' is also pretty important. > > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > > on getting The Design and Implementation of the 4.4BSD Operating System > > Well more than 'basic' hopefully. :) > > Good choice on a book, others to look at are: > "UNIX Internals 'the new frontiers'" Vahalia > "The Basic Kernel Source Secrets" Jolitz > and of course "The UNIX Hater's Handbook" > > > that is about it the rest really is a blur and is so complex and huge i have > > no idea where to begin hope i wasn't to lame guys :-) > > Find a local user group, find and talk to some kernel hackers, but > step away at the first sign of dizzyness or lightheadness. > > Feel free to ask on the mailing lists if something is > confounding you, just be sure to check the mailing list archives > first. > > best of luck, The manual pages are very helpfull although not the complete references, the sources itself is the saviour. I remembered porting back cd9660 to 2.2.x tree, and now look forward porting softupdates (If anybody can give me some light I really appreciate that). I'm reviewing sources from current, stable and from other BSD project such OpenBSD to pick all the good stuffs. I'm a happy 2.2.x user. - -- /\_____ / ./__ / __/ < I do understand.. / ___/ / / ^^^^^^^^^^^^^^^^^^^^^^ *warf* *warf* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 02:23:20 -0800 From: Kris Kennaway Subject: Re: FreeBSD Linux emulation / arla 0.34.6 - --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2001 at 10:15:53PM -0600, Chris Csanady wrote: >=20 > >On Wed, Jan 24, 2001 at 12:50:29PM -0600, Chris wrote: > >> Silly me--I forgot to mention, this is with FreeBSD 4.2-STABLE. > > > >How recent -stable? A bug like this was fixed recently. If it's older > >than a week, Try upgrading :-) > > > >Kris >=20 > Hmm, are you referring to this commit? It appears to been MFC'd on > 11/07, so I hope not. :) I will rebuild and find out though.. That could be the one I'm thinking of. Kris - --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org - --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6cVAYWry0BWjoQKURAoTGAJ4uhJO2AXC342RXcSaeGIPYnurwbQCgw2IN QRwUt2uYTBlJenS0D/e6vgc= =gorV - -----END PGP SIGNATURE----- - --+QahgC5+KEYLbs62-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 11:30:45 +0100 From: Xavier Galleri Subject: Re: Kernel memory allocation bug ... Alfred Perlstein wrote: > * Xavier Galleri [010125 10:36] wrote: > >> Alfred Perlstein wrote: >> >>> I told you about 3 times to provide us with a stipped down source >>> code module which reproduces this "bug". >>> >>> You haven't done this. >>> >>> Therefore I can't help you. >>> >> I did not expect to make trouble to anyone, just sorry for the >> inconvenience ... I am not sure that we could easily provide for some >> code sample on this issue since this could be expensive, but I will see >> for sure (I easily understand that this is easier for anybody to track >> down a problem in such conditions ;-). >> >> That said, I still remain astonished not to get any comments or >> questions or hints or any other reactions about the analysis I have >> already provided. I have seen other mails in this list that exposed >> different kind of issues without requiring code sample to feed a >> constructive discussion. Did I miss something ? > > > You missed the two other people reporting "bugs" the same week you > began to. I spend a couple of hours trying to track them down and > they wound up being errors in thier code and not FreeBSD's. > > Honestly the symptoms you describe lean towards error on your part. > Even if they are not your error they seem pretty hard to reproduce. > > You've been complaining about this problem for at least a week. > Producing some code so that we can test couldn't take more than a > couple of hours and would have probably had your issue resolved > by now. > > This is why I'm irritated that you still haven't provided any code > to reproduce it. I wish I could avoid this misunderstanding ! The fact is that I was expecting some hints to track down the problem on myown, especially concerning the FreeBSD behaviour in case of free list shortage. Also, I would appreciate to know if my understanding of the figures I got from 'cnt' or of the scheduling behaviour with regard to kernel preemption is correct. I think this would be helpful for me to build the code sample you are requesting. > I do appreciate your mini-kernel debug howto, I've got it saved > for future reference. I am sincerely happy that I could provide something helpful ... Well, actually, it sounds that I did go to far to be able to retract myself, so I will let you know of any progress I will make asap ;-) Cheers, Xavier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 13:31:50 +0100 From: "Koster, K.J." Subject: RE: Kernel Hacking (i tried not to make it lame) Dear Ariff, > > I remembered porting back cd9660 to 2.2.x tree, and now look > forward porting softupdates (If anybody can give me some light > I really appreciate that). I'm reviewing sources from current, > stable and from other BSD project such OpenBSD to pick all > the good stuffs. > I'm a happy 2.2.x user. > I think Yahoo! is using still on 2.2.8. There are some people on this list who work for Yahoo!, so you could try to drop them a line. I can imagine that they are interested in softupdates. 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 ------------------------------ Date: Fri, 26 Jan 2001 08:51:32 -0500 (EST) From: Mike Wade Subject: Re: if_fxp driver info (which card then?) On Fri, 26 Jan 2001, Greg Lehey wrote: > Performance isn't even the main thing. As I said earlier, it's plain > bloody unreliable. Linux people avoid the EtherExpress because they > think something is wrong with the card. They were surprised when I > reported that it works without any problems under FreeBSD. Do we > really want to change that? Slightly off subject but with all the discussion about not Intel playing nicely with the FreeBSD developers... I've always had the best reliability, performance, and lower CPU usage with the Intel EtherExpress Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there better cards out there that I should be looking at? - --- Mike Wade (mwade@cdc.net) Chief Technical Officer CDC Internet, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 09:47:38 -0500 (EST) From: Jim Sander Subject: Re: if_fxp driver info (which card then?) > > Linux people avoid the EtherExpress because they think something is > > wrong with the card. > Intel EtherExpress Pro 10/100B cards in FreeBSD These cards work well in our many 3.x and 4.x systems. But I just built up a Redhat 6.2 box with one, and all seemed to be working fine, but after a while I started having various problems starting net services. The box would boot, but often would "hang" indefinitely when "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro NIC, new MB, different RAM, other cables, everything, but no change. After I switched to a linksys NIC, voila- everything worked without a problem. (so far) Of course the Intel NICs still work perfectly when put into a spare BSD system. So it's *not* that the cards themselves are unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC conflict of some sort? - -=Jim=- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:01:41 -0500 (EST) From: Alwyn Goodloe Subject: Re: Divert Sockets & Fragmentation revisited Thanks for the suggestion I will give lsof a shot to see. I think the port binding is correct, otherwise I don't think it would work when datagrams aren't fragmented. Like I said the code works fine for datagrams < MTU ==> not fragmented but fails when they are. That being said it NEVER HURTS TO CHECK. Alwyn agoodloe@gradient.cis.upenn.edu On Fri, 26 Jan 2001, Patrick Bihan-Faou wrote: > Hi, > > Sorry to state something that is obvious, but when you bind your socket to > the port, you have the port in the correct (network) order ? > > i.e. do you use htons(DIVERTPort) ? > > If you have lsof installed, run it and look at the port number that your > program listens on. > > > > Patrick. > > > > Here is the important code fragments: > > > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make > some > > difference but to no avail. > > > > #define MAX_PACKET_SIZE 300000 > > #define DIVERTPort 4422 > > #define ACTIVE_UDP_PORT 3322 > > > > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > > sys_error("divert socket error"); > > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > > printf("Step 1 \n"); /* Register address and port with the system */ > > if (bind(divert_sock, (struct sockaddr*) > &server_divert,sizeof(server_divert)) < 0) > > sys_error("server_divert bind error"); > > for ( ; ; ) { > > > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > > ( struct sockaddr * ) &client_add,&clilen); > > > > > > > > > > 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 ------------------------------ Date: Fri, 26 Jan 2001 10:27:46 -0500 (EST) From: Alwyn Goodloe Subject: Re: Divert Sockets & Fragmentation revisited Having run lsof I can verify that the program IS reading on that port number. Has anyone else on the hacker list had problems with diverting fragmented datagrams?? Alwyn Goodloe agoodloe@gradient.cis.upenn.edu On Fri, 26 Jan 2001, Patrick Bihan-Faou wrote: > Hi, > > Sorry to state something that is obvious, but when you bind your socket to > the port, you have the port in the correct (network) order ? > > i.e. do you use htons(DIVERTPort) ? > > If you have lsof installed, run it and look at the port number that your > program listens on. > > > > Patrick. > > > > Here is the important code fragments: > > > > Note: I have played with the MAX_PACKET_SIZE in hopes that it would make > some > > difference but to no avail. > > > > #define MAX_PACKET_SIZE 300000 > > #define DIVERTPort 4422 > > #define ACTIVE_UDP_PORT 3322 > > > > > > if ((divert_sock = socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)) < 0) > > sys_error("divert socket error"); > > set_sock_data(&server_divert,PF_INET,DIVERTPort,INADDR_ANY); > > printf("Step 1 \n"); /* Register address and port with the system */ > > if (bind(divert_sock, (struct sockaddr*) > &server_divert,sizeof(server_divert)) < 0) > > sys_error("server_divert bind error"); > > for ( ; ; ) { > > > > n = recvfrom (divert_sock,encaped_pkt,MAX_PACKET_SIZE,0, > > ( struct sockaddr * ) &client_add,&clilen); > > > > > > > > > > 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 ------------------------------ Date: Fri, 26 Jan 2001 10:38:24 -0500 From: "Person, Roderick" Subject: gpc Pascal Compiler from FreeBSD This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C087AE.06D6891A Content-Type: text/plain; charset="iso-8859-1" Is anyone using this? I can seem to get the compiler to find any of the units. I have set the GPC_INCLUDE_DIR to where the units are but still no luck. Roderick P. Person Programmer II personrp@ccbh.com "I'm not indecisive. Am I indecisive?" - Jim Scheibel, mayor of St. Paul Minnesota - ------_=_NextPart_001_01C087AE.06D6891A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable gpc Pascal Compiler from FreeBSD

Is anyone using this?

I can seem to get the compiler to find any of the = units. I have set the GPC_INCLUDE_DIR to where the units are but still = no luck.

Roderick P. Person
Programmer II
personrp@ccbh.com


"I'm not indecisive. Am I = indecisive?"

        - Jim = Scheibel, mayor of St. Paul Minnesota

- ------_=_NextPart_001_01C087AE.06D6891A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 19:43:10 +0300 (MSK) From: "Aleksandr A.Babaylov" Subject: Re: if_fxp driver info (which card then?) Mike Wade writes: > On Fri, 26 Jan 2001, Greg Lehey wrote: > > Performance isn't even the main thing. As I said earlier, it's plain > > bloody unreliable. Linux people avoid the EtherExpress because they > > think something is wrong with the card. They were surprised when I > > reported that it works without any problems under FreeBSD. Do we > > really want to change that? > Slightly off subject but with all the discussion about not Intel playing > nicely with the FreeBSD developers... I've always had the best > reliability, performance, and lower CPU usage with the Intel EtherExpress > Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there > better cards out there that I should be looking at? 3C905 - -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 12:20:25 -0500 From: Dennis Subject: Re: if_fxp driver info (which card then?) At 08:51 AM 01/26/2001, Mike Wade wrote: >On Fri, 26 Jan 2001, Greg Lehey wrote: > > > Performance isn't even the main thing. As I said earlier, it's plain > > bloody unreliable. Linux people avoid the EtherExpress because they > > think something is wrong with the card. They were surprised when I > > reported that it works without any problems under FreeBSD. Do we > > really want to change that? > >Slightly off subject but with all the discussion about not Intel playing >nicely with the FreeBSD developers... I've always had the best >reliability, performance, and lower CPU usage with the Intel EtherExpress >Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there >better cards out there that I should be looking at? Why dont some people get the point even when you hit them in the head with a hammer? The point is that the driver quality is more important than the "card" To get completely off base, this is which is why we SELL our software. Implementation technique is usually more decisive in determining functionality and performance than the hardware itself. its something that people in the know are willing to pay for (sometimes). Certainly some hardware is better than others, but a bad driver with good hardware is useless. DB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 12:22:46 -0500 From: Dennis Subject: Re: if_fxp driver info (which card then?) At 09:47 AM 01/26/2001, Jim Sander wrote: > > > Linux people avoid the EtherExpress because they think something is > > > wrong with the card. > > > Intel EtherExpress Pro 10/100B cards in FreeBSD > > These cards work well in our many 3.x and 4.x systems. > > But I just built up a Redhat 6.2 box with one, and all seemed to be >working fine, but after a while I started having various problems starting >net services. The box would boot, but often would "hang" indefinitely when >"Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro >NIC, new MB, different RAM, other cables, everything, but no change. the eepro100 driver is badly broken in linux (havent you been paying attention?). it took me a few hours to fix it. They dont reset the card properly on an overrun, which causes it to lock up. Clearly the driver as is is unusable in a heavy use environment. DB > After I switched to a linksys NIC, voila- everything worked without a >problem. (so far) Of course the Intel NICs still work perfectly when put >into a spare BSD system. So it's *not* that the cards themselves are >unreliable. Perhaps the drivers controlling them? Perhaps a weird MB/NIC >conflict of some sort? > >-=Jim=- > > > >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 ------------------------------ Date: Fri, 26 Jan 2001 12:25:32 -0500 From: Dennis Subject: Re: if_fxp driver info (which card then?) At 11:43 AM 01/26/2001, Aleksandr A.Babaylov wrote: >Mike Wade writes: > > On Fri, 26 Jan 2001, Greg Lehey wrote: > > > Performance isn't even the main thing. As I said earlier, it's plain > > > bloody unreliable. Linux people avoid the EtherExpress because they > > > think something is wrong with the card. They were surprised when I > > > reported that it works without any problems under FreeBSD. Do we > > > really want to change that? > > Slightly off subject but with all the discussion about not Intel playing > > nicely with the FreeBSD developers... I've always had the best > > reliability, performance, and lower CPU usage with the Intel EtherExpress > > Pro 10/100B cards in FreeBSD (and Solaris x86 for that matter). Are there > > better cards out there that I should be looking at? >3C905 I disagree. The if_fxp driver is far superior to the if_xl driver. In other OS's your mileage may vary. DB >-- >@BABOLO http://links.ru/ > > >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 ------------------------------ Date: Fri, 26 Jan 2001 19:32:34 +0100 From: mouss Subject: [kernel patch] fcntl(...) to close many descriptors Hi, I've modified the kerenl to add F_CLOSEM functionality to fcntl. (I've seen this in some AIX docs). The purpose is allow a process to close all its filedescriptors starting from a given value without issuing thousands of close() syscalls. This may be used for programs that daemonize themselves (or one of their children) after some amount of work, when many fd's has been opened. The program would simply call fcntl(minclose, F_CLOSEM, 0); The patch concerns /sys/kern/kern_descriptors.c and fcntl.h (and of course the corresponding manpage). Is this functionality worth inclusion in the kernel (or should I throw away the patch)? are there any kind souls to review the patch? cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:33:44 -0800 (PST) From: Matt Dillon Subject: Re: [kernel patch] fcntl(...) to close many descriptors I think it is worth doing. A quick google search shows that the linux folks discussed the AIX thingy in March 1999, but I don't think they actually implemented. From the discussion, it appears that the fcntl would be useful and (not having seen your patches), almost certainly trivial to implement. -Matt :Hi, : :I've modified the kerenl to add F_CLOSEM functionality to fcntl. :(I've seen this in some AIX docs). : :The purpose is allow a process to close all its filedescriptors starting :from a given value without issuing thousands of close() syscalls. :This may be used for programs that daemonize themselves (or one of :their children) after some amount of work, when many fd's has been :opened. The program would simply call : fcntl(minclose, F_CLOSEM, 0); : :The patch concerns /sys/kern/kern_descriptors.c and fcntl.h :(and of course the corresponding manpage). : :Is this functionality worth inclusion in the kernel (or should I throw :away the patch)? are there any kind souls to review the patch? : :cheers, :mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 19:36:15 +0100 From: Xavier Galleri Subject: Re: Kernel memory allocation bug ... This is a multi-part message in MIME format. - --------------010304000009040600000002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Xavier Galleri wrote: [...] >> You've been complaining about this problem for at least a week. >> Producing some code so that we can test couldn't take more than a >> couple of hours and would have probably had your issue resolved >> by now. >> >> This is why I'm irritated that you still haven't provided any code >> to reproduce it. > [...] > Well, actually, it sounds that I did go to far to be able to retract > myself, so I will let you know of any progress I will make asap ;-) Ok, I'm back again ;-) and this time, I got something for you ... Basically, what I did, is to write a little SYSCALL kld module to allow controlling calls to MALLOC/FREE from user space. This way, I can issue some filesystem-intensive command (tar something-bigger-than-memory-size) in order to create the free list shortage. Then, I use my test program to issue several MALLOC in kernel space. What I actually noticed is that, when the free list felt below 120 or alike, I can issue several thousands successful MALLOC as long as the asked size is no more than one or a few pages. But, when I ask for numerous pages (32Kb), then the process is falling asleep (this is analysed with my manual stack analysis process ;-), whilst the M_NOWAIT flag has been set (of course !). Everything is almost entirely self-documented in the attached kmem.tar.gz file. I hope this will help and I am eager to hear from you soon. Have a nice WE, Regards Xavier - --------------010304000009040600000002 Content-Type: application/gzip; name="kmem.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="kmem.tar.gz" H4sICEe+cToCA2ttZW0udGFyAO0ba1PbSJKv6Ff0kk2wWGH0sGUb1tkj4Gxxy+MKwt5tJZRL lkZGZ0vySbLBl/Dfr3tmZMsPSMgu3D6sCrKmp2emp9/TUnohC3fWnvaCil6rVmHNsKtGtSJ+ K/gLk0sHqJlWxTLtionPhmFatTWorj3DNUwzJwFYu+06/T5LgvvwEifyvLU/3dUj+Z/88q51 8W7ndyD/Ckoe5W+atrmS/3PLPxxnLM3K7m+9hqHrdqVyr/zNij6Rv2XoNZR/Ra9U10Bfyf/J L+VFELn9ocfg+zTzgrh8/XoW1A86BCsCx+kO/rnIrzls7MjGA5YugsPYG/bZ3ETh2EtGHIYy yAIXgiiDcCznbkfDcO+eriAKMiiN4sBTlY8KQJolQxcR+CptGgJ02+NdTlYesSQN4giakAb/ ZbFfIqhK3TiEnkv46weRV9rgRG2o2qspSpEimoJm9JzMKSNRI6e/p9wpygx9UKKmG3oap5vW FE/9OB4IiqmVsEzMjyu2naSbtjOgH9w18IcyTgG4Iv7s5SCaTO5jAqNpEUY/fCxOTCiCmNIM /Rq8oiF8Y4EPJURVYcCSJE5o7xJzQ83nGSaRoDPfoxNEYns4jauBe+0kW/Q8en8ldjaM0qAb MY93EelNfU9uWDBiQuasPEtiTSKKpv7eUrFFEwIMEhztlzY6jkdLgRsPo+xDtMF3AcBucfS2 wVt3NIdkG6fKuHqvX3FFEIxzsjgo8R7zio+QzJvCrStBSXoTZO41lHC2KSmukzLYDDd3C62T mVZnpvVGtsTo6VYmey+d7B8fnx1oLz38p+KmtAKbBCF0FfB/OTg5bMtRS3GJhcSCZpMohU+f IG+dbKrQSZjTA8G5uwKl/iYUCX+bN++n/O15q6U+lnAatByTE1aky2O+M+xny8m4jHpRfBOh LoQhuuZdeOlyGkha9015V1Bqnau0svYXv4rx/8TpMT/os2eO/5ju1+biv1Wr1Vbx/1niv0j6 diFP/qBcRn04PP95R4ZnZd11YfsMtgfBgE3RtmP5DNtH+ZCVOf1R7Z/k/Xs4/1cMvUrnP8Oy V+e/Z5b/U7n/L/D/xpz8LcRf+f9n8f8X5wcXTeHqXeWnk7ND0VB+Omt++5Had+VerPx0fEhd maKUJ8e3TuqVe3huKoe91yvP/8e3fxnv157d/i19kv9VdNsk+6+aq/zvmeo/eMoKIgbFY+V6 Sb89bO0fqnO9dHajvjet1ltVUajWg/2T6sukjjGpcMjCRX72z59FBeButvKBh7bpaqiP7f3z Hy/ap2+gJGs2RWx1RwJxOlVdeZ/fzv7dZ7d/26SYP2f/q/rv89d/7y/fDpzECZeAk9h9qNa7 UDNmUbYI77EkYv2l+Fm4pPY8CkOWsWTJwijBZQTlZN5TeubOa+B2ttAfucMEn/ZyqFyKfvcU KjdvbQFZTGfoQ5NKSIXytCL8E24xGaPPktPi0lsw0EAOHjqF+m866w/FMy/FipLpfGGYl7Xc eDCmEuwWTiWKuVpe1MZnVQWONS3W4RS7nKZdXgXUb1/eilLoS0+UPl96vG6Gg8u8Yk0PojxH T9MSXV4OlYhzJdFi+LivbkikCBntTrj4cgCC5/T0/qV3xYmRvZrs06DdPj46bbXbs0VOiaZK 0EdlXXAPWkenP+8f7ynrhQKgLP/RlVJ1fNCPGC86Pw2ZefVTDmtCrlqiAzWKYFGWAwTr8i1p Ql+0XARbUsQcrGon7cPWz28u3+LD6dk/94/ePdk2FrndbOoFhi9f7+3+0fHleSufeRf8hHGN uwkS/uu4WTDiT0E0fXYd95pJhVTWOZPKozaNbfOSvyYhNMssRMwxC8tnnoXyNQQIt7eOanBb otchE9U5PTtpndyrOn6cQIkkgiYq7Of7iZ0IwHffFdhTEPP6rITfE+6VkLM2sbllglXWC9wX w7gM1j8Sj75IACTqrxEC3xAXxbMIA2AqDoB5gUzK+et381IpmJmei2wy1YOWcXF5cNC6uChY yFfxKTchLvEnZtN9r0sKfpgS9Ye8MJFX9ArFPcwa/Tdf62MfaSgLKq4CbaJUch3PSzDhnzWb 3E7UhXWXjtKgMOABjvxxtaGQlcAj36gJeebi/OyLM47OX57J3EemOiK9k0mLbDR5rmNoeKOT WmlLnUmMZFqESUshd8Jz4exr/9j3U/5C+/SsffHLxQG60WWJVz92vEneJXLQLfrVYPIynq/G X5lPk7BJvjVJcZa88D05O2wfn+0fPmRTtP4uEBbQ606GDUm51ArRUvcetl9c6fL0y9YSeF+5 2m+rClIubST/8rgljuraK0GD9qqoE9pUWtrp5fExqfDqGP7/Pf+ft/YPT1pPtsbD53/DpJdD 4vxv1XTb4N//VY3V+f9Zzv/vMGyRM2ZpClmMlo0Nb+gyyERHp89CCFJwUgzpmDPdpLuKYmB0 DpKUfDMg29DFpulQDNkMnR7bzD/LSGEYeXiA5hUmQACIbw1gb1tVFFOFo4wmH6bMH/Zx/Zho uImTHobb7BocEMUBnNnJ4Bpp8Fhn2IV4kAVxlJJTmqErrygTDRKHmoetN5c/Nre7k/5CH+8/ fKMolgp/R2UAx6cTfxChXvT7QdTlu/JYihHby8mhjSSsE8dZjhBiUA4iRpGuwAxBGeHk/EAi X0Ov7/FoVay79WLsmPkQEzpQ0Rs2GLpZUWDx2vnAb8u6Pn3ityVd/OjP07G5q+T6ZRSefL2/ CfQmUJUcff/uGoV0E/T74AWYVztjSOOQ5WILUXecLkOewc7ISXb6cXdHwlINWDpgboC8HEty Nigd2iDBcX0ppke0LOt7pFabLjVnpCsrRbuwpKrhMeQn3xznGd8hZ9zcoPkTsZ4fiPVbt+6a DV3X4b1lX33VuEr18+NuXd2vMUJfNkHj3gnmU9PpRDJFNa26URVZqlWr6nmeathWY5qpmkat JnNVw3iQoR1Glf3PM3T2KDGlajneU+wC7YZc+K2PK213gu42qW6Ze/XZ6wXgmcSJxhCj4iVc w6nGyMJtzK1YlNLU0k41rpvd2OlDh3Ebf9A855ZxMWXKpAegTfUDRE+v4yQjMymXy8rC5380 lUZTqcr8B3aFrtd/GiMwrN/ICOREUn0MUxfKU7XsBkzURbcLymPqZiPXnppdfxorkGR9sRX8 +m3AV107nz585Uj49MiBS0zhmx++Ub7Arl6ACECYF2A8oDALbMQiDLpozFmAseZXGdXC+paJ DBVyXpiT94mRM8ThnoYYuaI4y09HmMmk1wxjJmZR4SDjJCo4aj9Dz0AjiAUaHKGbIVzyFi4m JXGfUbObOB0Ow+Qkn4HSDpFcOBy8OXCiwJ0kWzh9Fafn+YsbJwlzM5ml8JEyd3ETJ70GbxgO hJ+i7+I7Y9hMnRHDUWyTSKKkOOPpFWx2vQ5s9zYhxZBOyDwXc3hQxtDPaWWZIF8Yc0yeeJpU XifxsHtNk/FMiham+B6mXdT9wVyML/VwORUGsCX7lW8NPPp/xFY7dLp44m+ielRt3dSAYPKr bpRKpS4gOOgWIbZp2BNAgoBqTa9RekagQUYQCj513SKns3EQD8ZJ0L3OMBFSwWg0zG2TOig9 fouK++biEP6RxP9GnpY/RPPYtYaG97rO7xa/2/xe53fe2zD43eR3jtOofIg+ZLTCOeui20mJ L8Sjyyjg/2MhGxPkwOkHfpxEgVOGfVQnvnCKkk1ZMmIekpMTWCkb2+et4w3UtLuck7ewkxZ2 +h2xgbamCFilWrd2ZV6GbsT8ED0YV4RlTNxgjv2lAeVR+BhI7sX/XAD5EBETptq0cwtbpVLh XZ86HaAq35qkYghuu4nFFcN0PB+7NMJtMy/gQF9eEpoKqFs3GDIox+0MJNQ1Haa7OW4BijPn uLccmjcDiaQbDVs3KgLqJbpEUt7jlq7yPQWRH6NLddACp6sVRisXmeP2JAYa7BRpV4H5pSh1 D4N2/oqvXN7Bf+Qv+K2djiP3uuzu1qt1dQ/IUXh8CjFBtdapKrIKRZ5kYUmr/lnSrXpxMsIG ltG3yDiKPMdRJIKGJlxnHxUyzZ3m9JCV8i2Th5l6kodY9EKH4rZVIvqBvSv4xy3lPhw4RZc/ xKkotaRk0wvICcfJuLycnNltEzlZ2mdsAKXAQwtschv1DJ2RiiRBnKBLaKJi3GDI6/Jey/J9 y4CNURgPnGRDo3AYN/UHt1KxGwr+iRp/dB/acoptnVNsNhq+aXGKR2E77pBfbA8wnrUTFsaY npQETNDYqFrkG3lQaVatWg3jd+ThU72qgYvCjNpx1B/PkD0K8R+fsny9W63UFPwrMH+m+9F8 b7hyF3bFtvNdhM6g7bE+w8y9hM856Zho5aRbZsVE1eFOnDZAbdNs1OxFwnEC5LRRN3SFbvOE i+5H0+3WJd0Vu+NzuskjtoV7XEI1uuymSFjA7zvdtGksEEoiR1Is5AP+LXBYdj+aUl9qdp1Z Xo1TOm1ybyNJLpJIH58I+u1KnRzqIs1TLZUfexCP68ji5YY5QXos/b7pyrOpj+F7Qr9oEv0/ /ID+YvlQR5oIczp2dTJUNGmoTChNKPFxzY+Z3/bpk4QK2gU+s8KzV4TzMJTzypcBaNvQa7WG VTPMuiYTcurjYSjvwyF8RMDD0HbDtGt21aDwxlEpClE0l6vczq7i8m6rUjXoP2cLmEMwPI/w VpY4gygmJLNIQUIplinwebixa4atV7j1I8ylnVmG6OeCJpRqQ26tSL5lCPJTwYw78dpwohOB VbfFjSghjTBMW6HbVCUWcB6hEB2/4/udekWI0es4tYJUeZOk+q8gyvTbut6e/B9QUT0ThwPG QszYHF53SIMw6DsJr3RSKk0HgIzbxJgy+QH3QPwkwqJRkMRRSK/S+OlhP+IooUgWE/jPENEo J3fwrHjD+m7ME/JdyKvZf2NRQAhl7Fm9Z1ldq2t1ra7VtbpW1+paXatrda2uv/D1P0dA6cYA UAAA - --------------010304000009040600000002-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 10:43:00 -0800 (PST) From: Archie Cobbs Subject: Re: Divert Sockets & Fragmentation revisited Alwyn Goodloe writes: > Guys still having problems with divert sockets and fragmentation. > > As I said in a previous post the divert operations and corresponding program > work fine when the datagram sent have size < MTU (1500) but when the > datagram has size > MTU and hence get fragmented the recfrom just > waits never receiving anything. I am attaching the relevent code > fragments below. > > tcpdump tells me that the packets arrive on the interface. > Hence I know the fragments arrive. > > Now my ipfw commands are: > > ipfw add 60000 divert 4422 udp from any to any 3322 in > ipfw add 65000 allow ip from any to any I think the problem is that the first fragment is matching your rule, but not subsequent fragments (because the port number is only contained in the first fragment..) > Now I thought that that maybe the divert being so specific was > a problem so I tried flushing ipfw and using the command: > ipfw add 60000 divert 4422 ip from any to any > > thus diverting any ip packets and still nothing. That doesn't make sense.. Try adding the "log" keyword to your ipfw commands, or checking the stats with "ipfw show" so you can see exactly what's being diverted. > Now according to the man page on divert: > > Incomming packets which get diverted are fully reassembled before > delivery of any one fragment. Diversion of any one packet causes > the entire packet to get diverted. I different fragments get > diverted to different ports, then which port ultimately gets > diverted is unpredictable. > > I was under the impression that the packets wern't reassemblembed before > diversion. Am I wrong here? Yes... but all fragments must match. - -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 11:12:59 -0800 (PST) From: Doug White Subject: Re: pthreads and kqueue On 25 Jan 2001, Kevin Mills wrote: > Well, there are wrappers in the libc_r code (libc_r/uthread/uthread_kevent.c) > and I seem to recall posts on -stable saying that kqueue could now be used > with user threads (around the 4.1.1 time frame, I think). I could be wrong :) > > This seems like a strange way to implement your solution, though ... from > > the sounds of it, you can only have one concurrent connection to your > > authentication server via this library, which sounds extremely lame. Do > > the clients just sit around forever until the server returns? The > > serialization this library forces isn't too scalable. > > The library is reentrant and will allow different threads to call into > it (there isn't a mutex serializing the entry point or anything like that). > However, the call to the backend is done with a blocking call. The > communication with the backend is generally very quick. However, if the > backend gets too busy I want to make sure I don't starve the other connections. > A thread pool seemed the best way to tackle this. I'd be very open to other > suggestions if you have any! Also, your proprietary library has to be threadsafe too. Particularly if it blocks... it'll probably block the whole process instead of the individual thread. Unless we figured out a way to fix that :) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 11:19:14 -0800 (PST) From: Doug White Subject: Re: NFS server out of mbuf's? On Thu, 25 Jan 2001, Delanet Administration wrote: > I run a FreeBSD 3.2s nfs server which recently crashed with a panic 'Out > of mbuf clusters'. I found this odd since the normal peak is always > below 200 and I compiled the kernel with users at 256 (4608 max mbufs). > The server had an uptime of 118 days prior to this crash, and has no > entries in the logs out of the norm up until this crash. Just curious if > anyone knows of any reason this would happen? The server has no other > use at all..no one even logs into it except me on occasion to go over > logs and such. Sudden network outages during periods of high activity will cause mbuf cluser consumption to increase. 'netstat -m' is your friend. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 20:49:40 +0100 From: mouss Subject: Re: [kernel patch] fcntl(...) to close many descriptors At 10:33 26/01/01 -0800, Matt Dillon wrote: > I think it is worth doing. A quick google search shows that > the linux folks discussed the AIX thingy in March 1999, but > I don't think they actually implemented. From the discussion, > it appears that the fcntl would be useful and (not having seen > your patches), almost certainly trivial to implement. you're right. (I can resend it as a tar file...) *** kern_descrip.c Fri Jan 26 19:42:18 2001 - --- kern_descrip.c.new Fri Jan 26 20:24:07 2001 *************** *** 364,369 **** - --- 364,387 ---- (caddr_t)(intptr_t)uap->arg, sizeof(fl)); } return(error); + + /* close all descriptors starting from a given value */ + case F_CLOSEM: + { + i = uap->fd; + + p->p_retval[0] = 0; + if ((unsigned)i >= fdp->fd_nfiles) { + return (EBADF); + } + for (; i<=fdp->fd_lastfile; i++) { + struct close_args uap; /* XXX. requires _SYS_SYSPROTO_H_ */ + uap.fd = i; + close(p, &uap); + } + return 0; + } + default: return (EINVAL); } The F_CLOSEM is added to fcntl.diff *** fcntl.h Fri Jan 26 20:24:45 2001 - --- fcntl.h.new Fri Jan 26 20:25:39 2001 *************** *** 156,161 **** - --- 156,162 ---- #define F_GETLK 7 /* get record locking information */ #define F_SETLK 8 /* set record locking information */ #define F_SETLKW 9 /* F_SETLK; wait if blocked */ + #define F_CLOSEM 10 /* close open fd's larger >= arg */ /* file descriptor flags (F_GETFD, F_SETFD) */ #define FD_CLOEXEC 1 /* close-on-exec flag */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 21:00:54 +0100 From: mouss Subject: packet redirection design problem [Divert Sockets & Fragmentation revisited] "IP filtering engines" that do something to packet based on rule matching have a problem when fragmentation comes to play. In the case of a "packet redirector' such as divert, the problem is that only the first fragment will match the rule, if the rule uses ports or whatever info contained in the payload. The problem occurs if the packet (that should match) is subject to change by the engine (either redirection, nat, blocking, ...) IP Filter handles such situation with specific code. It would be a nice thing if this is added to standard code so that packet filters writers do not need to add their own. Any opinions? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 26 Jan 2001 12:00:17 -0800 (PST) From: Matt Dillon Subject: Re: [kernel patch] fcntl(...) to close many descriptors : :At 10:33 26/01/01 -0800, Matt Dillon wrote: :> I think it is worth doing. A quick google search shows that :> the linux folks discussed the AIX thingy in March 1999, but :> I don't think they actually implemented. From the discussion, :> it appears that the fcntl would be useful and (not having seen :> your patches), almost certainly trivial to implement. : : :you're right. (I can resend it as a tar file...) : : :*** kern_descrip.c Fri Jan 26 19:42:18 2001 :--- kern_descrip.c.new Fri Jan 26 20:24:07 2001 :... Yah, something like that. You can test whether the descriptor is valid before calling close() on it, which should make it a lot faster. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ End of freebsd-hackers-digest V5 #20 ************************************ ---433746122.980539550302.JavaMail.root.ad-a02.dmz.another.com-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 12:54:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chuck.teleweb.at (TK158249.telekabel.at [195.34.158.249]) by hub.freebsd.org (Postfix) with ESMTP id 7E44337B400; Fri, 26 Jan 2001 12:53:57 -0800 (PST) Received: by chuck.teleweb.at (8.11.1/8.11.1) id f0QKrkY00357; Fri, 26 Jan 2001 21:53:46 +0100 (MET) (envelope-from alh) From: Alexander Hausner To: Mike Smith Subject: Re: Pthreads with sprintf/dtoa Date: Fri, 26 Jan 2001 21:23:23 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: hackers@freebsd.org References: <200101250348.f0P3mPI02756@mass.dis.org> In-Reply-To: <200101250348.f0P3mPI02756@mass.dis.org> MIME-Version: 1.0 Message-Id: <01012621534501.00257@chuck.teleweb.at> Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG on Thu, 25 Jan 2001 Mike Smith wrote: > >__dtoa has static locals. Bad function, no biscuit. I think this can be a serious problem for any threaded application, I have not tested your patch yet, you think this is only a temporary solution right? Have you commited this patch to current? Is somebody else working on that? Thanks and regards, Alex --=20 Email: Alexander Hausner NIC-HDL: AH194-RIPE PGP Key ID: 1024/D272F9B5 PGP Key fingerprint: 45 CB 7A 6A 24 81 71 14 CE 11 27 53 36 63 AD 1C PGP Public-Key: https://www.luga.or.at/pgppubkeys/D272F9B5.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 13:21:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ffnet.com (w200.z208176006.sjc-ca.dsl.cnc.net [208.176.6.200]) by hub.freebsd.org (Postfix) with ESMTP id 2E60437B404 for ; Fri, 26 Jan 2001 13:20:55 -0800 (PST) Received: from ffnet.com (noriega.ffnet.com [172.16.248.252]) by ffnet.com (8.8.8/8.8.8) with ESMTP id NAA15589 for ; Fri, 26 Jan 2001 13:20:49 -0800 (PST) (envelope-from solan@ffnet.com) Message-ID: <3A71EA31.705019DA@ffnet.com> Date: Fri, 26 Jan 2001 13:20:49 -0800 From: Michael Solan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: libkvm and DB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi there, I'm porting some stuff from FreeBSD 3.3 to 4.2 which uses libkvm. The old one had a DB *db member in struct __kvm (for dbopen(...) calls), but in 4.2 it's missing, so do you have to use slow nlist calls or am I missing something here? Thx in advance Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 13:21:58 2001 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 9DBAF37B402 for ; Fri, 26 Jan 2001 13:21:41 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.2/8.11.2) with ESMTP id f0QLLVg06530 for ; Fri, 26 Jan 2001 16:21:31 -0500 (EST) Date: Fri, 26 Jan 2001 16:21:27 -0500 (EST) From: Zhiui Zhang X-Sender: zzhang@onyx To: freebsd-hackers@freebsd.org Subject: specify a different kernel to boot 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 Is there a way to specify a kernel other than /kernel to boot from? I do not want to do this manually, I want to put it into some configuration file. Thanks, -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 13:35:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.mobydark.com (ns1.mobydark.com [216.13.76.21]) by hub.freebsd.org (Postfix) with ESMTP id BAB2537B401 for ; Fri, 26 Jan 2001 13:35:23 -0800 (PST) Received: from jeff (pc101.mobydark.com [216.13.76.101]) by ns1.mobydark.com (Postfix) with SMTP id 1FF70151A1 for ; Fri, 26 Jan 2001 16:38:26 -0500 (EST) Message-ID: <032a01c087e0$d8bd90e0$930aa8c0@mobydark.com> From: "Jeff Brooke" To: Subject: driver for Matrox Meteor II frame grabber Date: Fri, 26 Jan 2001 16:42:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0327_01C087B6.EFB52E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0327_01C087B6.EFB52E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, I am fairly new to freebsd, but have been asked to develop a driver for = the Matrox Meteor II card. (To the best of my knowledge, there is = currently no such driver in fbsd, please correct me if I'm wrong..) My first initial thoughts were, 'ok, let's base it as much as possible = on the Meteor I driver, naturally making changes for hardware = differences where applicable. However, I've just read a couple of = archive entries about a new method for drivers based on a 'newbus' = system. My questions are: (i) where, if at all, can I find = info/tutorials/examples on driver-writing with this method? (ii) what = are the benefits of the newbus method? (iii) is it still at all = acceptable to write drivers using the old style/method? If these issues are better posted to another mailing list, please = advise... Thanks very much in advance, Jeff Brooke ------=_NextPart_000_0327_01C087B6.EFB52E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
I am fairly new to freebsd, but have = been asked to=20 develop a driver for the Matrox Meteor II card. (To the best of my = knowledge,=20 there is currently no such driver in fbsd, please correct me if I'm=20 wrong..)
 
My first initial thoughts were, 'ok, = let's base it=20 as much as possible on the Meteor I driver, naturally making = changes for=20 hardware differences where applicable. However, I've just read a couple = of=20 archive entries about a new method for drivers based on a 'newbus'=20 system.
 
My questions are: (i) where, if at all, = can I find=20 info/tutorials/examples on driver-writing with this method? (ii) what = are the=20 benefits of the newbus method? (iii) is it still at all acceptable to = write=20 drivers using the old style/method?
 
If these issues are better posted to = another=20 mailing list, please advise...
 
Thanks very much in = advance,
Jeff Brooke
 
------=_NextPart_000_0327_01C087B6.EFB52E40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 14:20:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (Postfix) with ESMTP id C15BB37B404; Fri, 26 Jan 2001 14:19:58 -0800 (PST) Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1]) by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id HAA95358; Sat, 27 Jan 2001 07:21:05 +0900 (JST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) Message-Id: <200101262221.HAA95358@shidahara1.planet.sci.kobe-u.ac.jp> To: Brooks Davis Cc: hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: PCI changes break HP Docking Station In-reply-to: Your message of "Fri, 26 Jan 2001 12:50:37 PST." <20010126125037.B28316@Odin.AC.HMC.Edu> Date: Sat, 27 Jan 2001 07:21:05 +0900 From: Takanori Watanabe Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010126125037.B28316@Odin.AC.HMC.Edu>, Brooks Davis $B$5$s$$$o$/(B: > >I plugged my HP Omnibook 4150 into my dock for the first time in a couple >months only to discover that I couldn't attach any of the PCI devices in >it. I'm running -current as of sometime in the last week or so. I traced >the problem to the new PCI code comitted six weeks ago. Specificaly: Would you send me raw memory block,by executing acpidump -o omnibook.dsdt? Device docking can be handled by ACPI. Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 14:45:55 2001 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 7FA1F37B699 for ; Fri, 26 Jan 2001 14:45:37 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA96309; Fri, 26 Jan 2001 23:45:33 +0100 (CET) (envelope-from 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: Zhiui Zhang Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: specify a different kernel to boot References: From: Dag-Erling Smorgrav Date: 26 Jan 2001 23:45:32 +0100 In-Reply-To: Zhiui Zhang's message of "Fri, 26 Jan 2001 16:21:27 -0500 (EST)" 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 Zhiui Zhang writes: > Is there a way to specify a kernel other than /kernel to boot from? I do > not want to do this manually, I want to put it into some configuration > file. Thanks, 'man loader' 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 Jan 26 14:59: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 8870F37B400; Fri, 26 Jan 2001 14:58:47 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0QNEZb01395; Fri, 26 Jan 2001 15:14:35 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101262314.f0QNEZb01395@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alexander Hausner Cc: Mike Smith , hackers@freebsd.org Subject: Re: Pthreads with sprintf/dtoa In-reply-to: Your message of "Fri, 26 Jan 2001 21:23:23 +0100." <01012621534501.00257@chuck.teleweb.at> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jan 2001 15:14:35 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > on Thu, 25 Jan 2001 Mike Smith wrote: > > > >__dtoa has static locals. Bad function, no biscuit. > = > I think this can be a serious problem for any threaded application, > I have not tested your patch yet, you think this is only a temporary > solution right? Have you commited this patch to current? Is somebody > else working on that? There are still serious problems; Tor pointed out that the Bigint = freelist probably needs protection too. Personally, I think the entire interface is totally bogus, and the = allocator should just call malloc. I don't have any benchmarks to test = printf speed though... -- = =2E.. 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 Jan 26 15: 5: 2 2001 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 54DD837B402; Fri, 26 Jan 2001 15:04:42 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0QN4gf12123; Fri, 26 Jan 2001 15:04:42 -0800 (PST) Date: Fri, 26 Jan 2001 15:04:42 -0800 From: Alfred Perlstein To: Mike Smith Cc: Alexander Hausner , hackers@FreeBSD.ORG Subject: Re: Pthreads with sprintf/dtoa Message-ID: <20010126150441.J26076@fw.wintelcom.net> References: <01012621534501.00257@chuck.teleweb.at> <200101262314.f0QNEZb01395@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101262314.f0QNEZb01395@mass.dis.org>; from msmith@FreeBSD.ORG on Fri, Jan 26, 2001 at 03:14:35PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mike Smith [010126 15:00] wrote: > > on Thu, 25 Jan 2001 Mike Smith wrote: > > > > > >__dtoa has static locals. Bad function, no biscuit. > > > > I think this can be a serious problem for any threaded application, > > I have not tested your patch yet, you think this is only a temporary > > solution right? Have you commited this patch to current? Is somebody > > else working on that? > > There are still serious problems; Tor pointed out that the Bigint > freelist probably needs protection too. > > Personally, I think the entire interface is totally bogus, and the > allocator should just call malloc. I don't have any benchmarks to test > printf speed though... This could also be solved by using pthread_getspecific(3) and friends to reduce the amount of malloc calls in persistant threads. Short lived threads might have to deal with some overhead, but long lived ones will be ok. -- -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 Jan 26 15:24:43 2001 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 6C51437B69F for ; Fri, 26 Jan 2001 15:24:26 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id E586E2B793; Fri, 26 Jan 2001 17:24:15 -0600 (CST) Date: Fri, 26 Jan 2001 17:24:15 -0600 From: Bill Fumerola To: "Koster, K.J." Cc: "'skywizard@time.net.my'" , freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Hacking (i tried not to make it lame) Message-ID: <20010126172415.L57121@elvis.mu.org> References: <59063B5B4D98D311BC0D0001FA7E4522026D7B63@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <59063B5B4D98D311BC0D0001FA7E4522026D7B63@l04.research.kpn.com>; from K.J.Koster@kpn.com on Fri, Jan 26, 2001 at 01:31:50PM +0100 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 26, 2001 at 01:31:50PM +0100, Koster, K.J. wrote: > I think Yahoo! is using still on 2.2.8. There are some people on this list > who work for Yahoo!, so you could try to drop them a line. I can imagine > that they are interested in softupdates. I'd imagine that just upgrading machines to recent versions of FreeBSD would be just as easy as trying to push out that kind of update. I'd encourage all others who are looking for softupdates in 2.2.8 to just upgrade to 4.2-{RELEASE,STABLE}. -- Bill Fumerola / billf@FreeBSD.org ps. not speaking for my employer, etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 15:30:37 2001 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 B0E2F37B401 for ; Fri, 26 Jan 2001 15:30:18 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id E55FE6A90D; Sat, 27 Jan 2001 10:00:15 +1030 (CST) Date: Sat, 27 Jan 2001 10:00:15 +1030 From: Greg Lehey To: Jim Sander Cc: hackers@FreeBSD.ORG Subject: Re: if_fxp driver info (which card then?) Message-ID: <20010127100015.G1948@wantadilla.lemis.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 jim@federation.addy.com on Fri, Jan 26, 2001 at 09:47:38AM -0500 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, 26 January 2001 at 9:47:38 -0500, Jim Sander wrote: >>> Linux people avoid the EtherExpress because they think something is >>> wrong with the card. > >> Intel EtherExpress Pro 10/100B cards in FreeBSD > > These cards work well in our many 3.x and 4.x systems. > > But I just built up a Redhat 6.2 box with one, and all seemed to be > working fine, but after a while I started having various problems starting > net services. The box would boot, but often would "hang" indefinitely when > "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro > NIC, new MB, different RAM, other cables, everything, but no change. Yes, these are exactly the problems I've heard of. > After I switched to a linksys NIC, voila- everything worked > without a problem. (so far) Of course the Intel NICs still work > perfectly when put into a spare BSD system. So it's *not* that the > cards themselves are unreliable. Perhaps the drivers controlling > them? Perhaps a weird MB/NIC conflict of some sort? As I mentioned earlier, it's the drivers (two different ones) themselves. Linux people have different opinions about which is worse, but they do agree that both are pretty bad. That's why I've been saying that we shouldn't be looking at porting them. 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 Jan 26 15:39: 2 2001 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 16B7F37B6A4; Fri, 26 Jan 2001 15:38:46 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f0QNch419872; Fri, 26 Jan 2001 15:38:43 -0800 Date: Fri, 26 Jan 2001 15:38:42 -0800 From: Brooks Davis To: Takanori Watanabe Cc: hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: PCI changes break HP Docking Station Message-ID: <20010126153842.A19356@Odin.AC.HMC.Edu> References: <20010126125037.B28316@Odin.AC.HMC.Edu> <200101262221.HAA95358@shidahara1.planet.sci.kobe-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200101262221.HAA95358@shidahara1.planet.sci.kobe-u.ac.jp>; from takawata@shidahara1.planet.sci.kobe-u.ac.jp on Sat, Jan 27, 2001 at 07:21:05AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 07:21:05AM +0900, Takanori Watanabe wrote: > Would you send me raw memory block,by executing acpidump -o omnibook.dsdt? > Device docking can be handled by ACPI. It's now online at: http://www.one-eyed-alien.net/~brooks/FreeBSD/dock/omnibook.dsdt I'd be happy to test any docking related ACPI work. -- 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 Fri Jan 26 16:29: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by hub.freebsd.org (Postfix) with ESMTP id 580C737B69D; Fri, 26 Jan 2001 16:28:45 -0800 (PST) Received: from asiale (asiale.nttmcl.com [216.69.69.78]) by alicia.nttmcl.com (8.10.1/8.10.1) with SMTP id f0R0Sij01286; Fri, 26 Jan 2001 16:28:44 -0800 (PST) From: "Eugene M. Kim" To: "Kris Kennaway" , "Felix-Antoine Paradis" Cc: Subject: RE: IDE CDRW Date: Fri, 26 Jan 2001 16:25:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-reply-to: <20010124185305.J45221@citusc17.usc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One more similar question: Does/will FreeBSD support ATAPI CD-R(W) drives in disk-at-once mode, perhaps using burncd(1)? I wanted to burn some audio CDs in that manner but burncd on 4-stable didn't support DAO writing. Thank you, Eugene -----Original Message----- From: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Kris Kennaway Sent: Wednesday, January 24, 2001 6:53 PM To: Felix-Antoine Paradis Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: IDE CDRW On Wed, Jan 24, 2001 at 05:04:23PM -0500, Felix-Antoine Paradis wrote: > Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? It supports them just fine.. Perhaps your question was really "does FreeBSD emulate a SCSI interface to ATAPI drives?", in which case the answer is "no". They are still fully functional however. Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@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 Jan 26 16:35:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from obsecurity.org (adsl-64-165-226-72.dsl.lsan03.pacbell.net [64.165.226.72]) by hub.freebsd.org (Postfix) with ESMTP id 9EB7637B6A0; Fri, 26 Jan 2001 16:35:39 -0800 (PST) Received: by obsecurity.org (Postfix, from userid 1000) id D1F48BA4A3; Fri, 26 Jan 2001 16:36:06 -0800 (PST) Date: Fri, 26 Jan 2001 16:36:06 -0800 From: Kris Kennaway To: "Eugene M. Kim" Cc: Kris Kennaway , Felix-Antoine Paradis , freebsd-hackers@FreeBSD.ORG Subject: Re: IDE CDRW Message-ID: <20010126163606.A19005@azathoth.cthul.hu> References: <20010124185305.J45221@citusc17.usc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gene@nttmcl.com on Fri, Jan 26, 2001 at 04:25:15PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 26, 2001 at 04:25:15PM -0800, Eugene M. Kim wrote: > One more similar question: Does/will FreeBSD support ATAPI CD-R(W) > drives in disk-at-once mode, perhaps using burncd(1)? I wanted to burn > some audio CDs in that manner but burncd on 4-stable didn't support DAO > writing. Don't know; you'd have to do some research yourself into this one, I think. Kris --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6chf1Wry0BWjoQKURAmm4AJkBrgzPpDbhM2KfRvOJjuA2y6r9eQCgwT4p ewidHJ+mu498pxE46ABAYTU= =kiP+ -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 17:42:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by hub.freebsd.org (Postfix) with ESMTP id E276537B401 for ; Fri, 26 Jan 2001 17:41:53 -0800 (PST) Received: from localhost (s340-modem1762.dial.xs4all.nl [194.109.166.226]) by smtp3.xs4all.nl (8.9.3/8.9.3) with SMTP id CAA27933 for ; Sat, 27 Jan 2001 02:41:48 +0100 (CET) Message-ID: <3A7226D6.41C67EA6@xs4all.nl> Date: Sat, 27 Jan 2001 01:39:34 +0000 From: "W.H.Scholten" Organization: . X-Mailer: Mozilla 3.04 (X11; I; FreeBSD 4.1-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: More error message changes? (Re: mkdir diff) References: <3A5C843C.794BDF32@xs4all.nl> <20010111132509.J7240@fw.wintelcom.net> <3A5EE6B1.41C67EA6@xs4all.nl> <20010112081422.U7240@fw.wintelcom.net> <3A6025F1.794BDF32@xs4all.nl> <20010113191432.G7240@fw.wintelcom.net> <20010114041041.M7240@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There were a few other places where I noticed (long time ago, but I've now written it all down) somewhat strange messages: mkdir / gives: mkdir: /: Is a directory whereas mkdir /usr gives: mkdir: /usr: File exists Is this a bug in the kernel to return EISDIR in case of "/" or is it a 'feature'? Further, various other programs have a variant of the message weirdness that mkdir had, though this is defensible in some cases as another message is added, e.g. in sh: echo "aa" >/tmp/a/b gives: cannot create /tmp/a/b: directory nonexistent. The other cases are present in rm, touch, chmod, cat, ls, cp, mv (possible more...). The messages are all ok if one remembers the exact meaning of the error message as decribed in intro(2) but the short messages that strerror et al produce are misleading when one does not expand further (as opposed to e.g. the sh example) For the following I assume /tmp/e is a file, and /tmp/a does not exist. rm /tmp/e/f gives: rm: /tmp/e/f: Not a directory (better: rm: /tmp/e: Not a directory) touch /tmp/a/b: touch: /tmp/a/b: No such file or directory (better: touch: /tmp/a: No such file or directory, as touch is supposed to create the file if it doesn't exist) touch /tmp/e/f: touch: /tmp/e/f: Not a directory (better: touch: /tmp/e: Not a directory) chmod +x /tmp/e/f: chmod: /tmp/e/f: Not a directory (better: chmod: /tmp/e: Not a directory) cat /tmp/e/f: cat: /tmp/e/f: Not a directory (better: cat: /tmp/e: Not a directory) ls /tmp/e/f: ls: /tmp/e/f: Not a directory (better: ls: /tmp/e: Not a directory) cp /tmp/e/f f: cp: /tmp/e/f: Not a directory (better: cp: /tmp/e: Not a directory) mv /tmp/e/f f mv: rename /tmp/e/f to f: Not a directory if g does not exist: mv /tmp/e/f g/f mv: rename /tmp/e/f to g/f: Not a directory (not sure what do to here, 2 directories, so check/mention both with an expanded message?) Of course, these messages can changed by changing: 1. the messages that go with errno, e.g. "Not a directory" to "Part of the directory name is not a directory" or something 2. check for these cases in the given programs. 3. expand the error message as sh does. I actually like the idea of making the messages that strerror produces more verbose but maybe everyone feels the current messages should stay as they are standard?. Regards, Wouter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 18: 3:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id 3BD7737B400 for ; Fri, 26 Jan 2001 18:03:01 -0800 (PST) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id SAA31833 for ; Fri, 26 Jan 2001 18:02:50 -0800 (PST) (envelope-from rh@matriplex.com) Date: Fri, 26 Jan 2001 18:02:50 -0800 (PST) From: Richard Hodges To: freebsd-hackers@FreeBSD.ORG Subject: NEWBUS: multiple calls needed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, all! I am writing a device driver for a device that has three separate memory areas (plus a 256-byte IO block). At first glance, it would seem that the correct thing would be something like: for(x = 0; x < 3; x++) { device->mem[x] = bus_alloc_resource(dev, SYS_RES_MEMORY, &device->rid_mem[x], 0, ~0, 1, RF_ACTIVE); if(device->mem[x] == NULL) FAIL; device->bustag[x] = rman_get_bustag(device->mem[x]); device->bushandle[x] = rman_get_bushandle(device->mem[x]); device->virt_addr[x] = rman_get_virtual(device->mem[x]); } The memory areas "appear" to be fixed relative to each other: mem1 == base + 0x000000 (size==0x200000) mem2 == base + 0x201000 (size==0x000100) mem3 == base + 0x203000 (size==0x000400) So of course, it is tempting to wonder whether it is really neccessary to allocate three newbus entities for them. On the other hand, I have to believe that the BIOS has already set the base and sizes of these areas, and it would be a really bad idea to pretend that they are a single (say 3-meg) resource. I think I will just go ahead with allocating three separate resources for them, but I would be very interested in other opinions. Thanks, -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 18:53:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 6A7F137B402 for <freebsd-hackers@freebsd.org>; Fri, 26 Jan 2001 18:53:01 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-144.nnj.dialup.bellatlantic.net [151.198.117.144]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id VAA14212; Fri, 26 Jan 2001 21:52:58 -0500 (EST) Message-ID: <3A723805.D01CD375@bellatlantic.net> Date: Fri, 26 Jan 2001 21:52:53 -0500 From: Sergey Babkin <babkin@bellatlantic.net> X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: GLOBALLINK2001@aol.com Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Hacking (i tried not to make it lame) References: <8c.189517c.27a24307@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG GLOBALLINK2001@aol.com wrote: > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System > > that is about it the rest really is a blur and is so complex and huge i have > no idea where to begin hope i wasn't to lame guys :-) Better start with some books on general OS design. For example, Tannenbaum's or something like this. The 4.4BSD book goes into details expecting that you have the high-level knowledge of things, so without that knowledge it would be very difficult to read. Another prerequisite would be a book on general Unix systems programming, and by the same reason: reading about how things are implemented is much easier if you already know what these things being implemented are. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 19:43:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 121BB37B401 for <hackers@freebsd.org>; Fri, 26 Jan 2001 19:43:24 -0800 (PST) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id TAA10433 for <hackers@freebsd.org>; Fri, 26 Jan 2001 19:43:23 -0800 (PST) Message-ID: <3A7243BC.491C604E@isi.edu> Date: Fri, 26 Jan 2001 19:42:52 -0800 From: Lars Eggert <larse@ISI.EDU> Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: hackers@freebsd.org Subject: capturing an early kernel dump Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms288C4A70ECD9DEB5AF2ACE7F" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a cryptographically signed message in MIME format. --------------ms288C4A70ECD9DEB5AF2ACE7F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit How do I capture an early kernel dump (before rc executes and sets dumpdev)? The dump partition used to be an option in the kernel config file, but that seems to have changed in 3.X or 4.X. Thanks, Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms288C4A70ECD9DEB5AF2ACE7F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDEyNzAzNDI1MlowIwYJKoZIhvcNAQkEMRYE FGtb6aQpKb7kG4MFklg2/g3ZSzgGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAoTmUICAOJj9NDRuaz1ktzUPWmHsNEoh0U5xdMLOsqR096++ZcU23 O7IsKCbISr1m+oDzk7uT2Nkokz9ln/Yl7myFUMXMR3ld8ClNeRVq4l3I1aziAwyg24buAWms tyjQE9wn6PLecgpJQIjCoaNkTjzOCN9AwkgHdIXo13+eXKc= --------------ms288C4A70ECD9DEB5AF2ACE7F-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 21:13:31 2001 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 6850537B400 for <freebsd-hackers@FreeBSD.ORG>; Fri, 26 Jan 2001 21:13:14 -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 f0R5D7h17509; Fri, 26 Jan 2001 22:13:11 -0700 Message-Id: <200101270513.f0R5D7h17509@chopper.Poohsticks.ORG> To: Richard Hodges <rh@matriplex.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NEWBUS: multiple calls needed? In-reply-to: Your message of "Fri, 26 Jan 2001 18:02:50 PST." <Pine.BSF.4.10.10101261750060.31475-100000@mail.matriplex.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17505.980572386.1@chopper.Poohsticks.ORG> Date: Fri, 26 Jan 2001 22:13:07 -0700 From: Drew Eckhardt <drew@PoohSticks.ORG> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <Pine.BSF.4.10.10101261750060.31475-100000@mail.matriplex.com>, rh@m atriplex.com writes: >I think I will just go ahead with allocating three separate resources >for them, but I would be very interested in other opinions. The different regions on a device often have different functionality which may allow/call for different memory access characteristics. For instance, you probably want attempts to write to onboard ROM to fault. You might mark to allow prefetch on large on-device buffers where reads have no side effects. Beyond that, if a specification does not prohibit a behavior eventually you'll run into a system that implements it because it seems to make sense or is just convienant. For example, if I thought about accomodating a systems where virtual and physical addresses matched (the Linux kernel used to do this), I might pad everything to page boundaries and skip a page between entries to make it easier to catch overruns. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 26 22:44:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id C51AE37B402 for <hackers@FreeBSD.ORG>; Fri, 26 Jan 2001 22:44:30 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA664856; Sat, 27 Jan 2001 01:44:24 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: <p05010400b6981565909b@[128.113.24.47]> In-Reply-To: <4.3.0.20010126193228.06e2a200@bluesun> References: <4.3.0.20010126193228.06e2a200@bluesun> Date: Sat, 27 Jan 2001 01:44:23 -0500 To: mouss <usebsd@free.fr>, hackers@FreeBSD.ORG From: Garance A Drosihn <drosih@rpi.edu> Subject: Re: [kernel patch] fcntl(...) to close many descriptors Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 7:32 PM +0100 1/26/01, mouss wrote: >Hi, > >I've modified the kernel to add F_CLOSEM functionality to fcntl. >(I've seen this in some AIX docs). > >The purpose is allow a process to close all its filedescriptors >starting from a given value without issuing thousands of close() >syscalls. This may be used for programs that daemonize themselves >(or one of their children) after some amount of work, when many >fd's has been opened. The program would simply call > fcntl(minclose, F_CLOSEM, 0); > >The patch concerns /sys/kern/kern_descriptors.c and fcntl.h >(and of course the corresponding manpage). > >Is this functionality worth inclusion in the kernel (or should >I throw away the patch)? are there any kind souls to review the >patch? In a number of programs, I've seen references to a "closeallfds" routine, which seems to do this. Right now (at 1am), the only program I can think of which did this is 'lpr', and it has it's own implementation of closeallfds. So in that case it isn't a system routine, and it just loops thru getdtablesize() fd's closing them all. On the other hand, I seem to remember this being done (in some other program, if not in lpr) because closeallfds *is* a system routine in some place or another. The intent of closeallfds is the same as what you have implemented, as it is: void closeallfds(int start); While I understand that defining a new routine is more work than just adding a parameter to an existing routine, I do think it is more appropriate to have that new routine than to use fcntl for this. The description for fcntl says the first parameter is: a descriptor to be operated on by 'cmd' as described below. For the proposed F_CLOSEM command, it does not operate on the GIVEN fd, it operates on a whole bunch of OTHER fd's. This means that a program which calls fcntl with a cmd-argument which is different than the programmer thinks is being passed could cause some pretty painful-to-debug errors in sections of the program which have nothing to do with the section that has the bug. Of the various operating systems I use, none of them seem to actually have a closeallfds, but maybe someone else will remember where it comes from. Certainly it would be nice to have this capability implemented somewhere in the system level, where some useful optimization could be done. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 0:44:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 17D8A37B6A7; Sat, 27 Jan 2001 00:44:28 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id JAA79495; Sat, 27 Jan 2001 09:44:13 +0100 (CET) (envelope-from sos) From: Soren Schmidt <sos@freebsd.dk> Message-Id: <200101270844.JAA79495@freebsd.dk> Subject: Re: IDE CDRW In-Reply-To: <ACECIGEBKAHJMMMDHIMPKELOCEAA.gene@alicia.nttmcl.com> from "Eugene M. Kim" at "Jan 26, 2001 04:25:15 pm" To: gene@nttmcl.com (Eugene M. Kim) Date: Sat, 27 Jan 2001 09:44:12 +0100 (CET) Cc: kris@FreeBSD.ORG (Kris Kennaway), reel@idemnia.ath.cx (Felix-Antoine Paradis), freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Eugene M. Kim wrote: > One more similar question: Does/will FreeBSD support ATAPI CD-R(W) > drives in disk-at-once mode, perhaps using burncd(1)? I wanted to burn > some audio CDs in that manner but burncd on 4-stable didn't support DAO > writing. I'm working on it, but currently I have little time to spend on it though... -Søren "MrATA" Schmidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 4: 7:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (pool212-tch-1.Sofia.0rbitel.net [212.95.170.212]) by hub.freebsd.org (Postfix) with SMTP id 863B537B400 for <hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 04:07:33 -0800 (PST) Received: (qmail 2693 invoked by uid 1000); 27 Jan 2001 12:06:02 -0000 Date: Sat, 27 Jan 2001 14:06:02 +0200 From: Peter Pentchev <roam@orbitel.bg> To: mouss <usebsd@free.fr> Cc: Archie Cobbs <archie@dellroad.org>, Alwyn Goodloe <agoodloe@gradient.cis.upenn.edu>, hackers@FreeBSD.ORG Subject: Re: packet redirection design problem [Divert Sockets & Fragmentation revisited] Message-ID: <20010127140602.B328@ringworld.oblivion.bg> Mail-Followup-To: mouss <usebsd@free.fr>, Archie Cobbs <archie@dellroad.org>, Alwyn Goodloe <agoodloe@gradient.cis.upenn.edu>, hackers@FreeBSD.ORG References: <Pine.SOL.4.21.0101252258280.9067-100000@gradient.cis.upenn.edu> <200101261843.KAA09789@curve.dellroad.org> <4.3.0.20010126202555.06e24350@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.0.20010126202555.06e24350@pop.free.fr>; from usebsd@free.fr on Fri, Jan 26, 2001 at 09:00:54PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 26, 2001 at 09:00:54PM +0100, mouss wrote: > "IP filtering engines" that do something to packet based on rule > matching have a problem when fragmentation comes to play. > > In the case of a "packet redirector' such as divert, the problem is that > only the first fragment will match the rule, if the rule uses ports or > whatever info contained in the payload. > > The problem occurs if the packet (that should match) is subject to change > by the engine (either redirection, nat, blocking, ...) > > IP Filter handles such situation with specific code. > > It would be a nice thing if this is added to standard code so that packet > filters > writers do not need to add their own. > > Any opinions? Hmm isn't this exactly the issue that's addressed in the Linux kernel by the 'always reassemble the whole packet before processing' config option? Wouldn't this be good/desired behavior? Or am I on crack - is FreeBSD already doing this? From this discussion I gather it's not.. G'luck, Peter -- This sentence no verb. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 7:51:51 2001 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 77C4837B400 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 07:51:33 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA01542; Sat, 27 Jan 2001 16:51:28 +0100 (CET) (envelope-from 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: Alfred Perlstein <bright@wintelcom.net> Cc: GLOBALLINK2001@aol.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Hacking (i tried not to make it lame) References: <8c.189517c.27a24307@aol.com> <20010126011053.C26076@fw.wintelcom.net> From: Dag-Erling Smorgrav <des@ofug.org> Date: 27 Jan 2001 16:51:28 +0100 In-Reply-To: Alfred Perlstein's message of "Fri, 26 Jan 2001 01:10:53 -0800" Message-ID: <xzpg0i5gfi7.fsf@flood.ping.uio.no> Lines: 31 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 Alfred Perlstein <bright@wintelcom.net> writes: > * GLOBALLINK2001@aol.com <GLOBALLINK2001@aol.com> [010125 19:04] wrote: > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > > on getting The Design and Implementation of the 4.4BSD Operating System > > Well more than 'basic' hopefully. :) > > Good choice on a book, others to look at are: > "UNIX Internals 'the new frontiers'" Vahalia > "The Basic Kernel Source Secrets" Jolitz I haven't read Vahalia, so I can't comment on that one, but both McKusick et al. and Jolitz are seriously outdated - you can basically forget anything they tell you about memory management (particularly virtual memory), interrupt handling, spls, and probably scheduling as well; and none of them tell you much about writing device drivers (which is what kernel newbies most often want to do). On the other hand, the Daemon book (McKusick et al.) still has some fairly relevant sections (some of part 2, about half of part 3 and most of part 4), and does a good job of demystifying the kernel on a psychological level, i.e. teaching you that most of it really isn't deep voodoo and you can understand it if you try. In my experience, this psychological block is a much bigger obstacle to overcome than actual technical complexity. (hmm, I must remember to drop by Mustang Jack next time I'm in NYC) 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 Sat Jan 27 8: 5:28 2001 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 F3C0837B400 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 08:05:10 -0800 (PST) Received: from newsguy.com (p58-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.59]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id BAA25515; Sun, 28 Jan 2001 01:04:56 +0900 (JST) Message-ID: <3A72F112.19944902@newsguy.com> Date: Sun, 28 Jan 2001 01:02:26 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Dag-Erling Smorgrav <des@ofug.org> Cc: Zhiui Zhang <zzhang@cs.binghamton.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: specify a different kernel to boot References: <Pine.SOL.4.21.0101261620010.1042-100000@onyx> <xzpzogej5kj.fsf@flood.ping.uio.no> 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: > > Zhiui Zhang <zzhang@cs.binghamton.edu> writes: > > Is there a way to specify a kernel other than /kernel to boot from? I do > > not want to do this manually, I want to put it into some configuration > > file. Thanks, > > 'man loader' The loader.conf(5) man page is probably more appropriate. Or just check /boot/defaults/loader.conf. Everyone else does. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 9: 0:57 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from server.bitmcnit.bryansk.su (bitmcnit.bryansk.ru [195.239.213.9]) by hub.freebsd.org (Postfix) with ESMTP id 11F1237B401 for <hackers@freebsd.org>; Sat, 27 Jan 2001 09:00:34 -0800 (PST) Received: (from uucp@localhost) by server.bitmcnit.bryansk.su (8.9.3/8.9.3) with UUCP id TAA09357 for hackers@freebsd.org; Sat, 27 Jan 2001 19:49:52 +0300 Received: (from alex@localhost) by kapran.bitmcnit.bryansk.su (8.11.1/8.11.1) id f0RGcQR06640 for hackers@freebsd.org; Sat, 27 Jan 2001 19:38:26 +0300 (MSK) (envelope-from alex@kapran.bitmcnit.bryansk.su) Date: Sat, 27 Jan 2001 19:38:25 +0300 From: Alex Kapranoff <alex@kapran.bitmcnit.bryansk.su> To: hackers@freebsd.org Subject: FreeBSD specific strftime(3) format specifiers Message-ID: <20010127193824.A6332@kapran.bitmcnit.bryansk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi to all. gcc supports strftime format string checking and issues a warning when it encounters some unknown format specifier. FreeBSD strftime has several additional format chars which gcc knows nothing about. This can easily be seen when compiling /usr/src/usr.sbin/pw: pw_user.c:1175: warning: unknown conversion type character `f' in format pw_user.c:1177: warning: unknown conversion type character `f' in format Are there chances that this could be fixed? I suppose, the patches should be submitted to gcc developers and the changes will get into our tree on next gcc source import? -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 3 weeks in the brand new millenium... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 9:51:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by hub.freebsd.org (Postfix) with ESMTP id 58FEC37B400 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 09:51:35 -0800 (PST) Received: from mini.acl.lanl.gov (root@mini.acl.lanl.gov [128.165.147.34]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id KAA7552831 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 10:51:33 -0700 (MST) Received: from localhost (rminnich@localhost) by mini.acl.lanl.gov (8.9.3/8.8.8) with ESMTP id KAA04192 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 10:51:33 -0700 X-Authentication-Warning: mini.acl.lanl.gov: rminnich owned process doing -bs Date: Sat, 27 Jan 2001 10:51:33 -0700 (MST) From: Ronald G Minnich <rminnich@lanl.gov> X-Sender: <rminnich@mini.acl.lanl.gov> To: <freebsd-hackers@FreeBSD.ORG> Subject: Re: Kernel Hacking (i tried not to make it lame) In-Reply-To: <xzpg0i5gfi7.fsf@flood.ping.uio.no> Message-ID: <Pine.LNX.4.30.0101271050440.4161-100000@mini.acl.lanl.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I still think a really neat source for kernel hacking is Chuck Cranor's PhD thesis. He describes the kernel equivalent of open-heart surgery: replacing the old VM with a new one, while keep the kernel alive. Neat stuff. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 9:55:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id 782AC37B400 for <freebsd-hackers@freebsd.org>; Sat, 27 Jan 2001 09:55:03 -0800 (PST) Received: from HSE-QuebecCity-ppp82790.qc.sympatico.ca ([64.229.241.185]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010127175502.FRTD6682.tomts7-srv.bellnexxia.net@HSE-QuebecCity-ppp82790.qc.sympatico.ca> for <freebsd-hackers@freebsd.org>; Sat, 27 Jan 2001 12:55:02 -0500 Date: Sat, 27 Jan 2001 12:57:09 -0500 (EST) From: Felix-Antoine Paradis <reel@idemnia.ath.cx> To: <freebsd-hackers@freebsd.org> Subject: Need help - emergency! Message-ID: <Pine.BSF.4.31.0101271255160.642-100000@idemnia.ath.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hey We got a problem booting our server. Someone added some ips with x.x.x.y y=>255 and it's not booting. We rebooted in single-user mode and we're not able to make any changes to the rc.conf. It says the filesystem is read-only. Can you help us? Thank's! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Felix-Antoine Paradis . cell: 1-418-261-0865 . . IRC: reel @ DALnet . job: Idemnia Network . . Email: reel@sympatico.ca . *** www.FreeBSD.org *** . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ."The power of man has grown in every sphere, except . . over himself" . . --Sir Winston Churchill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBOnML+hcIKY4ZDBRpAQEwbQQAhTjr/IkEP4qEZy9H8/FD5y4PTVwLO4dy zjQv67KBxHX4lN+a65xmnHOjMT0wJ59t8J5lq91Q850o1iOpM1OB3MDDGnhLg1CG mDC/NCrCRY/GpVkn7NTeKlWGgWstEe3di14PPNY8kYNtx0Av2/GvY2e7d7NtIrCi R2szPwR9qiI= =mHax -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 9:57:50 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7529637B401 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 09:57:30 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA30889; Sat, 27 Jan 2001 09:57:21 -0800 Date: Sat, 27 Jan 2001 09:57:22 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> Reply-To: mjacob@feral.com To: Felix-Antoine Paradis <reel@idemnia.ath.cx> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help - emergency! In-Reply-To: <Pine.BSF.4.31.0101271255160.642-100000@idemnia.ath.cx> Message-ID: <Pine.BSF.4.21.0101270956120.19716-100000@beppo.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wrong list to send this too... it should either be -stable or -current- you didn't say which system it was. try mount / or mount -w / On Sat, 27 Jan 2001, Felix-Antoine Paradis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Hey > We got a problem booting our server. Someone added some ips with > x.x.x.y y=>255 and it's not booting. We rebooted in single-user mode and > we're not able to make any changes to the rc.conf. It says the filesystem > is read-only. Can you help us? > > Thank's! > > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > . Felix-Antoine Paradis . cell: 1-418-261-0865 . > . IRC: reel @ DALnet . job: Idemnia Network . > . Email: reel@sympatico.ca . *** www.FreeBSD.org *** . > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > ."The power of man has grown in every sphere, except . > . over himself" . > . --Sir Winston Churchill . > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: noconv > > iQCVAwUBOnML+hcIKY4ZDBRpAQEwbQQAhTjr/IkEP4qEZy9H8/FD5y4PTVwLO4dy > zjQv67KBxHX4lN+a65xmnHOjMT0wJ59t8J5lq91Q850o1iOpM1OB3MDDGnhLg1CG > mDC/NCrCRY/GpVkn7NTeKlWGgWstEe3di14PPNY8kYNtx0Av2/GvY2e7d7NtIrCi > R2szPwR9qiI= > =mHax > -----END PGP SIGNATURE----- > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 10: 6:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chuck.teleweb.at (TK158249.telekabel.at [195.34.158.249]) by hub.freebsd.org (Postfix) with ESMTP id 6BAFB37B401 for <freebsd-hackers@freebsd.org>; Sat, 27 Jan 2001 10:06:28 -0800 (PST) Received: by chuck.teleweb.at (8.11.1/8.11.1) id f0RI6Cl00298; Sat, 27 Jan 2001 19:06:12 +0100 (MET) (envelope-from alh) From: Alexander Hausner <alh@teleweb.at> To: Felix-Antoine Paradis <reel@idemnia.ath.cx>, <freebsd-hackers@freebsd.org> Subject: Re: Need help - emergency! Date: Sat, 27 Jan 2001 19:01:37 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <Pine.BSF.4.31.0101271255160.642-100000@idemnia.ath.cx> In-Reply-To: <Pine.BSF.4.31.0101271255160.642-100000@idemnia.ath.cx> MIME-Version: 1.0 Message-Id: <01012719061100.00262@chuck.teleweb.at> Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG on Sat, 27 Jan 2001 Felix-Antoine Paradis wrote: >It says the filesystem >is read-only. Can you help us? mount -uw /=20 should help. Alex --=20 Email: Alexander Hausner <alh@teleweb.at> NIC-HDL: AH194-RIPE PGP Key ID: 1024/D272F9B5 PGP Key fingerprint: 45 CB 7A 6A 24 81 71 14 CE 11 27 53 36 63 AD 1C PGP Public-Key: https://www.luga.or.at/pgppubkeys/D272F9B5.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 12:16:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bulwark.switch.com (bulwark.switch.com [206.181.77.34]) by hub.freebsd.org (Postfix) with SMTP id 454AA37B400; Sat, 27 Jan 2001 12:16:42 -0800 (PST) Received: by bulwark.switch.com; id PAA24023; Sat, 27 Jan 2001 15:16:33 -0500 Received: from dhcp103-172-16-3.switch.com(172.16.3.122) by bulwark.switch.com via smap (V5.5) id xma024021; Sat, 27 Jan 01 15:16:06 -0500 Received: (from breaker@localhost) by dhcp103-172-16-3.switch.com (8.11.1/8.11.1) id f0RKFip07174; Sat, 27 Jan 2001 15:15:44 -0500 (EST) (envelope-from breaker) Date: Sat, 27 Jan 2001 15:15:43 -0500 From: Trent Nelson <tpnelson@switch.com> To: hackers@FreeBSD.org Cc: jlemon@FreeBSD.org Subject: kevent signal handling question. Message-ID: <20010127151543.B2890@dhcp103-172-16-3.switch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd just like to confirm that my interpretation of how kevent() can be made to handle signals is correct. From kqueue(2): ... EVFILT_SIGNAL Takes the signal number to monitor as the identifier and returns when the given signal is delivered to the process. This coexists with the signal() and sigaction() facilities, and has a lower precedence. The filter will record all attempts to deliver a signal to a process, even if the signal has been marked as SIG_IGN. [...] So if I set all appropriate signals I want to monitor to SIG_IGN, I can essentially have kevent() becoming the primary signal handling mechanism in my program? Thanks in advance. Regards, Trent. -- Trent Nelson - Software Engineer - tpnelson@switch.com "A man with unlimited enthusiasm can achieve almost anything." --unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 12:37:13 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id E16FC37B401; Sat, 27 Jan 2001 12:36:55 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0RKa7172632; Sat, 27 Jan 2001 14:36:07 -0600 (CST) (envelope-from jlemon) Date: Sat, 27 Jan 2001 14:36:07 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Trent Nelson <tpnelson@switch.com> Cc: hackers@FreeBSD.org, jlemon@FreeBSD.org Subject: Re: kevent signal handling question. Message-ID: <20010127143607.T29115@prism.flugsvamp.com> References: <20010127151543.B2890@dhcp103-172-16-3.switch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010127151543.B2890@dhcp103-172-16-3.switch.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 03:15:43PM -0500, Trent Nelson wrote: > > I'd just like to confirm that my interpretation of how kevent() > can be made to handle signals is correct. > > From kqueue(2): > > ... > > EVFILT_SIGNAL > Takes the signal number to monitor as the identifier and returns when > the given signal is delivered to the process. This coexists with the > signal() and sigaction() facilities, and has a lower precedence. The > filter will record all attempts to deliver a signal to a process, even > if the signal has been marked as SIG_IGN. [...] > > So if I set all appropriate signals I want to monitor to SIG_IGN, I > can essentially have kevent() becoming the primary signal handling > mechanism in my program? Correct. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 12:51:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (c228380-a.sfmissn1.sfba.home.com [24.20.90.44]) by hub.freebsd.org (Postfix) with ESMTP id 17C0037B404 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 12:51:37 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0RKpax01005; Sat, 27 Jan 2001 12:51:37 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101272051.f0RKpax01005@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Richard Hodges <rh@matriplex.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NEWBUS: multiple calls needed? In-reply-to: Your message of "Fri, 26 Jan 2001 18:02:50 PST." <Pine.BSF.4.10.10101261750060.31475-100000@mail.matriplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Jan 2001 12:51:36 -0800 From: Mike Smith <msmith@freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The memory areas "appear" to be fixed relative to each other: > mem1 == base + 0x000000 (size==0x200000) > mem2 == base + 0x201000 (size==0x000100) > mem3 == base + 0x203000 (size==0x000400) > > So of course, it is tempting to wonder whether it is really neccessary > to allocate three newbus entities for them. On the other hand, I have > to believe that the BIOS has already set the base and sizes of these > areas, and it would be a really bad idea to pretend that they are a > single (say 3-meg) resource. Just because *your* BIOS puts them there doesn't mean that another one won't put them somewhere else. 8) -- ... 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 Sat Jan 27 12:52:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by hub.freebsd.org (Postfix) with ESMTP id E9D7637B69E for <hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 12:51:58 -0800 (PST) Received: from dades.chilali.net (paris11-nas3-45-84.dial.proxad.net [212.27.45.84]) by postfix2-2.free.fr (Postfix) with SMTP id 711006B747; Sat, 27 Jan 2001 21:51:50 +0100 (CET) From: mouss <usebsd@free.fr> To: Peter Pentchev <roam@orbitel.bg> Subject: Re: packet redirection design problem [Divert Sockets & Fragmentation revisited] Date: Sat, 27 Jan 2001 22:36:37 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: Archie Cobbs <archie@dellroad.org>, Alwyn Goodloe <agoodloe@gradient.cis.upenn.edu>, hackers@FreeBSD.ORG References: <Pine.SOL.4.21.0101252258280.9067-100000@gradient.cis.upenn.edu> <4.3.0.20010126202555.06e24350@pop.free.fr> <20010127140602.B328@ringworld.oblivion.bg> In-Reply-To: <20010127140602.B328@ringworld.oblivion.bg> MIME-Version: 1.0 Message-Id: <01012722503600.00529@dades.chilali.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG the "defrag all" feature of Linux solves the discussed problem, but can be improved. We do not need to defrag the packets. We just need to queue them. and, when the first frag has been received, we only need to save the informations necessary for filtering (ip header stuff + ports for TCP/UDP and other things for icmp or ....) the algo might be something like: - if packet is not frag, do as usual and skip the frag stuff - find packet in fragments list - if not found, create a new list - if the list contains the infos on the ports (I am restricting myself to tcp/udp for simplicity, but any kind of infos may be used), then the packet is ready for filtering: the rule may be found and applied to the packet. we do not need to queue it. * if the packet is the last one, delete the list * if frag timeout, delete the list - if not, then - if packet contains the infos (first frag), then store them and find the filtering rule and apply it for all the packets queued in the list. - else, queue packet So the code would be like the reassembly one, except that: - packets are "delivered" (passed to filters and the rest of ip_input) when the first frag is received (I am assuming that the first frag contains the infos necessary for filtering). - to handle next frags, the infos (ip header stuff and ports or so) are still kept in the list. With this method, if fragments come in order, packets are never queued. (Note that linux is unfriendly here: it sends frags in reverse order...). cheers, mouss On Sat, 27 Jan 2001, Peter Pentchev wrote: > > Hmm isn't this exactly the issue that's addressed in the Linux kernel > by the 'always reassemble the whole packet before processing' config > option? Wouldn't this be good/desired behavior? > > Or am I on crack - is FreeBSD already doing this? From this discussion > I gather it's not.. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 12:52:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from webpimps.net (cc889338-a.slbch1.occa.home.com [24.0.207.185]) by hub.freebsd.org (Postfix) with ESMTP id 82D2037B6A7 for <freebsd-hackers@freebsd.org>; Sat, 27 Jan 2001 12:51:59 -0800 (PST) Received: from WorldClient [127.0.0.1] by webpimps.net [127.0.0.1] with SMTP (MDaemon.v3.1.2.R) for <freebsd-hackers@freebsd.org>; Sat, 27 Jan 2001 12:53:55 -0800 Date: Sat, 27 Jan 2001 12:53:54 -0800 From: "Aaron" <click46@webpimps.net> To: freebsd-questions@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Thread-safe X libraries in XFree86 4.0.2 X-Mailer: WorldClient Standard 3.1.2 X-MDRcpt-To: freebsd-hackers@freebsd.org X-MDRemoteIP: 127.0.0.1 X-Return-Path: click46@webpimps.net X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-Id: <20010127205159.82D2037B6A7@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I have FreeBSD 4.1-RELEASE (soon to be -STABLE) running a binary install of XFree86 4.0.2. After installing xine from sources, I get a message saying I dont have Thread-safe X libraries and it wont run. I've scoured google and many newsgroups in search of anything on getting these "thread safe" libraries. Can anyone point me in the right direction as to how to obtain these files, and add them or make sure they are added, for XFree86 4.0.2 binary. I'm not too keen on compiling the whole thing... As always, I tried to do my research before submitting to the list...last ditch effort here. I even tried XFree86's list to no avail. Any help is greatly appriciated. peace - click46 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 18: 9:53 2001 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 D65AA37B400 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 18:09:36 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0S29ZW22978; Sat, 27 Jan 2001 18:09:35 -0800 (PST) Date: Sat, 27 Jan 2001 18:09:35 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Ronald G Minnich <rminnich@lanl.gov> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Hacking (i tried not to make it lame) Message-ID: <20010127180935.O26076@fw.wintelcom.net> References: <xzpg0i5gfi7.fsf@flood.ping.uio.no> <Pine.LNX.4.30.0101271050440.4161-100000@mini.acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <Pine.LNX.4.30.0101271050440.4161-100000@mini.acl.lanl.gov>; from rminnich@lanl.gov on Sat, Jan 27, 2001 at 10:51:33AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Ronald G Minnich <rminnich@lanl.gov> [010127 09:52] wrote: > > I still think a really neat source for kernel hacking is Chuck Cranor's > PhD thesis. He describes the kernel equivalent of open-heart surgery: > replacing the old VM with a new one, while keep the kernel alive. Neat > stuff. Interesting, for us too lazy to search, do you have a url handy? or a place where copies can be purchased? -- -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 Sat Jan 27 18:17:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id E7D9237B400 for <freebsd-hackers@FreeBSD.ORG>; Sat, 27 Jan 2001 18:17:41 -0800 (PST) Received: (qmail 39304 invoked by uid 3130); 28 Jan 2001 02:17:40 -0000 Date: Sat, 27 Jan 2001 21:17:40 -0500 From: Garrett Rooney <rooneg@electricjellyfish.net> To: Alfred Perlstein <bright@wintelcom.net> Cc: Ronald G Minnich <rminnich@lanl.gov>, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Hacking (i tried not to make it lame) Message-ID: <20010127211740.C33416@electricjellyfish.net> References: <xzpg0i5gfi7.fsf@flood.ping.uio.no> <Pine.LNX.4.30.0101271050440.4161-100000@mini.acl.lanl.gov> <20010127180935.O26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010127180935.O26076@fw.wintelcom.net>; from bright@wintelcom.net on Sat, Jan 27, 2001 at 06:09:35PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 06:09:35PM -0800, Alfred Perlstein wrote: > * Ronald G Minnich <rminnich@lanl.gov> [010127 09:52] wrote: > > > > I still think a really neat source for kernel hacking is Chuck Cranor's > > PhD thesis. He describes the kernel equivalent of open-heart surgery: > > replacing the old VM with a new one, while keep the kernel alive. Neat > > stuff. > > Interesting, for us too lazy to search, do you have a url handy? > or a place where copies can be purchased? http://www.ccrc.wustl.edu/pub/chuck I believe the paper he's talking about is "The Design and Implementation of the UVM Virtual Memory System", but I haven't had a chance to look at it yet (only had time to do a google search and bookmark it for future reference ;-) -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 18:34:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta05.mail.mel.aone.net.au (mta05.mail.au.uu.net [203.2.192.85]) by hub.freebsd.org (Postfix) with ESMTP id 175DF37B400 for <hackers@freebsd.org>; Sat, 27 Jan 2001 18:34:37 -0800 (PST) Received: from pc99101401 ([63.34.214.152]) by mta05.mail.mel.aone.net.au with SMTP id <20010128023434.XWMT6342.mta05.mail.mel.aone.net.au@pc99101401> for <hackers@freebsd.org>; Sun, 28 Jan 2001 13:34:34 +1100 Message-ID: <003301c088d3$0db33820$022aa8c0@pc99101401> From: "Murray Taylor" <mjtlx@ozemail.com.au> To: <hackers@freebsd.org> Subject: Problems with install Date: Sun, 28 Jan 2001 13:36:00 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Karen's system A friend is attempting a new installation from my 3.4 CDROM set (still waiting for my new 4.2 set to arrive!) on her Gateway machine with the following hardware mitsumi CDROM FX4010M!B FW AM2A Generic IDE disk type 01 Generic NEC fdd Iomega ZIP 100 Display Adapter NVIDIA RIVA TNT Hard disk controller Intel 8371 AB/EB PCI bus Master IDE controller Network 3COM Etherlink XL 10/100 PCI TX NIC (3C905B-TX) SCSI Adaptec AVA-1502 SCSI host adapter Shuttle EPAT external atapi adapter Sound Creative Audio PCI (ES 1371, ES 1373) (WDM) Errors ====== After setting up the partitions (several times as she had a few arguments with Windoze needing to be where it wanted to be rather than where she wanted to stick it!), she commenced the install by booting the CDROM, which trogged on fine for a while then produced the following error messages when it needed to mount (remount?) itself to install the binaries distribution. error mounting device /dev/acd0c on /dist: no such file or directory (2) warning: using existing root partition. It will be assumed that you have the appropriate device entries in /dev At this point she cancelled the install and finished up with the Ctrl-Alt-Del three finger salute... My Guesses ========= Based on my "wider" experience of FreeBSD (;-P tongue firmly in cheek) and reading both the GENERIC config on my machine and Gregs book, I believe that the first error is due to the fact that GENERIC doesnt have the mcd driver installed. The second error has me tossed though....?? Questions ========= Could I make a GENERIC with the mcd driver and somehow replace the GENERIC she is using? If so, do I need to build a complete new install set (unknown ground, I've never been near the releases stuff as my poor little 486 DX4-100 melts during buildworld with either a reboot or memory seg faults)? OR Should one of us somehow uproot all our hardware and transport it 25 kilometres so that she can do a network install via a x-over cable? What does the second message mean? TIA mjtlx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 19:45:45 2001 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 14BE837B400 for <hackers@FreeBSD.org>; Sat, 27 Jan 2001 19:45:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gradient.cis.upenn.edu (8.10.1/8.10.1) with ESMTP id f0S3jQF10347 for <hackers@FreeBSD.org>; Sat, 27 Jan 2001 22:45:26 -0500 (EST) Date: Sat, 27 Jan 2001 22:45:26 -0500 (EST) From: Alwyn Goodloe <agoodloe@gradient.cis.upenn.edu> To: hackers@FreeBSD.org Subject: ipfw message Message-ID: <Pine.SOL.4.21.0101272243450.10235-100000@gradient.cis.upenn.edu> 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 my last fragmentation question I swear :-) When diverting udp packets which are larger than MTU(1500) ipfw seems to divert the first and reject the second. Here is tcpdump of the packets: 23:41:05.670408 192.168.1.3.1128 > 192.168.5.12.3322: udp 1474 (frag 4127:1480@ 0+) 23:41:05.670420 192.168.1.3 > 192.168.5.12: (frag 4127:2@1480) Below is the log from ipfw. Jan 26 23:40:56 richmond /kernel: ipfw: 60000 Divert 4422 UDP 192.168.1.3:1128 192.168.5.12:3322 in via xl0 Jan 26 23:40:56 richmond /kernel: ipfw: -1 Refuse UDP 192.168.1.3 192.168.5.12 in via xl0 Fragment = 185 Now i know that ipfw will drop tcp packets of length 1 is something like that what's going on here? Well if anyone can let me in on the meaning of the rejection message it would be helpful. Alwyn 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 Sat Jan 27 19:46: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 2920B37B404; Sat, 27 Jan 2001 19:45:39 -0800 (PST) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.1/8.11.1) with SMTP id f0S3jcf84787; Sat, 27 Jan 2001 22:45:38 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa <mike@sentex.net> To: msmith@FreeBSD.ORG (Mike Smith) Cc: hackers@FreeBSD.ORG Subject: Re: 3ware ATA RAID 3DM management utility available Date: Sat, 27 Jan 2001 22:45:37 -0500 Message-ID: <1h477t4q1rlj5doh32la6n2lltp676egk8@4ax.com> References: <SEN.980475030.692982711@news.sentex.net> In-Reply-To: <SEN.980475030.692982711@news.sentex.net> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25 Jan 2001 21:10:31 -0500, in sentex.lists.freebsd.hackers you wrote: > >(Please trim cc's on any followups to remove -hackers, thanks.) > >I'm happy to announce a quick public BETA cycle for the 3ware 3DM=20 >management utility for their family of ATA RAID controllers and FreeBSD. Most exciting indeed! Also, in terms of stability as compared to other platforms, I have found the 3ware FreeBSD drivers as good if not better than the LINUX and Windows NT and 2000 versions. Those drivers are good, but I did run into a couple of crashes and rebuilds on Windows. But on = the more than half dozen production machines I have these cards in running =46reeBSD, they have been rock solid for us as well as blazing fast! = With the addition of the 3dm management utility it opens up a whole new cost effective class of reliable storage for FreeBSD servers. One small issue: 3ware has yet to update their web site. Also, their FAQ references=20 http://www.3ware.com/products/faq.shtml#L14 which points to old outdated info about the status of the twe driver. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 27 23:34:28 2001 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 0C81E37B402 for <freebsd-hackers@freebsd.org>; Sat, 27 Jan 2001 23:34:06 -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 14MAuo-0000EJ-00; Fri, 26 Jan 2001 08:35:54 -0700 Message-ID: <3A71995A.E39E0884@softweyr.com> Date: Fri, 26 Jan 2001 08:35:54 -0700 From: Wes Peters <wes@softweyr.com> Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: GLOBALLINK2001@aol.com Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Hacking (i tried not to make it lame) References: <8c.189517c.27a24307@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG GLOBALLINK2001@aol.com wrote: > > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Several others have made good replies to this, but here's another thought: The best way to learn something is to have a goal in mind. If you understand C pretty well, pick a PR out of the problem report database and start working on that. It will give you a starting point and a goal. -- "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 Sat Jan 27 23:34:28 2001 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 8AD4A37B400 for <freebsd-hackers@freebsd.org>; Sat, 27 Jan 2001 23:34:05 -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 14Lxqv-00008Z-00; Thu, 25 Jan 2001 18:39:01 -0700 Message-ID: <3A70D535.860C161B@softweyr.com> Date: Thu, 25 Jan 2001 18:39:01 -0700 From: Wes Peters <wes@softweyr.com> Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Felix-Antoine Paradis <reel@idemnia.ath.cx> Cc: Chris Faulhaber <jedgar@fxp.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: IDE CDRW References: <Pine.BSF.4.31.0101241741480.22607-100000@idemnia.ath.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Felix-Antoine Paradis wrote: > > On Wed, 24 Jan 2001, Chris Faulhaber wrote: > > > On Wed, Jan 24, 2001 at 05:04:23PM -0500, Felix-Antoine Paradis wrote: > > > Just a simple question, FreeBSD doesn't support/emulate any IDE CDRW? > > > > > > > Not sure if that is a question or not, but you probably want to look > > over ata(4) and burncd(8). > > I don't have theses installed here, not even in my port tree... you know > where i could get them? ata(4) is a man page for the ata driver. The burncd program is in /usr/sbin, a standard part of FreeBSD; burncd(8) is the man page for it. These questions belong on freebsd-questions, not on the hackers list. -- "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 Sat Jan 27 23:50:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from server.bitmcnit.bryansk.su (bitmcnit.bryansk.ru [195.239.213.9]) by hub.freebsd.org (Postfix) with ESMTP id B909D37B400 for <hackers@freebsd.org>; Sat, 27 Jan 2001 23:50:34 -0800 (PST) Received: (from uucp@localhost) by server.bitmcnit.bryansk.su (8.9.3/8.9.3) with UUCP id KAA18693 for hackers@freebsd.org; Sun, 28 Jan 2001 10:42:13 +0300 Received: (from alex@localhost) by kapran.bitmcnit.bryansk.su (8.11.1/8.11.1) id f0S7PjK02209 for hackers@freebsd.org; Sun, 28 Jan 2001 10:25:45 +0300 (MSK) (envelope-from alex@kapran.bitmcnit.bryansk.su) Date: Sun, 28 Jan 2001 10:25:44 +0300 From: Alex Kapranoff <alex@kapran.bitmcnit.bryansk.su> To: hackers@freebsd.org Subject: FreeBSD specific strftime(3) format specifiers Message-ID: <20010128102544.A2192@kapran.bitmcnit.bryansk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi to all. gcc supports strftime format string checking and issues a warning when it encounters some unknown format specifier. FreeBSD strftime has several additional format chars which gcc knows nothing about. This can easily be seen when compiling /usr/src/usr.sbin/pw: pw_user.c:1175: warning: unknown conversion type character `f' in format pw_user.c:1177: warning: unknown conversion type character `f' in format Are there chances that this could be fixed? I suppose, the patches should be submitted to gcc developers and the changes will get into our tree on next gcc source import? -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 3 weeks in the brand new millenium... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message