Re: RE: net.inet.tcp.always_keepalive on as default ?
: FWIW, I think only a fool would want a computer to NOT drop dead connections. : Any connection that doesn't respond after 8 $^! tries spaced FAR apart does : NOT deserve to stay. : :If they are spaced too far apart, it is possible for perfectly :legitimate connections to get shot down as a result of external :periodicities. (Does somebody's router reset every day at 2:45? If :so, better hope no keepalives are scheduled for then!) : :-GAWollman : :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same Irrelevant. If data is transmitted from either side at 'just the wrong time', you have the same problem. Keepalives do not make it worse. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
: : If they are spaced too far apart, it is possible for perfectly : legitimate connections to get shot down as a result of external : periodicities. (Does somebody's router reset every day at 2:45? If : so, better hope no keepalives are scheduled for then!) : :But remember that the idea is the keepalive would keep trying for a certain :amount of time, and this would be finely configureable. : Brian Feldman_ __ ___ ___ ___ ___ Adjusting the keepalive's retry period after activation is also irrelevant. As they currently stand, keepalives operate in virtually the same fashion as sending a byte of data. Extending the retry period for a keepalive is no more a reliable solution then extending ( or shortening ) the initial timeout because you are only effecting one small aspect of the TCP protocol. You are not effecting timeouts associated with normal data transmitted ( from either side ) over TCP. Unless the entire purpose of the connection is to simply be connected, with no data flow ever, being able to finely tune keepalive values does not really help. The existing rough tuning is as much as anyone will ever need to mess with. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
Most KDE programs, including the configure scripts, look for the KDEDIR environment variable. I believe that the correct thing to do with FreeBSD's KDE install is to set KDEDIR to /usr/local. I do this in /etc/profile and /etc/csh.cshrc here. (I have KDE in /usr/local/kde here, too, so I haven't tested it as /usr/local.) KDEDIR is depreciated. How do you mean depreciated? Should users not set it, or applications not check for it, or what? The 2.0 kdelibs/README states: IMPORTANT: most applications need KDEDIR as the directory where KDE is installed. Please set this in your login file. Of course, this could be out-of-date. I do not know of an alternate mechanism. A brief examination of the 2.0 kdebase and koffice configure.in's do not immediately reveal one either, other than --prefix. Is this the accepted method, then? What if a user wants to install something in a different place than the rest of KDE? --prefix specifies where it should install to. However, this app needs to find some 3rd-party include files, so --prefix is not appropriate. Uh no. The prefix is also used by the configuration script to figure out where the kdelibs were installed to. From configure: I apologize, I did not examine the source before I spoke. I will maintain that --prefix is, in general, a target specifier rather than a source specifier. In the case of the configure script you quoted (and probably all KDE configure scripts), and if they coincide (as they usually will), then --prefix will DTRT. Which configure script did you take this from? I see the same code in many bits of KDE itself. Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
: wouldn't notice... nobody would notice. : :I would. I have several long-lived connections, with a few of them :are sometimes unreachable for quote some time. I like that they survive, :and would hate it, if some brain-dead default would ruin my perfectly :set up connections. : :Even more, it would ruin dial-on-demand for a lot of people, i think. : :CU, :Sec Turn on keepalives and see if you actually notice. I can virtually guarentee that you will not notice. As far as dial-on-demand goes, that also makes no real difference. There are very few two-way dial-on-demand systems. Usually dial-on-demand is outgoing only. Incoming packets cannot activate them. There are a few ISDN-based links and ISPs that implement it in both directions both those are rapidly dying away. This means that incoming data on the undialed link will cause a disconnect, making holding such connections over an undialed link so unreliable that depending on the effect is stupid. If you have an active connection to somewhere, the link needs to be up for that connection to remain reliable whether keepalives are turned on or not. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
:On Sat, 5 Jun 1999 20:13:56 -0400 (EDT), Brian Feldman gr...@unixhelp.org said: : : If they are spaced too far apart, it is possible for perfectly : legitimate connections to get shot down as a result of external : periodicities. (Does somebody's router reset every day at 2:45? If : so, better hope no keepalives are scheduled for then!) : : But remember that the idea is the keepalive would keep trying for a certain : amount of time, and this would be finely configureable. : :This wouldn't help the poor sod whose connection gets shot down every :eight days while he's not there and doesn't know what hit him. If the poor sod hasn't touched his xterm for 8 days, he's either dead or he doesn't care if it goes away. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
: : 4. It would be desirable to have per socket timeouts, but would : require application changes which are unlikely to happen. : :Huh? I was just considering writing the patch for this. What :application problems would this create? : :The worst thing I can see is that it would mean that changing the :timeout value on a running system wouldn't affect already opened :sockets. Even that may be changable by an external utility if I can :think of a way to handle the locking in userland. : :Cheers, :joelh I see no use whatsoever for being able to specify per-socket keepalive timeouts. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
:On Sat, Jun 05, 1999 at 07:37:57AM +0200, Poul-Henning Kamp wrote: : QED: The following patch. :[...] : +tcp_keepalive=YES # Kill dead TCP connections (or NO). : :I still don't understand why you insist on making it YES by default. It :works fine like it is for most of the people right now. :So why shouldn't the few servers which have problems without it, enable :it? Make it a knob in rc.conf but off by default. :As I understand it, It suffices if the server requests the keepalives. :So if every FreeBSD-box has it on by default, I simply can not choose to :have no keepalifes anymore, even if I turn them off locally. So this :change is going to hurt somebody, somewhere. : :CU, :Sec The problem is that certain classes of connections or network instabilities can leave stale daemons. FreeBSD boxes operating as servers in any real capacity for certain services will want keepalives on. The system defaults should result in stability. For a significant percentage of machines, leaving keepalives off results in a slow buildup of processes sitting on dead connections. i.e. long term instability. This is especially true of machines which people log into with telnet, NNTP, and a number of other servers. When you leave a machine on 24 hours a day, these sorts of things can become important. The machine needs to be able to clean up after itself. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
From: Matthew Dillon dil...@apollo.backplane.com Subject: Re: net.inet.tcp.always_keepalive on as default ? Date: Sat, 5 Jun 1999 23:20:20 -0700 (PDT) Message-ID: 199906060620.xaa17...@apollo.backplane.com dillon As far as dial-on-demand goes, that also makes no real difference. dillon There are very few two-way dial-on-demand systems. Usually Two-way dial-on-demand systems may be few but actually exist. In that case, a keep alive packet may cause an extra charge of 10 yen (about US$0.08), which can be significant if the amount of other traffic is small. Note that I am not necessarily against keep alive, if there is a benefit over that charge. Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
:Huh? I was just considering writing the patch for this. What :application problems would this create? : :The worst thing I can see is that it would mean that changing the :timeout value on a running system wouldn't affect already opened :sockets. Even that may be changable by an external utility if I can :think of a way to handle the locking in userland. : I see no use whatsoever for being able to specify per-socket keepalive timeouts. Well, if it was implemented with the TCP_KEEPALIVE option, it would be one more part of the system that complied with the X/Open specifications. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
The poor sod in this situation deserves something untoward, IMNSHO. Protocols like ssh do send something periodically whereas telnet doesn't. Telnet is a well-known security problem. As others have pointed out, this is an endemic problem in applications generally speaking, where a long-term idle connection isn't treated as an exception or an an error. Some of us use only ssh for remote login *and* specifically turn off ssh keepalives, in order to keep login sessions up for weeks at at time. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
[no subject]
made cvsupworld last night, when i config the GENERIC kernel : options.i386: Duplicate option FDC_DEBUG. .== Tomer Weller s...@i.am well...@netvision.net.il Drugs are good, and if you do'em pepole think that you're cool, NoFX To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Mmap problem in -current?
On 6 Jun 1999, Joel Ray Holveck wrote: I just noticed (kernelworld from friday) that locate always cores dump: $ locate xxx Segmentation fault (core dumped) The problem disappears if I recompile locate without the -DMMAP option. Running on the very latest current, it does not work for me. By 'it', do you mean that locate does not work, that the failure test does not work (ie, locate is fine for you), or that the workaround does not work? Sorry for being ambiguous. By 'it' I meant the test that you showed us. I cannot reproduce it. Have you tried remaking your locate database first? Thanks, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
panic: bus_dmamem_free: Invalid map freed - with recent current
Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 FreeBSD/i386 bootstrap loader, Revision 0.7 636/65472kB (ti...@cicely5.cicely.de, Sun Jun 6 11:28:23 CEST 1999) Loading /boot/defaults/loader.conf /kernel text=0x15111d data=0x1b70c+0x240e0 syms=[0x4+0x1eec0+0x4+0x2205a] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Sun Jun 6 14:50:48 CEST 1999 r...@cicely5.cicely.de:/var/d3/src-1999-06-06/src/sys/compile/CICELY5 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 233029415 Hz CPU: AMD-K6tm w/ multimedia extensions (233.03-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x562 Stepping=2 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 134217728 (131072K bytes) sio0: system console avail memory = 126808064 (123836K bytes) Preloaded elf kernel kernel at 0xc02d4000. ccd0-3: Concatenated disk drivers npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82439HX PCI cache memory controller at device 0.0 on pci0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 chip1: Intel PIIX3 IDE controller at device 7.1 on pci0 pcib1: DEC 21050 PCI-PCI bridge at device 9.0 on pci0 pci1: PCI bus on pcib1 ahc0: Adaptec 398X SCSI RAID adapter irq 5 at device 4.0 on pci1 ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7810 RAID memory controller irq 11 at device 5.0 on pci1 RAID functionality unsupported device_probe_and_attach: ahc1 attach returned 6 ahc2: Adaptec 398X SCSI RAID adapter irq 5 at device 8.0 on pci1 ahc2: aic7870 Single Channel B, SCSI Id=7, 16/255 SCBs ahc3: Adaptec 398X SCSI RAID adapter irq 5 at device 12.0 on pci1 ahc3: aic7870 Single Channel C, SCSI Id=7, 16/255 SCBs pcib2: DEC 21050 PCI-PCI bridge at device 10.0 on pci0 pci2: PCI bus on pcib2 ahc4: Adaptec 3940 Ultra SCSI adapter irq 12 at device 4.0 on pci2 ahc4: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs ahc5: Adaptec 3940 Ultra SCSI adapter irq 5 at device 5.0 on pci2 ahc5: aic7880 Single Channel B, SCSI Id=7, 16/255 SCBs de0: Digital 21140A Fast Ethernet irq 10 at device 11.0 on pci0 de0: Cogent 21140A [10-100Mb/s] pass 2.0 de0: address 00:00:92:9b:20:e7 pcib3: DEC 21050 PCI-PCI bridge at device 12.0 on pci0 pci3: PCI bus on pcib3 ahc6: Adaptec 398X SCSI RAID adapter irq 11 at device 4.0 on pci3 ahc6: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs ahc7: Adaptec aic7810 RAID memory controller irq 10 at device 5.0 on pci3 RAID functionality unsupported device_probe_and_attach: ahc7 attach returned 6 ahc8: Adaptec 398X SCSI RAID adapter irq 11 at device 8.0 on pci3 panic: bus_dmamem_free: Invalid map freed Debugger(panic) Stopped at Debugger+0x37: movl$0,in_Debugger db trace Debugger(c02372db) at Debugger+0x37 panic(c0246f60,c02e6db0,c01380b7,0,0) at panic+0x74 bus_dmamem_free(0,0,0,c09dde00,380) at bus_dmamem_free+0x19 ahcfiniscbdata(c09dde00) at ahcfiniscbdata+0x87 ahc_free(c09dde00,9,0,c09d1600,c02e6e04) at ahc_free+0xd ahc_pci_attach(c09d1500,c09d1500,c02e6e30,c015e5ab,c09d1500) at ahc_pci_attach+0x641 DEVICE_ATTACH(c09d1500,c09d1500,0,c09c5ac0,c02e6e40) at DEVICE_ATTACH+0x33 device_probe_and_attach(c09d1500) at device_probe_and_attach+0x4b bus_generic_attach(c09d1600,c09d1600,c02e6e68,c015e5ab,c09d1600) at bus_generic_attach+0x16 DEVICE_ATTACH(c09d1600,c09d1600,c09c4904,c09c5cc0,c02e6e78) at DEVICE_ATTACH+0x33 device_probe_and_attach(c09d1600) at device_probe_and_attach+0x4b bus_generic_attach(c09c5ac0,c09c5ac0,c02419bd,3,0) at bus_generic_attach+0x16 pcib_attach(c09c5ac0,c09c5ac0,c02e6ec4,c015e5ab,c09c5ac0) at pcib_attach+0x44 DEVICE_ATTACH(c09c5ac0,c09c5ac0,0,c09c5dc0,c02e6ed4) at DEVICE_ATTACH+0x33 device_probe_and_attach(c09c5ac0) at device_probe_and_attach+0x4b bus_generic_attach(c09c5cc0,c09c5cc0,c02e6efc,c015e5ab,c09c5cc0) at bus_generic_attach+0x16 DEVICE_ATTACH(c09c5cc0,c09c5cc0,0,c09c3000,c02e6f0c) at DEVICE_ATTACH+0x33 device_probe_and_attach(c09c5cc0) at device_probe_and_attach+0x4b bus_generic_attach(c09c5dc0,c09c5dc0,c02e6f34,c015e5ab,c09c5dc0) at bus_generic_attach+0x16 DEVICE_ATTACH(c09c5dc0,c09c5dc0,0,c07331c0,c02e6f44) at DEVICE_ATTACH+0x33 device_probe_and_attach(c09c5dc0) at device_probe_and_attach+0x4b bus_generic_attach(c09c3000,c09c3000,c02e6f6c,c015e5ab,c09c3000) at bus_generic_attach+0x16 DEVICE_ATTACH(c09c3000,c09c3000,c026bc9c,2eb000,c02e6f7c) at DEVICE_ATTACH+0x33 device_probe_and_attach(c09c3000) at device_probe_and_attach+0x4b root_bus_configure(c07331c0,c0246a3f,0,0) at root_bus_configure+0x16 configure(0) at configure+0x39 mi_startup(c02e6fb4,0,2eb000,c0162435,c0403000) at mi_startup+0x92 begin() at begin+0x4b I used the following config: machine
options.i386: Duplicate option FDC_DEBUG.
New kernel won't build on current. when I do a config kernelname I get : options.i386: Duplicate option FDC_DEBUG. If i comment out the following from options.i386 everything builds. #FDC_DEBUG opt_fdc.h #FDC_YE opt_fdc.h Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How do i implement an Application firewall (like an transparent ftp-proxy) (smtp verifier etc.)
Subject says it all.. Almost.. Is it natd or is it the kernel ?? Maybe a plug-in system for natd could do it ? --- Nicolai Petri n...@swamp.dk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
weird crash
Hi, just today I got this error, never had it before in all those months I have been tracking CURRENT now. Jun 6 17:15:26 daemon /kernel: sio0: 65 more tty-level buffer overflows (total 65) Jun 6 17:15:28 daemon /kernel: sio0: 131 more tty-level buffer overflows (total 196) Jun 6 17:15:29 daemon /kernel: sio0: 38 more tty-level buffer overflows (total 234) until I interrupted it with CTRL-ALT-ESC to drop into DDB. This is some info I got from DDB: [ please bear with me if I didn't get all I need, but it's the first `crash' I intercepted and I think I got all the relevant data, comments appreciated though ] dbtrace Debugger(0c255518) at Debugger+0x37 scgetc(c0294020,2,124bca,c0294020,850ff2c) at scgetc+ox5ec sckdbevent(c0294020,0,0,124bca,850ff2c) at sckbdevent+0x1c4 atkbd_intr(c0294020,0,bfbfd4bc,c0211c92,c06773f0) at atkbd_intr+ox1f atkbd_isa_intr(c06773f0,0,2f,2f,2f) at atkbd_isa_intr+0x1b Xresume1() at Xresume+0x2b --- interrupt, eip=0x28078509, esp=0xc5b6dfe0, ebp=0xbfbfd4bc --- I also have results from show registers, print, show page if those are deemed interesting. What I was able to glance from ps what that the 0xc5b6dfe0 range lay in an xterm memory range... I am not 100% sure about this though. some relevant system information: [asmo...@daemon] (81) $ uname -a FreeBSD daemon.ninth-circle.org 4.0-CURRENT FreeBSD 4.0-CURRENT #3: Thu Jun 3 16:59:10 CEST 1999 asmo...@daemon.ninth-circle.org:/work/FreeBSD/src/sys/compile/DAEMON i386 Jun 2 10:57:38 daemon /kernel: isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 Jun 2 10:57:38 daemon /kernel: atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 Jun 2 10:57:38 daemon /kernel: atkbd0: AT Keyboard irq 1 on atkbdc0 Jun 2 10:57:38 daemon /kernel: atkbd: the current kbd controller command byte 0047 Jun 2 10:57:38 daemon /kernel: atkbd: keyboard ID 0x41ab (2) Jun 2 10:57:38 daemon /kernel: kbdc: RESET_KBD return code:00fa Jun 2 10:57:38 daemon /kernel: kbdc: RESET_KBD status:00aa Jun 2 10:57:38 daemon /kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d Jun 2 10:57:38 daemon /kernel: vga0: Generic ISA VGA on isa0 Jun 2 10:57:38 daemon /kernel: fb0: vga0, vga, type:VGA (5), flags:0x7007f Jun 2 10:57:38 daemon /kernel: fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa 0x2 Jun 2 10:57:38 daemon /kernel: fb0: init mode:24, bios mode:3, current mode:24 Jun 2 10:57:38 daemon /kernel: fb0: window:0xc00b8000 size:32k gran:32k, buf:0x0 size:0k Jun 2 10:57:38 daemon /kernel: VGA parameters upon power-up Jun 2 10:57:38 daemon /kernel: 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 Jun 2 10:57:38 daemon /kernel: bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 Jun 2 10:57:38 daemon /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Jun 2 10:57:38 daemon /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Jun 2 10:57:38 daemon /kernel: VGA parameters in BIOS for mode 24 Jun 2 10:57:38 daemon /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Jun 2 10:57:38 daemon /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Jun 2 10:57:38 daemon /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Jun 2 10:57:38 daemon /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Jun 2 10:57:38 daemon /kernel: EGA/VGA parameters to be used for mode 24 Jun 2 10:57:38 daemon /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Jun 2 10:57:38 daemon /kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Jun 2 10:57:38 daemon /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Jun 2 10:57:38 daemon /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Jun 2 10:57:38 daemon /kernel: sc0: System console on isa0 Jun 2 10:57:38 daemon /kernel: sc0: fb0 kbd0 Jun 2 10:57:38 daemon /kernel: sc0: VGA color 16 virtual consoles, flags=0x0 Jun 2 10:57:38 daemon /kernel: sio0: irq maps: 0x41 0x51 0x41 0x41 Jun 2 10:57:38 daemon /kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Jun 2 10:57:38 daemon /kernel: sio0: type 16550A Jun 2 10:57:38 daemon /kernel: sio1: irq maps: 0x41 0x49 0x41 0x41 Jun 2 10:57:38 daemon /kernel: sio1 at port 0x2f8-0x2ff irq 3 on isa0 Jun 2 10:57:38 daemon /kernel: sio1: type 16550A The system itself is a simple DFI-based motherboard with Intel Pentium 200 MMX and 96 MB RAM. The keyboard is not one of them ps/2's, but a the older type (I don't think that DIN is the correct name though). the device on sio0 is my serial MouseMan: controller isa0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device vga0at isa? port ? conflicts device sc0 at isa? If any more information is required, please tell me and I will see if I can dig it up. 'gards, -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The FreeBSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Accept no limitations... To
I claim the all-time worldstone record :-) :-)
Hi, -- elf make world started on Sun Jun 6 19:55:14 BST 1999 elf make world completed on Sun Jun 6 19:55:15 BST 1999 -- Given that this is just cosmetic sugar (and IMHO totally unnecessary), getting it right would have been nice... -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
On Sat, Jun 05, 1999 at 11:26:28PM -0700, Matthew Dillon wrote: If the poor sod hasn't touched his xterm for 8 days, he's either dead or he doesn't care if it goes away. Thanks for your concern. Matt, poor sod. -- Matthew Hunt m...@astro.caltech.edu * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: I claim the all-time worldstone record :-) :-)
I don't get you. We did get it right and it works fine. If you change your date in the middle then it can't help you, nor can it help you if the world build completely fails in the middle or something. :) - Jordan -- elf make world started on Sun Jun 6 19:55:14 BST 1999 elf make world completed on Sun Jun 6 19:55:15 BST 1999 -- Given that this is just cosmetic sugar (and IMHO totally unnecessary), getting it right would have been nice... -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
International Business Opportunities
ECOTECH TECHNOLOGIES, L.L.C. 4001 E., Broadway Road, Suite 7, Phoenix, AZ 85040, USA Tel: (602) 437 8000, Fax: (602) 437 4033 E-mail: ecotech...@yahoo.com http://www.ecotechindia.com Dear Sir, Sub: Your Partner for Development of International Business Ecotech Technologies, L.L.C., Phoenix, USA is a subsidiary of principal company Ecotech Marketing who has been established for 7 years in International Business Development and committed to promote cleaner technologies and projects. It promotes technologies, projects, products and equipments/machinery. Our business network covers India, Oman, UAE and Egypt. To promote your products we developed a team of professionals. The team is unique mix of technical and commercial personnel from various institutes and industries. Whether you are interested in licensing your technology or looking for establishing a joint venture or your own subsidiary or offering a turnkey project, we can provide you complete services from concept to implementation level. We provide services like market research and opportunity assessment study, feasibility study, project analysis, statutory services and supervision of implementation of project. We have been trying to promote more and more sustainable and eco-friendly technologies and we are committed to it. India is one of the fastest growing and largest economy, a democratic country with very optimistic program to implement sustainable manufacturing projects and one of the leading countries who has implemented largest number of projects. You have a concept, technology or product, and we have the professional experiences to take you to international. Sincerely Bimal Das To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: I claim the all-time worldstone record :-) :-)
fixed.. I originally used STARTTIME!=date and someone confused me into using STARTTIME?=`date` but I forgot that they get evaluated at different times. On Sun, 6 Jun 1999, Jordan K. Hubbard wrote: I don't get you. We did get it right and it works fine. If you change your date in the middle then it can't help you, nor can it help you if the world build completely fails in the middle or something. :) - Jordan -- elf make world started on Sun Jun 6 19:55:14 BST 1999 elf make world completed on Sun Jun 6 19:55:15 BST 1999 -- Given that this is just cosmetic sugar (and IMHO totally unnecessary), getting it right would have been nice... -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: I claim the all-time worldstone record :-) :-)
fixeed (My braino) On Sun, 6 Jun 1999, Bob Bishop wrote: Hi, -- elf make world started on Sun Jun 6 19:55:14 BST 1999 elf make world completed on Sun Jun 6 19:55:15 BST 1999 -- Given that this is just cosmetic sugar (and IMHO totally unnecessary), getting it right would have been nice... it's there because it removes a whole step in finding out how long the compile took. (for example if you forget to redirect your output to a log file (like I did yesterday :-)) -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How do i implement an Application firewall (like an transparent ftp-proxy) (smtp verifier etc.)
Lookup natd on the freebsd page. On Sun, 6 Jun 1999, Nicolai Petri wrote: Subject says it all.. Almost.. Is it natd or is it the kernel ?? Maybe a plug-in system for natd could do it ? --- Nicolai Petri n...@swamp.dk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: I claim the all-time worldstone record :-) :-)
At 12:49 pm -0700 6/6/99, Jordan K. Hubbard wrote:
I don't get you. We did get it right and it works fine. If you
change your date in the middle then it can't help you, nor can it
help you if the world build completely fails in the middle or
something. :)
No, really, only the subject line is in jest:
bludnok# grep 'elf make world' ,makelog
elf make world started on Sun Jun 6 16:26:52 BST 1999
elf make world started on Sun Jun 6 19:55:14 BST 1999
elf make world completed on Sun Jun 6 19:55:15 BST 1999
bludnok#
Or alternatively, the makefile:
STARTTIME?= `LC_TIME=C date`
thing:
@echo started on ${STARTTIME}
sleep 10
@echo started on ${STARTTIME}
@echo completed on `LC_TIME=C date`
produces the following:
started on Sun Jun 6 21:30:54 BST 1999
sleep 10
started on Sun Jun 6 21:31:04 BST 1999
completed on Sun Jun 6 21:31:04 BST 1999
Make isn't doing what you expected (here at least).
Last cvsupd at Sun Jun 6 04:02:36 BST 1999.
--
Bob Bishop (0118) 977 4017 international code +44 118
r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: I claim the all-time worldstone record :-) :-)
Sorry, I wasn't aware of the fact that Julian had broken this since
my last make world. :)
- Jordan
At 12:49 pm -0700 6/6/99, Jordan K. Hubbard wrote:
I don't get you. We did get it right and it works fine. If you
change your date in the middle then it can't help you, nor can it
help you if the world build completely fails in the middle or
something. :)
No, really, only the subject line is in jest:
bludnok# grep 'elf make world' ,makelog
elf make world started on Sun Jun 6 16:26:52 BST 1999
elf make world started on Sun Jun 6 19:55:14 BST 1999
elf make world completed on Sun Jun 6 19:55:15 BST 1999
bludnok#
Or alternatively, the makefile:
STARTTIME?= `LC_TIME=C date`
thing:
@echo started on ${STARTTIME}
sleep 10
@echo started on ${STARTTIME}
@echo completed on `LC_TIME=C date`
produces the following:
started on Sun Jun 6 21:30:54 BST 1999
sleep 10
started on Sun Jun 6 21:31:04 BST 1999
completed on Sun Jun 6 21:31:04 BST 1999
Make isn't doing what you expected (here at least).
Last cvsupd at Sun Jun 6 04:02:36 BST 1999.
--
Bob Bishop (0118) 977 4017 international code +44 118
r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
config is broken?
redwood201:/usr/src/sys/i386/conf#config -g DUSTER options.i386: Duplicate option FDC_DEBUG. redwood201:/usr/src/sys/i386/conf#grep FDC_DEBUG * LINT:# FDC_DEBUG enables floppy debugging. Since the debug output is huge, you LINT:optionsFDC_DEBUG options.i386:FDC_DEBUG opt_fdc.h redwood201:/usr/src/sys/i386/conf# Hmm. It's been this way for a while, and I can't see anything obvious that would cause this (and yes, I rebuilt config). - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: config is broken?
This option is in /sys/conf/options and /sys/i386/conf/options.i386 According to the cvs log, the floppy driver has moved out of the i386 architecture directory. It seems the options.i386 has been forgotten (options.pc98 has been corrected). Daniel Alex Zepeda schrieb: redwood201:/usr/src/sys/i386/conf#config -g DUSTER options.i386: Duplicate option FDC_DEBUG. redwood201:/usr/src/sys/i386/conf#grep FDC_DEBUG * LINT:# FDC_DEBUG enables floppy debugging. Since the debug output is huge, you LINT:optionsFDC_DEBUG options.i386:FDC_DEBUG opt_fdc.h redwood201:/usr/src/sys/i386/conf# To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: I claim the all-time worldstone record :-) :-)
At 1:28 pm -0700 6/6/99, Julian Elischer wrote: it's there because it removes a whole step in finding out how long the compile took. (for example if you forget to redirect your output to a log file (like I did yesterday :-)) I use a wrapper script which backgrounds the build and redirects the output; records the cvsup time, when the current kernel was built and some other stuff; and greps the start and end times out of the make log. The wrapper script appends all this stuff to a historical log file, kernel builds are recorded in the same file (another wrapper script). -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
wide char support
Is there anything in current that provides wide character support? I'm messing around with document formatting, and I have to be involved with wide character things. One example: wcscat(). It's not the only one, I just need to know if it's in *any* library, and declared in any include file. Don't give me an answer that deals with wcscat() only, that's just one example, and I'll just be back like a bad penny. If it's not a current subject (but it's there) then reply privately, I don't want to pollute the list. What I'm doing is destined for current, so I don't care if it's not in stable or some older release. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: wide char support
Is there anything in current that provides wide character support? I'm messing around with document formatting, and I have to be involved with wide character things. One example: wcscat(). It's not the only one, I just need to know if it's in *any* library, and declared in any include file. Don't give me an answer that deals with wcscat() only, that's just one example, and I'll just be back like a bad penny. If it's not a current subject (but it's there) then reply privately, I don't want to pollute the list. What I'm doing is destined for current, so I don't care if it's not in stable or some older release. As one of the people currently working on wchar support for FreeBSD, I can safely say that it is not in current. I do have 'libwcs' available that includes all functions that I am aware of that start with wcs*(). Also included are man pages and a testsuite for all but 4 of the functions. I can send this to you if desired. This also provides a kick in my pants to finish it up and submit it for review. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
On Sat, Jun 05, 1999 at 09:08:54PM +0300, Tomer Weller wrote: every small kde program i try to install (right now i tried Knewmail and Kover) i get : checking for kde headers installed... configure: error: your system is not able to compile a small KDE application! Check, if you installed the KDE header files correctly. i'm using a current machine as if last night, installed kde from ports (yes, kde-libs was compiled with -CURRENT and EGCS) any idea what's the problem ? $./configure --prefix=/usr/local that should solve it. regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: wide char support
Is there anything in current that provides wide character support? I'm messing around with document formatting, and I have to be involved with wide character things. One example: wcscat(). It's not the only one, I just need to know if it's in *any* library, and declared in any include file. There are several Japanese people working on stateful multibyte char support. Existing codebase like glibc only supports stateless multibyte char. People using iso-2022 variants (Japan, Korea, China, you name it) need stateful multibyte char support. We have some code fragment used in various software packages like multilingual vi or multilingual schedule management tool, and we would like to clean up those to fit into src/lib/whatever. I'll be talking about this issue a bit in my presentation at Usenix/ Freenix99 (titled multilingual vi) so come to presentation room or catch me somewhere in the conference site. (again, there's language barrier problem... I think we should sort it out. I believe the best way is to ban Japanese-language mailing list for the project, but other volunteers may have some trouble) ito...@involved into too many projects To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: wide char support
There are several Japanese people working on stateful multibyte char support. Existing codebase like glibc only supports stateless multibyte char. People using iso-2022 variants (Japan, Korea, China, you name it) need stateful multibyte char support. We have some code fragment used in various software packages like multilingual vi or multilingual schedule management tool, and we would like to clean up those to fit into src/lib/whatever. I'll be talking about this issue a bit in my presentation at Usenix/ Freenix99 (titled multilingual vi) so come to presentation room or catch me somewhere in the conference site. (again, there's language barrier problem... I think we should sort it out. I believe the best way is to ban Japanese-language mailing list for the project, but other volunteers may have some trouble) Alas I will not be at Usenix. I do hope to be able to attend FreeBSDcon'99. I think both of our work is valuable. We need both statefull and stateless I18N support; because there is source that uses both. Language has been a problem, but it is good to see we have some liasons bridging that gap to keep us from replicating efforts and stepping on toes and emotions. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Panic on boot
I was wondering, I've been spending all my time recently on a research task, and I might have missed this: I just rebuilt world, then reinstalled a new kernel, and it won't mount root. Luckily, my old kernel is just fine, and uses my new modules fine, but it won't mount root. I noticed in the kernel config file that I had the old formulation for mount root on so I changed it to the new one, rebooted, nothing changed at all. I have an Intel DK440LX with a AIC7895 dual Adaptec controller, with 2 4G drives on one controller, one 4G drive and one cdrom on the other. I've checked with the old kernel, comparing everything, it all looks fine, and the new kernel won't even boot single user, so I can't tell if it's suddenly decided to juggle my drives or not. anyone know if anything has changed? +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
But remember that the idea is the keepalive would keep trying for a certain amount of time, and this would be finely configureable. Adjusting the keepalive's retry period after activation is also irrelevant. As they currently stand, keepalives operate in virtually [snip] I don't see why this is a point of discussion. The keepalive timers are all configurable via sysctl. Is this mechanism being considered as insufficient? Unless the entire purpose of the connection is to simply be connected, with no data flow ever, being able to finely tune keepalive values does not really help. The existing rough tuning is as much as anyone will ever need to mess with. With all due respect, Matt, the second biggest lesson my time with computers has taught me is to never think that X will be enough for all needs. 640k, 32 bit IP addresses, two-digit years, Ada, non 8-bit-clean text utilities, one-second granularity in the filesystem timestamps, yada yada. (Note that I have no objection to saying that we don't see a need to implement it at present. In this case, I sure don't see such a need, but I'm willing to be given a counterexample. We're not looking at making it impossible-- or even difficult-- to implement other keepalive timing strategies in the future, if the need arises, so I would suggest that we not concern ourselves with this discussion until the need arises.) Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
Joel Ray Holveck jo...@gnu.org wrote: I don't see why this is a point of discussion. The keepalive timers are all configurable via sysctl. Not quite all. The variables tcp_keepcnt and tcp_maxpersistidle are not accessible via sysctl (the latter is not directly related to the current keepalives issue, but it shares the same default value - TCPTV_KEEP_IDLE - as tcp_keepidle). There's also the the minor nit that there's no documentation. RTSL may be OK for developers, but it's not really appropriate for end users. This is aggravated by the timers being in 500ms units - phk tripped over this recently. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: wide char support
On Mon, 7 Jun 1999, Jun-ichiro itojun Hagino wrote: Is there anything in current that provides wide character support? I'm messing around with document formatting, and I have to be involved with wide character things. One example: wcscat(). It's not the only one, I just need to know if it's in *any* library, and declared in any include file. There are several Japanese people working on stateful multibyte char support. Existing codebase like glibc only supports stateless multibyte char. People using iso-2022 variants (Japan, Korea, China, you name it) need stateful multibyte char support. We have some code fragment used in various software packages like multilingual vi or multilingual schedule management tool, and we would like to clean up those to fit into src/lib/whatever. I'll be talking about this issue a bit in my presentation at Usenix/ Freenix99 (titled multilingual vi) so come to presentation room or catch me somewhere in the conference site. (again, there's language barrier problem... I think we should sort it out. I believe the best way is to ban Japanese-language mailing list for the project, but other volunteers may have some trouble) Do you guys have any testable, even if it's not ready for prime time? I need wchar.h and the wcs* functions for a project for FreeBSD. You want me to have this, I think. David said he had something ready to play with (I think) but I haven't heard from him yet. As far as the list ... Urrr, I don't speak Japanese. I'm willing if someone would do the interpreting, but I better make it clear that my own interest is in document formatting, not on the Unicode support in and of itself, you understand? I want you guys to be able to use my stuff, but since I can't read it, I'll never use 16 bit characters myself. I think. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
About the panic
Don't wory. I guess with my dual controllers, that's likely what did it. I only had ahc0, not ahc1, in my config file. For some reason, it didn't like that anymore. Anyhow, it's fixed. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How do i implement an Application firewall (like an transparentftp-proxy) (smtp verifier etc.)
k...@lyris.com wrote: Lookup natd on the freebsd page. Yes, and take a look at the ipfw 'forward' rule. It is your friend. Thomas To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: wide char support
The latest snapshot can be grabbed from: http://www.cs.rpi.edu/~crossd/FreeBSD/wcs-19990606.tar.gz New in this release... 1) Man pages (I don't think I included them prior to this) 2) Makefile that sorta works (makes a dynamic library.. I don't recommend people use the dynamic, it is convienient for me doing testing) 3) Bug fixes. 4) wcstest: my own program for testing some of the code-paths in the library routines. This was just created from my work space... I don't know if it compiles. I think it does, and you have the test program to be fairly sure that what does compile is at least paritally correct. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: wide char support
Do you guys have any testable, even if it's not ready for prime time? I need wchar.h and the wcs* functions for a project for FreeBSD. You want me to have this, I think. David said he had something ready to play with (I think) but I haven't heard from him yet. We have some code fragment, with small wchar-compliant application to play with. This is not integrated into src/lib/whatever yet. I'll be supplying URL for those who would like test this (sorry not on the mailing list...), so contact me if interested. itojun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
