From owner-freebsd-hackers Sun Nov 10 00:03:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA22448 for hackers-outgoing; Sun, 10 Nov 1996 00:03:14 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA22443; Sun, 10 Nov 1996 00:03:11 -0800 (PST) Message-Id: <199611100803.AAA22443@freefall.freebsd.org> To: Jaye Mathisen cc: hackers@freebsd.org, scsi@freebsd.org Subject: Re: Anybody compiling -current with AHC_DEBUG? In-reply-to: Your message of "Sat, 09 Nov 1996 23:46:27 PST." Date: Sun, 10 Nov 1996 00:03:11 -0800 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nope, but its easy enough to fix. Change DEBUGTARGET to DEBUGTARG, and use this for your ahc_print_scb function: static void ahc_print_scb(scb) struct scb *scb; { struct hardware_scb *hscb = scb->hscb; printf("scb:%p control:0x%x tcl:0x%x cmdlen:%d cmdpointer:0x%lx\n", scb, hscb->control, hscb->tcl, hscb->cmdlen, hscb->cmdpointer ); printf(" datlen:%d data:0x%lx segs:0x%x segp:0x%lx\n", hscb->datalen, hscb->data, hscb->SG_segment_count, hscb->SG_list_pointer); printf(" sg_addr:%lx sg_len:%ld\n", hscb->ahc_dma[0].addr, hscb->ahc_dma[0].len); } >From this mail, this must mean that you continue to have problems with your RAID box and the FreeBSD driver. I have a hunch that this may be related to a problem with how the driver is setting up the termination settings. How is your bus setup??? -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sun Nov 10 02:20:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA28288 for hackers-outgoing; Sun, 10 Nov 1996 02:20:03 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA28259 for ; Sun, 10 Nov 1996 02:19:54 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id LAA14308; Sun, 10 Nov 1996 11:00:37 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.2/8.8.2) with SMTP id KAA01114; Sun, 10 Nov 1996 10:56:48 +0100 (MET) Date: Sun, 10 Nov 1996 10:56:48 +0100 (MET) From: Andreas Klemm To: "Justin T. Gibbs" cc: "Alexsandro D. F. Correia" , hackers@FreeBSD.ORG Subject: Re: Problems restoring Backups !!! In-Reply-To: <199611091736.JAA10651@freefall.freebsd.org> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 9 Nov 1996, Justin T. Gibbs wrote: > >One problem in -current still remains. If I enable Tagged command > >queueing and try to do a backup. the machine hangs. > >P100, ASUS P55tp4xe, 256k burst, 2940, TDC 4222. I noticed that > >also using a Sun DAT. > > I need a boot -v. I'm also assuming that you have all of my changes up > to and including those made on the 7th? Hi Justin, thanks that you take the time on that. BTW, I just wrote a problem report. I'm not sure if I had a kernel with your changes from Nov. 7th. But I'm just cvsupping and will repeat that with a new kernel. S delay: 2 clocks chip1 rev 2 on pci0:7:0 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: IRQ11, B: disabled, C: IRQ12, D: disabled MB0: disabled, MB1: disabled chip2 rev 2 on pci0:7:1 mapreg[20] type=1 addr=0000e800 size=0010. Primary IDE: disabled Secondary IDE: disabled vga0 rev 0 int a irq 12 on pci0:10 mapreg[10] type=0 addr=f8000000 size=2000000. ahc0 rev 3 int a irq 11 on pci0:12 mapreg[10] type=1 addr=0000e400 size=0100. mapreg[14] type=0 addr=f7800000 size=1000. reg16: ioaddr=0xe400 size=0x100 reg20: virtual=0xf5fbf000 physical=0xf7800000 size=0x1000 ahc0: Reading SEEPROM...done. ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A Choosing drivers for scbus configured at 0 ahc0 waiting for scsi devices to settle ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "IBM DORS-32160 WA0A" type 0 fixed SCSI 2 sd is configured at 0 sd0(ahc0:0:0): Direct-Access 2063MB (4226725 512 byte sectors) sd0(ahc0:0:0): with 6703 cyls, 5 heads, and an average 126 sectors/track ahc0: target 1 synchronous at 10.0MHz, offset = 0xf ahc0: target 1 Tagged Queuing Device (ahc0:1:0): "IBM DORS-32160 WA0A" type 0 fixed SCSI 2 sd is configured at 1 sd1(ahc0:1:0): Direct-Access 2063MB (4226725 512 byte sectors) sd1(ahc0:1:0): with 6703 cyls, 5 heads, and an average 126 sectors/track ahc0: target 4 synchronous at 4.4MHz, offset = 0x8 (ahc0:4:0): "TANDBERG TDC 4222 =07:" type 1 removable SCSI 2 st is configured at 0 st0(ahc0:4:0): Sequential-Access density code 0x0, 512-byte blocks, write-enabled ahc0: target 6 synchronous at 4.0MHz, offset = 0xf (ahc0:6:0): "TOSHIBA CD-ROM XM-3601TA 0725" type 5 removable SCSI 2 cd is configured at 0 cd0(ahc0:6:0): CD-ROM cd present [253041 x 2048 byte records] pci0: uses 33558528 bytes of memory from f7800000 upto f9ffffff. pci0: uses 272 bytes of I/O space from e400 upto e80f. Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <4 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 maddr 0xcc000 msize 16384 on isa ed0: address 00:00:c0:25:fd:2d, type WD8013EPC (16 bit) bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in tel0 at 0xd80 irq 9 on isa bpf: ipi0 attached bpf: ipi1 attached bpf: ipi2 attached bpf: ipi3 attached tel0: card type Teles S0/16.3 npx0 on motherboard npx0: INT 16 interface joy0 at 0x201 on isa joy0: joystick sb0 at 0x220 irq 5 drq 1 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvo0: sbmidi0 at 0x330 on isa opl0 at 0x388 on isa opl0: imasks: bio c0000840, tty c003009a, net c0020600 Device configuration finished. Considering FFS root f/s. configure() finished. bpf: tun0 attached bpf: lo0 attached IP packet filtering initialized, divert disabled, unlimited logging sd0s1: type 0x6, start 63, end = 1028159, size 1028097 : OK sd0s2: type 0x5, start 1028160, end = 2056319, size 1028160 : OK sd0s3: type 0xa5, start 2056320, end = 4225094, size 2168775 : OK sd0s5: type 0x6, start 1028223, end = 2056319, size 1028097 : OK sd1s1: type 0xa5, start 63, end = 4225094, size 4225032 : OK Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Queue Full Assigned: TEI = 0xa1 = 80 -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Sun Nov 10 04:57:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA06731 for hackers-outgoing; Sun, 10 Nov 1996 04:57:50 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA06723 for ; Sun, 10 Nov 1996 04:57:46 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id EAA27377; Sun, 10 Nov 1996 04:57:31 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id XAA28475; Sun, 10 Nov 1996 23:57:04 +1100 From: Julian Assange Message-Id: <199611101257.XAA28475@suburbia.net> Subject: Re: gdb anomalies To: bde@zeta.org.au (Bruce Evans) Date: Sun, 10 Nov 1996 23:57:03 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611101014.VAA03875@godzilla.zeta.org.au> from "Bruce Evans" at Nov 10, 96 09:14:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > gdb sometimes tells me that the executable file has changed, although > it shouldn't have. It seems to be correct though - executing the > file apparently clobbers at least its ctime and mtime: I suspect this has something to do with mmaping. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Sun Nov 10 10:04:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA21997 for hackers-outgoing; Sun, 10 Nov 1996 10:04:13 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA21991; Sun, 10 Nov 1996 10:04:10 -0800 (PST) Message-Id: <199611101804.KAA21991@freefall.freebsd.org> To: Andreas Klemm cc: "Alexsandro D. F. Correia" , hackers@FreeBSD.ORG Subject: Re: Problems restoring Backups !!! In-reply-to: Your message of "Sun, 10 Nov 1996 10:56:48 +0100." Date: Sun, 10 Nov 1996 10:04:09 -0800 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On Sat, 9 Nov 1996, Justin T. Gibbs wrote: >Hi Justin, thanks that you take the time on that. BTW, I just wrote >a problem report. I'm not sure if I had a kernel with your changes from >Nov. 7th. But I'm just cvsupping and will repeat that with a new kernel. Your problem report had the information I needed to understand and fix your problem. I changed the QUEUE FULL condition code to not do an unconditional retry a little while ago, and you must be running out of retries. You should be able to get this kind of thing to happen in other scenarios besides dumping. I'll fix this today. >-- >andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik Gmb >H > Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.d >e >pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by << >< >ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD << >< > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sun Nov 10 10:41:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA23879 for hackers-outgoing; Sun, 10 Nov 1996 10:41:11 -0800 (PST) Received: from ami.tom.computerworks.net (root@AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA23873 for ; Sun, 10 Nov 1996 10:41:09 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #3) id m0vMenf-0021WYC; Sun, 10 Nov 96 13:40 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id MAA22803; Sun, 10 Nov 1996 12:41:53 -0600 Date: Sun, 10 Nov 1996 12:41:53 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199611101841.MAA22803@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: Linux compat issue(s) Newsgroups: taronga.freebsd.hackers In-Reply-To: <199610151816.UAA01759@SandBox.CyberCity.dk> References: <199610151643.JAA03974@austin.polstra.com> Organization: none Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199610151816.UAA01759@SandBox.CyberCity.dk>, Soren Schmidt wrote: >to do SVR4 emulation we will NEED a way to tell them apart. So having >a nice little util that marks the ELF header in ways for us to know >is the ONLY solution to this problem, like it or not.=20 I am not familiar with ELF in particular, but other modern binary file formats (IFF, MFF, PNG, even GIF) support a mechanism for adding entries to the file without having to understand the file's content completely. What's wrong with using a NOTE field. Sure, the binary's size will change but all the offsets should automagically drop in... From owner-freebsd-hackers Sun Nov 10 11:02:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25438 for hackers-outgoing; Sun, 10 Nov 1996 11:02:34 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA25432 for ; Sun, 10 Nov 1996 11:02:32 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id TAA04482; Sun, 10 Nov 1996 19:45:46 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.2/8.8.2) with SMTP id TAA18646; Sun, 10 Nov 1996 19:40:33 +0100 (MET) Date: Sun, 10 Nov 1996 19:40:32 +0100 (MET) From: Andreas Klemm To: "Justin T. Gibbs" cc: "Alexsandro D. F. Correia" , hackers@FreeBSD.ORG Subject: Re: Problems restoring Backups !!! In-Reply-To: <199611101804.KAA21991@freefall.freebsd.org> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Nov 1996, Justin T. Gibbs wrote: > Your problem report had the information I needed to understand and fix your > problem. I changed the QUEUE FULL condition code to not do an > unconditional retry a little while ago, and you must be running out of > retries. You should be able to get this kind of thing to happen in other > scenarios besides dumping. I'll fix this today. That's very nice, thanks. -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Sun Nov 10 12:48:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA02105 for hackers-outgoing; Sun, 10 Nov 1996 12:48:57 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA02098 for ; Sun, 10 Nov 1996 12:48:55 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id MAA05053 for ; Sun, 10 Nov 1996 12:48:45 -0800 (PST) Message-Id: <199611102048.MAA05053@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: PPRO optimizations? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Nov 1996 12:48:45 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tnks, Amancio Subject: PPro optimiz. (multiple accumulators) Date: Sun, 10 Nov 1996 11:56:34 -0700 From: "H.W. Stockman" Organization: Southwest Cyberport Newsgroups: comp.lang.asm.x86, comp.sys.intel I heard that Intel has a document with examples of "multiple accumulator" programming for the PPro. One example is supposedly like saxpy() or daxpy(), and ostensibly the speedup for the multi-accumulator approach was something like 150 MFLOPs vs. 60 MFLOPs. Has anyone seen this example... and could you tell me where I might get the document? I've see Terje Mathisen's excellent sqrt2(1/x) example, and am looking to increase my bag of tricks... From owner-freebsd-hackers Sun Nov 10 12:58:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA02719 for hackers-outgoing; Sun, 10 Nov 1996 12:58:40 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA02699 for ; Sun, 10 Nov 1996 12:58:37 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id MAA28328 for ; Sun, 10 Nov 1996 12:58:39 -0800 (PST) To: hackers@freebsd.org Subject: freefall will be down at 14:00 hours PST today (Nov 10) for PM Date: Sun, 10 Nov 1996 12:58:38 -0800 Message-ID: <28325.847659518@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't know how long it will be down, but I hope it'll be as short a period as possible. One of its long-suffering drives is finally going down for the count and requires replacement before data is lost. This replacement will installed today and the data moved. Jordan From owner-freebsd-hackers Sun Nov 10 13:33:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA05768 for hackers-outgoing; Sun, 10 Nov 1996 13:33:17 -0800 (PST) Received: from trapdoor.dstc.edu.au (root@trapdoor.dstc.edu.au [130.102.176.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA05752 for ; Sun, 10 Nov 1996 13:33:14 -0800 (PST) Received: from azure.dstc.edu.au (azure.dstc.edu.au [130.102.176.27]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id HAA11946; Mon, 11 Nov 1996 07:33:02 +1000 Received: (from leonard@localhost) by azure.dstc.edu.au (8.6.10/8.6.12) id HAA07495; Mon, 11 Nov 1996 07:33:02 +1000 From: David Leonard Message-Id: <199611102133.HAA07495@azure.dstc.edu.au> Subject: Re: semaphores/shared memory To: hackers@freebsd.org, scrappy@ki.net Date: Mon, 11 Nov 1996 07:33:01 +1000 (EST) Reply-To: leonard@dstc.edu.au X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk scrappy@ki.net (Marc G. Fournier) writes: > I have a copy of Unix Network Programming, and am working on > designing a server-client system where there is one server and X clients > that are talking to it, using shared memory. > according to the book, I'm looking at using semaphores for the > IPC, and the general concepts of semaphores presented makes sense...but > it seems to only allow for a 1-1 relationship, vs a 1-many relationship. > can anyone suggestion a reference that goes a bit deeper into > shared memory/semaphores that might give me a better idea of a 1-many > relationship, if possible? > essentially, I want the server to write a line of data to > shared memory, then signal all the clients at once that the data is > there, so that they all pick up the data... you might want to look at multicast ports: the LBL conferencing tools use what they term a 'conferencing bus' to allow all the tools to talk to each other in a 1-many kind of way. AFAIK it is implemented as a multicast group on the loopback interface. d -- David Leonard Developer, DSTC The University of Queensland david.leonard@dstc.edu.au http://www.dstc.edu.au/~leonard/ "What is contemplation but laxative for the mind?" - T.A.Casady (?) From owner-freebsd-hackers Sun Nov 10 13:44:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA06749 for hackers-outgoing; Sun, 10 Nov 1996 13:44:18 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA06683 for ; Sun, 10 Nov 1996 13:44:01 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.7.6/8.6.9) id IAA06189; Mon, 11 Nov 1996 08:43:34 +1100 (EST) Message-ID: Date: Mon, 11 Nov 1996 08:43:34 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: freebsd-hackers@freebsd.org Subject: Fwd: Digiboard driver X-Mailer: Mutt 0.50 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=evf6ppmFHys1AiCM Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --evf6ppmFHys1AiCM [originally posted in -questions, but no response] I heard mention some time ago that the Linux Digiboard driver had been ported to FreeBSD. Who maintains this port? I cannot find it in -current sources, and I'm interested in furthering its development. Regards, David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn --evf6ppmFHys1AiCM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBMoVPZK0PLjnMZgUtAQHPOAP9HEZjheBAPX+73Qhpl64Uh2Y7uW0eLRbc 0+wnExfwuSWYzYuKNkA2XTySTSyXcdg+AH+KM8qhT6lWFPPK5LTsiYzAcBKse6Co Jjk9v9f50yh3ldZ6n0RqR57xi77fwTfKGERDaT40wUCpQSrvarMYJsKHFPZsUH0e N17Dl8Rafug= =Aj4U -----END PGP SIGNATURE----- --evf6ppmFHys1AiCM-- From owner-freebsd-hackers Sun Nov 10 13:58:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA07525 for hackers-outgoing; Sun, 10 Nov 1996 13:58:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA07520 for ; Sun, 10 Nov 1996 13:58:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA16959; Sun, 10 Nov 1996 14:48:13 -0700 From: Terry Lambert Message-Id: <199611102148.OAA16959@phaeton.artisoft.com> Subject: Re: virtual hosting with inetd To: proff@suburbia.net (Julian Assange) Date: Sun, 10 Nov 1996 14:48:13 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199611090643.RAA23191@suburbia.net> from "Julian Assange" at Nov 9, 96 05:43:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Does anyone have any other comments on the patch > I produced? Terry, did I address yours? > Is it commitable? Well, you addressed mine... I didn't necessarily agree with all your points, but the one about external daemons was a good one. The state question I think is still valid, escpecially for long conf files. I still don't see why if you are ging to implement an "#include" type syntax for files that they have to have the first line a bind line; an #include is an #include. I also find it a little strange that you just don't implement a #include keyword instead of implying it with a sh "<" construct. Other than that, xinetd is already in ports, and I thought that inetd was maintained at Cray along with telnet and the other services... Other than that, no, I have no problems. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Nov 10 13:58:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA07565 for hackers-outgoing; Sun, 10 Nov 1996 13:58:56 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA07560 for ; Sun, 10 Nov 1996 13:58:51 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id NAA25171; Sun, 10 Nov 1996 13:57:00 -0800 (PST) Message-ID: <32864F96.41C67EA6@whistle.com> Date: Sun, 10 Nov 1996 13:56:38 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Julian Assange CC: freebsd-hackers@freebsd.org Subject: Re: virtual hosting with inetd References: <199611090643.RAA23191@suburbia.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Assange wrote: > > Does anyone have any other comments on the patch > I produced? Terry, did I address yours? > Is it commitable? they are definitly useful, and we might need them in the near future.. I need to look at xinetd some time to see how much should be added to our inetd and how much should be considered "use xinetd instead". From owner-freebsd-hackers Sun Nov 10 14:03:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07806 for hackers-outgoing; Sun, 10 Nov 1996 14:03:12 -0800 (PST) Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA07799 for ; Sun, 10 Nov 1996 14:03:06 -0800 (PST) Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.7.6/8.7.3) with ESMTP id OAA26954 for ; Sun, 10 Nov 1996 14:01:30 -0800 (PST) Received: (from gena@localhost) by shellx.best.com (8.8.2/8.7.3) id OAA26135 for hackers@FreeBSD.org; Sun, 10 Nov 1996 14:01:30 -0800 (PST) From: Gennadiy Gulchin Message-Id: <199611102201.OAA26135@shellx.best.com> Subject: SYN attack To: hackers@FreeBSD.org Date: Sun, 10 Nov 1996 14:01:29 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello, does anyone have any idea how can I protect my FreeBSD-2.1.5 box forn SYN attack? -- Gena Gulchin From owner-freebsd-hackers Sun Nov 10 15:40:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA00345 for hackers-outgoing; Sun, 10 Nov 1996 15:40:35 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA00320 for ; Sun, 10 Nov 1996 15:40:31 -0800 (PST) Received: from prova.iet.unipi.it (prova1.iet.unipi.it [131.114.9.11]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id PAA27043 for ; Sun, 10 Nov 1996 15:30:41 -0800 (PST) Received: (from luigi@localhost) by prova.iet.unipi.it (8.6.12/8.6.12) id AAA02443; Mon, 11 Nov 1996 00:40:07 +0100 Date: Mon, 11 Nov 1996 00:40:07 +0100 (MET) From: Luigi Rizzo To: hackers@freebsd.org cc: luigi@iet.unipi.it Subject: mail.local behaviour Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [perhaps this is also an isp thing, but I do not like much crossposting; if someone thing it's worth it, I'll do] we are running a (mail) server with about 2500 users, and have a couple of problems with the local delivery agent, mail.local: #1 /var/mail has too many entries, this leads to some inefficiency and is also unconvenient when doing an ls in that directory. #2 mail.local does not appear to honor quotas: /var/mail/xxx grows happily beyond the user's hard limit, causing a number of problems to the victim. I have had a look at the sources of mail.local, it appears that #1 can be solved with a trivial change, e.g. by putting the mailbox in the user's home directory instead of a centralized spool (of course, mail readers should be modified accordingly, but that's not hard). For #2, maybe mail.local could call setuid() after making sure that the user really exists on the system. This change should be trivial as well. Any comment on these two changes, and, especially, are there undesired side effects that I don't see ? While #1 is probably just a local hack, I think problem #2 should really be fixed in the distribution. Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-hackers Sun Nov 10 15:44:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA00821 for hackers-outgoing; Sun, 10 Nov 1996 15:44:01 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA00797 for ; Sun, 10 Nov 1996 15:43:36 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-1.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA09422 (5.67b/IDA-1.5 for ); Mon, 11 Nov 1996 00:12:28 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id AAA00997; Mon, 11 Nov 1996 00:11:40 +0100 (MET) Message-Id: <199611102311.AAA00997@x14.mi.uni-koeln.de> Date: Mon, 11 Nov 1996 00:10:20 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: durian@plutotech.com (Mike Durian) Cc: freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-Reply-To: <199611071835.LAA25115@pluto.plutotech.com>; from Mike Durian on Nov 7, 1996 11:35:09 -0700 References: <199611071835.LAA25115@pluto.plutotech.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Durian writes: > I've discovered three bugs in the pci code (at least I believe they > are bugs). These are in the 2.1.5 release. Since we've made some > local changes to these files, I don't have proper diffs, but the > changes are very small and isolated. Thanks a lot for sending such a good problem report! Please test the patches you'll find appended to this message ... > 1) In pcireg.h, the definitions of PCI_PPB_IOBASE_EXTRACT and > PCI_PPB_IOLIMIT_EXTRACT should be: > > #define PCI_PPB_IOBASE_EXTRACT(x) (((x) << 8) & 0xF000) > #define PCI_PPB_IOLIMIT_EXTRACT(x) (((x) << 0) & 0xF000) Modified the sources in a slightly different way ... > 2) Related to #1, the mask that is OR'd with the PCI_PPB_IOLIMIT_EXTRACT > value should be 0xfff. It should not be calculated from the > amount of memory requested. I don't have a line number for this, > but it is in pci.c near the PCI_PPB_IOLIMIT_EXTRACT string, which > only occurs once. The PCI standard says, "the upper 4 bits of I/O > Limit register are writeable and correspond to address bits AD[15::12]. > For purpose of address decoding the bridge assumes that the lower 12 > address bits, AD[11::0], of the I/O limit address (not implemented > in the I/O Limit register) are FFFh." Yes. Hmmm, but the same should apply to the memory regions! Well, looking at it more closely, the whole code appears to be bogus. Please test my suggested fix (you seem to have the required hardware, or you wouldn't have noticed there was a problem, I suppose ;-) > 3) In the same pci_bus_config() function, there is a section of for > loop code that begins with the comment, "Read the current mapping, > and update the pcicb fields." In this for loop, there is a switch > statement that handles the two types of mapping: I/O and memory. > The line: > switch (data & 7) { > should read: > switch (map & 7) { > The lower three bits that determine the mapping type are found in > the address value, not the size value. Well, I can only agree to half of that sentence: The mapping type is found in the address, but also in the size. The low bits of the map registers are hardwired. For that reason, (data & 7) is guaranteed to be identical to (map & 7) ... Regards, STefan Index: pcireg.h =================================================================== RCS file: /usr/cvs/src/sys/pci/pcireg.h,v retrieving revision 1.5.4.2 diff -C2 -r1.5.4.2 pcireg.h *** pcireg.h 1996/06/26 04:36:50 1.5.4.2 --- pcireg.h 1996/11/10 22:59:21 *************** *** 174,182 **** #define PCI_SUBORDINATE_BUS_INSERT(x, y) (((x) & ~PCI_SUBORDINATE_BUS_MASK) | ((y) << 16)) ! #define PCI_PPB_IOBASE_EXTRACT(x) (((x) << 8) & 0xFF00) ! #define PCI_PPB_IOLIMIT_EXTRACT(x) (((x) << 0) & 0xFF00) ! #define PCI_PPB_MEMBASE_EXTRACT(x) (((x) << 16) & 0xFFFF0000) ! #define PCI_PPB_MEMLIMIT_EXTRACT(x) (((x) << 0) & 0xFFFF0000) /* --- 174,182 ---- #define PCI_SUBORDINATE_BUS_INSERT(x, y) (((x) & ~PCI_SUBORDINATE_BUS_MASK) | ((y) << 16)) ! #define PCI_PPB_IOBASE_EXTRACT(x) (((x) << 8) & 0xF000) ! #define PCI_PPB_IOLIMIT_EXTRACT(x) (((x) << 0) & 0xF000 | 0x0FFF) ! #define PCI_PPB_MEMBASE_EXTRACT(x) (((x) << 16) & 0xFFF00000) ! #define PCI_PPB_MEMLIMIT_EXTRACT(x) (((x) << 0) & 0xFFF00000 | 0x000FFFFF) /* Index: pci.c =================================================================== RCS file: /usr/cvs/src/sys/pci/pci.c,v retrieving revision 1.23.4.6 diff -C2 -r1.23.4.6 pci.c *** pci.c 1996/06/26 04:36:49 1.23.4.6 --- pci.c 1996/11/10 23:03:34 *************** *** 774,794 **** ** Read out the mapped io region. */ ! u_int reg, data, mask; reg = pci_conf_read (tag, PCI_PCI_BRIDGE_IO_REG); - pci_conf_write(tag, - PCI_PCI_BRIDGE_IO_REG, 0xFFFF); - data = pci_conf_read (tag, - PCI_PCI_BRIDGE_IO_REG); - pci_conf_write(tag, - PCI_PCI_BRIDGE_IO_REG, reg & 0xffff); - - mask = (0xFF00 ^ (data & 0xFF00)) | 0xFF; - this->pcicb_iobase = PCI_PPB_IOBASE_EXTRACT (reg); this->pcicb_iolimit = ! PCI_PPB_IOLIMIT_EXTRACT(reg) | mask; /* --- 774,785 ---- ** Read out the mapped io region. */ ! unsigned reg; reg = pci_conf_read (tag, PCI_PCI_BRIDGE_IO_REG); this->pcicb_iobase = PCI_PPB_IOBASE_EXTRACT (reg); this->pcicb_iolimit = ! PCI_PPB_IOLIMIT_EXTRACT(reg); /* *************** *** 805,809 **** ** Read out the mapped memory regions. */ ! u_int reg, data, mask; /* --- 796,800 ---- ** Read out the mapped memory regions. */ ! unsigned reg; /* *************** *** 812,827 **** reg = pci_conf_read (tag, PCI_PCI_BRIDGE_MEM_REG); - pci_conf_write(tag, - PCI_PCI_BRIDGE_MEM_REG, 0xFFFFFFFF); - data = pci_conf_read (tag, - PCI_PCI_BRIDGE_MEM_REG); - pci_conf_write(tag, - PCI_PCI_BRIDGE_MEM_REG, reg); - - mask = 0xFFFFFFFF ^ (data & 0xFFFF0000); this->pcicb_membase = PCI_PPB_MEMBASE_EXTRACT (reg); this->pcicb_memlimit = ! PCI_PPB_MEMLIMIT_EXTRACT(reg) | mask; /* --- 803,810 ---- reg = pci_conf_read (tag, PCI_PCI_BRIDGE_MEM_REG); this->pcicb_membase = PCI_PPB_MEMBASE_EXTRACT (reg); this->pcicb_memlimit = ! PCI_PPB_MEMLIMIT_EXTRACT(reg); /* *************** *** 837,852 **** reg = pci_conf_read (tag, PCI_PCI_BRIDGE_PMEM_REG); - pci_conf_write(tag, - PCI_PCI_BRIDGE_PMEM_REG, 0xFFFFFFFF); - data = pci_conf_read (tag, - PCI_PCI_BRIDGE_PMEM_REG); - pci_conf_write(tag, - PCI_PCI_BRIDGE_PMEM_REG, reg); - - mask = 0xFFFFFFFF ^ (data & 0xFFFF0000); this->pcicb_p_membase= PCI_PPB_MEMBASE_EXTRACT (reg); this->pcicb_p_memlimit= ! PCI_PPB_MEMLIMIT_EXTRACT(reg) | mask; /* --- 820,827 ---- reg = pci_conf_read (tag, PCI_PCI_BRIDGE_PMEM_REG); this->pcicb_p_membase= PCI_PPB_MEMBASE_EXTRACT (reg); this->pcicb_p_memlimit= ! PCI_PPB_MEMLIMIT_EXTRACT(reg); /* From owner-freebsd-hackers Sun Nov 10 18:46:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA06969 for hackers-outgoing; Sun, 10 Nov 1996 18:46:40 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA06952; Sun, 10 Nov 1996 18:46:33 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA04819; Mon, 11 Nov 1996 13:16:16 +1030 (CST) From: Michael Smith Message-Id: <199611110246.NAA04819@genesis.atrad.adelaide.edu.au> Subject: Re: /kernel: nfsd send error 55 (No buffer space available) In-Reply-To: <199611082014.OAA24913@Mars.mcs.net> from Michael Borowiec at "Nov 8, 96 02:14:30 pm" To: mikebo@tellabs.com Date: Mon, 11 Nov 1996 13:16:15 +1030 (CST) Cc: hackers@freebsd.org, bugs@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Borowiec stands accused of saying: ... > I have a Toshiba Tecra 720CDT w/48MB and a 3Com 3C589C PCCARD ethernet. Nice toy 8) > Of course, this is the dreaded mbuf problem, confirmed by trying a ping: > server# ping client > PING client (198.102.156.3): 56 data bytes > ping: sendto: No buffer space available > ping: wrote client 64 chars, ret=-1 > ... I don't actally think this _is_ the "dreaded mbuf problem" (whatever that might be). I think that you're discovering that the PCCARD support in 2.1.5 sucks pretty badly. Now, AFAIK the Tecras are cardbus machines, which means that the PCIC in them is probably not supported by the PAO code yet. You could ask on the freebsd-mobile mailing list (check the archives first) about that. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Nov 10 19:01:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA07379 for hackers-outgoing; Sun, 10 Nov 1996 19:01:07 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA07373 for ; Sun, 10 Nov 1996 19:00:42 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA04923; Mon, 11 Nov 1996 13:30:09 +1030 (CST) From: Michael Smith Message-Id: <199611110300.NAA04923@genesis.atrad.adelaide.edu.au> Subject: Re: Linux emulation In-Reply-To: <199611072218.RAA03424@crh.cl.msu.edu> from Charles Henrich at "Nov 7, 96 05:18:56 pm" To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Mon, 11 Nov 1996 13:30:08 +1030 (CST) Cc: freebsd-hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Charles Henrich stands accused of saying: > When running streamworks for linux I get bazillions (okay exageration) of not > implemented ioctl calls, all the same thing: > > fd=9, typ=0xc50(P),num=0x12 > > But it does seem to work okay, any ideas on what that IOCTL is? typedef struct count_info { int bytes; /* Total # of bytes processed */ int blocks; /* # of fragment transitions since last time */ int ptr; /* Current DMA pointer value */ } count_info; #define SNDCTL_DSP_GETOPTR _IOR ('P',18, count_info) and now you know as much as I do. > Charles Henrich Michigan State University henrich@msu.edu -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Nov 10 19:39:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA08944 for hackers-outgoing; Sun, 10 Nov 1996 19:39:12 -0800 (PST) Received: from delphi.bsd.uchicago.edu (delphi.bsd.uchicago.edu [128.135.5.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA08939 for ; Sun, 10 Nov 1996 19:39:06 -0800 (PST) Received: from bio-5.bsd.uchicago.edu (bio-5.bsd.uchicago.edu [128.135.75.14]) by delphi.bsd.uchicago.edu (8.7.6/8.7.3/BSD-4.0) with SMTP id VAA17488; Sun, 10 Nov 1996 21:38:59 -0600 (CST) Received: by bio-5.bsd.uchicago.edu (5.0/SMI-SVR4) id AA13774; Sun, 10 Nov 1996 21:38:53 +0600 Date: Sun, 10 Nov 1996 21:38:53 +0600 Message-Id: <9611110338.AA13774@bio-5.bsd.uchicago.edu> To: scrappy@ki.net Cc: hackers@FreeBSD.ORG In-Reply-To: <9611100512.AA13579@bio-5.bsd.uchicago.edu> (message from Tim Pierce on Sat, 9 Nov 1996 23:12:27 +0600) Subject: Re: semaphores/shared memory From: Tim Pierce Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: > > essentially, I want the server to write a line of data to > > shared memory, then signal all the clients at once that the data is > > there, so that they all pick up the data... > > It sounds like this ought to be easy if you simply have each > client wait on the semaphore, and then have the server increment > the semaphore by a suitably high number (e.g. MAXINT) in order to > ensure that they all are freed at once. No, sorry, even this shouldn't be necessary. Have the server create the semaphore and increment its value to 1. Then have each client wait until the semaphore becomes 0. When the data has been written to shared memory, have the server decrement the semaphore to zero, which will unblock all of the clients. From owner-freebsd-hackers Sun Nov 10 19:48:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA09341 for hackers-outgoing; Sun, 10 Nov 1996 19:48:23 -0800 (PST) Received: from pixel.planetx.com.au (root@pixel2.planetx.com.au [203.16.241.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA09334 for ; Sun, 10 Nov 1996 19:48:11 -0800 (PST) Received: from pixel.planetx.com.au (james@pixel.planetx.com.au [203.16.241.66]) by pixel.planetx.com.au (8.7.5/8.6.12) with SMTP id NAA17662; Mon, 11 Nov 1996 13:44:40 GMT Message-ID: <32872DC6.41C67EA6@planetx.com.au> Date: Mon, 11 Nov 1996 13:44:38 +0000 From: "James Gardiner [hunter]" Organization: Planet X Studios X-Mailer: Mozilla 3.0 (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Setting PPP netmask! HOW! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello all, I'm using PPP under 2.1.5 to connect to my ISP. I have my own C-Class but currently it is trashed as PPP under freebsd seems to not give you the option to set the netmask!! I have looked through the manuals with no help. I have made many guess attempts in the config files to see if it had any effect NADA! Anyway, what I need is to change the following --- ifconfig tun0 tun0: flags=8051 mtu 1500 inet 203.16.241.10 --> 203.8.105.10 netmask 0xffffff00 --- so the netmask is 0xfffffff8. If anyone knows how to do this I would love to know! My config follows --- default: set device /dev/cuaa1 set speed 57600 disable lqr deny lqr set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" iis: set phone xxxxxxxxx set login "TIMEOUT 5 username:-\\r-username: planetx word: xxxxxxxx Number 1" set timeout 9999 set ifaddr 203.16.241.10 203.8.105.10 add 0 0 203.8.105.10 #### set netmask 255.255.255.248 THIS DOES NOT WORK! --- If anyone knows the syntec to effect the netmask above please HELP! Thanks, James Gardiner -- http://www.planetx.com.au/~james From owner-freebsd-hackers Sun Nov 10 21:20:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA14715 for hackers-outgoing; Sun, 10 Nov 1996 21:20:41 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA14697 for ; Sun, 10 Nov 1996 21:20:38 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA21526; Mon, 11 Nov 1996 00:20:06 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 11 Nov 1996 00:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id WAA10744; Sun, 10 Nov 1996 22:14:35 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id WAA13515; Sun, 10 Nov 1996 22:15:54 -0500 (EST) Date: Sun, 10 Nov 1996 22:15:54 -0500 (EST) From: Thomas David Rivers Message-Id: <199611110315.WAA13515@lakes.water.net> To: ponds!klemm.gtn.com!andreas, gibbs@freefall.freebsd.org Subject: Re: Problems restoring Backups !!! Cc: ponds!marlin.com.br!acorreia, ponds!freebsd.org!hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >On Sat, 9 Nov 1996, Justin T. Gibbs wrote: > >Hi Justin, thanks that you take the time on that. BTW, I just wrote > >a problem report. I'm not sure if I had a kernel with your changes from > >Nov. 7th. But I'm just cvsupping and will repeat that with a new kernel. > > Your problem report had the information I needed to understand and fix your > problem. I changed the QUEUE FULL condition code to not do an > unconditional retry a little while ago, and you must be running out of > retries. You should be able to get this kind of thing to happen in other > scenarios besides dumping. I'll fix this today. > Is it possible this is related to the aha2940 problems I've been seeing with resetting the SCSI bus? (With 2.1.5-STABLE). Just to catch up - when I write a tape (say, with 'tar') [this is a WANGTEK 5150ES] - things go fine until the operation is complete. Then the tape drive begins to rewind and I get lots of messages, followed by (sometimes) a loop some where with the SCSI bus being reset over-and-over... I say sometimes because if the tape happens to be in a position where the rewind is quick, the problem doesn't degrade to a total SCSI lock-up. Here's my previous description of one of these: > Now, every time I write to the tape device (a Wangtek 5150ES QIC-150), > when I get to the end of the writing, and the tape begins to rewind; > *whamo* - my SCSI bus locks up.... > > The messages, of course, are not logged in /var/log/messages - because > nothing can be written out. > > I've jotted them down - from my paper notes they are: > > ahc0: Issued Channel A Bus Reset #1. n SCB's aborted > sd0(ahc0:0:0) timed out in message out phase, SCSISGI==0xb4 > sd0(ahc0:0:0) asserted ATN - device reset in message buffer > sd0(ahc0:0:0) timed out in message out phase, SCSISGI==0xa4 - Thanks - - Dave Rivers - From owner-freebsd-hackers Sun Nov 10 21:21:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA14758 for hackers-outgoing; Sun, 10 Nov 1996 21:21:29 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA14749 for ; Sun, 10 Nov 1996 21:21:26 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id VAA09766; Sun, 10 Nov 1996 21:20:20 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id QAA06904; Mon, 11 Nov 1996 16:20:02 +1100 From: Julian Assange Message-Id: <199611110520.QAA06904@suburbia.net> Subject: Re: virtual hosting with inetd To: julian@whistle.com (Julian Elischer) Date: Mon, 11 Nov 1996 16:20:02 +1100 (EST) Cc: proff@suburbia.net, freebsd-hackers@freebsd.org In-Reply-To: <32864F96.41C67EA6@whistle.com> from "Julian Elischer" at Nov 10, 96 01:56:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Julian Assange wrote: > > > > Does anyone have any other comments on the patch > > I produced? Terry, did I address yours? > > Is it commitable? > > they are definitly useful, and we might need them in the near future.. > I need to look at xinetd some time to see how much should be added to > our inetd and how much should be considered "use xinetd instead". The xnited in ports doesn't do virtual hosting. At least not that I could see. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Sun Nov 10 22:46:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA21249 for hackers-outgoing; Sun, 10 Nov 1996 22:46:04 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA21244 for ; Sun, 10 Nov 1996 22:46:01 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id HAA31987 for ; Mon, 11 Nov 1996 07:45:56 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id HAA06226 for freebsd-hackers@freebsd.org; Mon, 11 Nov 1996 07:45:22 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id HAA22524; Mon, 11 Nov 1996 07:39:42 +0100 (MET) Message-ID: Date: Mon, 11 Nov 1996 07:39:41 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-hackers@freebsd.org Subject: Re: Setting PPP netmask! HOW! References: <32872DC6.41C67EA6@planetx.com.au> X-Mailer: Mutt 0.50.04 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2686 In-Reply-To: <32872DC6.41C67EA6@planetx.com.au>; from James Gardiner [hunter] on Nov 11, 1996 13:44:38 +0000 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to James Gardiner [hunter]: > Anyway, what I need is to change the following > --- > ifconfig tun0 > tun0: flags=8051 mtu 1500 > inet 203.16.241.10 --> 203.8.105.10 netmask 0xffffff00 > --- > so the netmask is 0xfffffff8. > If anyone knows how to do this I would love to know! I am afraid it is a known [by the author] bug of iij-ppp. I tried to get the same thing as you a while ago, found that it didn't work, contacted the author and reverted to kernel pppd, which will do it fine. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996 From owner-freebsd-hackers Sun Nov 10 23:09:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA22920 for hackers-outgoing; Sun, 10 Nov 1996 23:09:24 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA22911 for ; Sun, 10 Nov 1996 23:09:12 -0800 (PST) Received: from misery.sdf.com ([204.244.213.33]) by misery.sdf.com with SMTP id <1283-3086>; Sun, 10 Nov 1996 23:38:52 -0800 Date: Sun, 10 Nov 1996 23:38:46 -0800 (PST) From: Tom Samplonius To: Julian Assange cc: Julian Elischer , freebsd-hackers@freebsd.org Subject: Re: virtual hosting with inetd In-Reply-To: <199611110520.QAA06904@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Julian Assange wrote: > > Julian Assange wrote: > > > > > > Does anyone have any other comments on the patch > > > I produced? Terry, did I address yours? > > > Is it commitable? > > > > they are definitly useful, and we might need them in the near future.. > > I need to look at xinetd some time to see how much should be added to > > our inetd and how much should be considered "use xinetd instead". > > The xnited in ports doesn't do virtual hosting. At least not that I > could see. Yes, it does. Look at the "interface" directive in the man page. xinetd has had this feature since June 95 (date in doc). The access control, and instances limitation features are probably much older. xinetd is actually a very mature and stable product. Tom From owner-freebsd-hackers Mon Nov 11 00:05:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA27385 for hackers-outgoing; Mon, 11 Nov 1996 00:05:17 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA27373 for ; Mon, 11 Nov 1996 00:05:13 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id AAA12317; Mon, 11 Nov 1996 00:05:03 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id TAA21549; Mon, 11 Nov 1996 19:04:41 +1100 From: Julian Assange Message-Id: <199611110804.TAA21549@suburbia.net> Subject: Re: virtual hosting with inetd To: tom@sdf.com (Tom Samplonius) Date: Mon, 11 Nov 1996 19:04:40 +1100 (EST) Cc: proff@suburbia.net, julian@whistle.com, freebsd-hackers@freebsd.org In-Reply-To: from "Tom Samplonius" at Nov 10, 96 11:38:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Mon, 11 Nov 1996, Julian Assange wrote: > > > The xnited in ports doesn't do virtual hosting. At least not that I > > could see. > > Yes, it does. Look at the "interface" directive in the man page. > > Tom It isn't in the man page (checked again). However it is in the source. However, I don't like it much. o doesn't handle hostnames o doesn't handle multi-homed host names o entirely new record has to be created for every service on every interface! o everything has to be in the one file. administration nightmare. say you are running 200 virtual servers with 4 services each = around 6400 xinetd lines. and grep won't work on it. o uses bloated multi-line-per-service xinetd config style ;) -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Mon Nov 11 00:07:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA27530 for hackers-outgoing; Mon, 11 Nov 1996 00:07:02 -0800 (PST) Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA27508 for ; Mon, 11 Nov 1996 00:06:47 -0800 (PST) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.8.2/Sogang) id RAA02673; Mon, 11 Nov 1996 17:01:31 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA23163; Mon, 11 Nov 96 17:05:01 KST From: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Message-Id: <9611110805.AA23163@cslsun10.sogang.ac.kr> Subject: working set model To: freebsd-hackers@FreeBSD.ORG Date: Mon, 11 Nov 1996 17:05:00 +0900 (KST) Cc: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello there i have some question about FreeBSD memory management i would that know how memory to provide to each process to minimize the latter's page fault behavior i know, freebsd memory management does not use the working set medel because it lacks accurate information about the reference pattern of a process. but i wish to obtain reference pattern during the executing of one process. and i used to the object and offset , but i think it is not. then to obtain reference page pattern, what function or what variable is used. i want to know this problem. please send me a good news. have a good day! From owner-freebsd-hackers Mon Nov 11 00:38:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA29721 for hackers-outgoing; Mon, 11 Nov 1996 00:38:21 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA29709 for ; Mon, 11 Nov 1996 00:38:18 -0800 (PST) Message-Id: <199611110838.AAA29709@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA103601505; Mon, 11 Nov 1996 19:38:25 +1100 From: Darren Reed Subject: Re: Inetd mod.. comments? To: smpatel@umiacs.umd.edu (Sujal Patel) Date: Mon, 11 Nov 1996 19:38:25 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: from "Sujal Patel" at Nov 10, 96 02:39:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Sujal Patel, sie said: > > On Sun, 10 Nov 1996, Darren Reed wrote: > > > > 3 - Limit the number of concurrent TCP connections to a port. > > > 4 - Limit the number of concurrent TCP connections from a host/domain. > > > > These are more properly enforced by whatever it is that is managing those > > connections (ie inetd). > > I don't agree with this because hacking inetd can only get you so far. > There are many services such as ssh, sendmail, and http that don't > generally get launched from inetd. I'd hate to hack a half dozen user > apps when a simple kernel level solution exists. Besides, other firewall > products do it, why can't our ipfw? Which other firewall products and where do they implement it ? The "where" is important, here, because firewall vendors are providing a complete suite of programs to sit in on behalf of sendmail, etc, so it is more likely they can do things "correctly". Darren From owner-freebsd-hackers Mon Nov 11 00:45:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA00434 for hackers-outgoing; Mon, 11 Nov 1996 00:45:00 -0800 (PST) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA00422 for ; Mon, 11 Nov 1996 00:44:56 -0800 (PST) Received: from misery.sdf.com ([204.244.213.33]) by misery.sdf.com with SMTP id <1283-3087>; Mon, 11 Nov 1996 01:14:56 -0800 Date: Mon, 11 Nov 1996 01:14:40 -0800 (PST) From: Tom Samplonius To: Julian Assange cc: julian@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: virtual hosting with inetd In-Reply-To: <199611110804.TAA21549@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Julian Assange wrote: > > On Mon, 11 Nov 1996, Julian Assange wrote: > > > > > The xnited in ports doesn't do virtual hosting. At least not that I > > > could see. > > > > Yes, it does. Look at the "interface" directive in the man page. > > > > Tom > > It isn't in the man page (checked again). However it is in the source. > However, I don't like it much. > > o doesn't handle hostnames > o doesn't handle multi-homed host names I don't think you want this. Hostname lookups for 200 hostnames could take a while, especially if DNS is down. Imagine long delays when no connections are accepted while re-loading the config file. > o entirely new record has to be created for every service on > every interface! > o everything has to be in the one file. administration nightmare. > say you are running 200 virtual servers with 4 services each > = around 6400 xinetd lines. and grep won't work on it. > o uses bloated multi-line-per-service xinetd config style ;) The config format is flexible, and allows each service to be different. 6400 lines isn't that much. I'd be trival to make a script to generate the entire file from a template and list of hostnames. This way the script could go do the DNS lookups. Also, an average xinetd config entry is not even close to 32 lines (32*200=6400), in fact I don't think it possible to have an entry that long. > -- > "Of all tyrannies a tyranny sincerely exercised for the good of its victims > may be the most oppressive. It may be better to live under robber barons > than under omnipotent moral busybodies, The robber baron's cruelty may > sometimes sleep, his cupidity may at some point be satiated; but those who > torment us for own good will torment us without end, for they do so with > the approval of their own conscience." - C.S. Lewis, _God in the Dock_ > +---------------------+--------------------+----------------------------------+ > |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | > |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | > |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | > +---------------------+--------------------+----------------------------------+ > Tom From owner-freebsd-hackers Mon Nov 11 01:06:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA01931 for hackers-outgoing; Mon, 11 Nov 1996 01:06:52 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA01923 for ; Mon, 11 Nov 1996 01:06:46 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id BAA01446 for ; Mon, 11 Nov 1996 01:06:48 -0800 (PST) To: hackers@freebsd.org Subject: Re: Anyone care to write a novice's guide to visual UserConfig? Date: Mon, 11 Nov 1996 01:06:48 -0800 Message-ID: <1444.847703208@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks to all who volunteered for this! I'm most grateful. Michael Smith, clearly shamed into writing docs for his own code, has provided me with a full tutorial on the thing which I shall be SGML-ifying and otherwise converting into docs material. This should really help new users out, and my thanks go out to Mike (and all others who offered to help) for this. Thanks, guys! Between this and the new XFree86 setup utility, which actually goes graphical now and integrates *seamlessly* into FreeBSD's install, I think new users are going to find 2.1.6 and 2.2 the most approachable FreeBSD releases yet. Jordan From owner-freebsd-hackers Mon Nov 11 01:24:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA03248 for hackers-outgoing; Mon, 11 Nov 1996 01:24:58 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA03238 for ; Mon, 11 Nov 1996 01:24:55 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id BAA02797 for ; Mon, 11 Nov 1996 01:24:53 -0800 (PST) Message-Id: <199611110924.BAA02797@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: http://www.x86.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Nov 1996 01:24:52 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thats the N-Tel web page and it has Pentium Pro manuals in adobe acrobat format. Hopefully, the Pentium Pro 32 bit optimization manual will be be of use. Enjoy, Amancio From owner-freebsd-hackers Mon Nov 11 01:37:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA03918 for hackers-outgoing; Mon, 11 Nov 1996 01:37:48 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA03908 for ; Mon, 11 Nov 1996 01:37:43 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id BAA13380; Mon, 11 Nov 1996 01:37:33 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id UAA25288; Mon, 11 Nov 1996 20:37:02 +1100 From: Julian Assange Message-Id: <199611110937.UAA25288@suburbia.net> Subject: Re: virtual hosting with inetd To: tom@sdf.com (Tom Samplonius) Date: Mon, 11 Nov 1996 20:37:01 +1100 (EST) Cc: proff@suburbia.net, julian@whistle.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tom Samplonius" at Nov 11, 96 01:14:40 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > o doesn't handle hostnames > > o doesn't handle multi-homed host names > > I don't think you want this. Hostname lookups for 200 hostnames could > take a while, especially if DNS is down. Imagine long delays when no > connections are accepted while re-loading the config file. If you are the virtual server for those sites, you are very likely to be the primary name server, and if not a secondary name server and if not that, then /etc/hosts ;) > > o everything has to be in the one file. administration nightmare. > > say you are running 200 virtual servers with 4 services each ^^^^^^^^^^ > > = around 6400 xinetd lines. and grep won't work on it. > > o uses bloated multi-line-per-service xinetd config style ;) > [..] > script could go do the DNS lookups. Also, an average xinetd config entry > is not even close to 32 lines (32*200=6400), in fact I don't think it > possible to have an entry that long. 4*8*200=6400 -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Mon Nov 11 01:48:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA04357 for hackers-outgoing; Mon, 11 Nov 1996 01:48:26 -0800 (PST) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA04351 for ; Mon, 11 Nov 1996 01:48:23 -0800 (PST) Message-Id: <199611110948.BAA04351@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA116835719; Mon, 11 Nov 1996 20:48:39 +1100 From: Darren Reed Subject: Re: Anyone care to write a novice's guide to visual UserConfig? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 11 Nov 1996 20:48:39 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <1444.847703208@time.cdrom.com> from "Jordan K. Hubbard" at Nov 11, 96 01:06:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Jordan K. Hubbard, sie said: [...] > graphical now and integrates *seamlessly* into FreeBSD's install, I > think new users are going to find 2.1.6 and 2.2 the most approachable > FreeBSD releases yet. So long as they eventually get released...maybe even sooner rather than later ? ;-) From owner-freebsd-hackers Mon Nov 11 02:44:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA07247 for hackers-outgoing; Mon, 11 Nov 1996 02:44:21 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA07242 for ; Mon, 11 Nov 1996 02:44:18 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id FAA12226; Mon, 11 Nov 1996 05:44:23 -0500 (EST) Date: Mon, 11 Nov 1996 05:44:19 -0500 (EST) From: "Marc G. Fournier" To: Tim Pierce cc: hackers@FreeBSD.ORG Subject: Re: semaphores/shared memory In-Reply-To: <9611110338.AA13774@bio-5.bsd.uchicago.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Nov 1996, Tim Pierce wrote: > I wrote: > > > > essentially, I want the server to write a line of data to > > > shared memory, then signal all the clients at once that the data is > > > there, so that they all pick up the data... > > > > It sounds like this ought to be easy if you simply have each > > client wait on the semaphore, and then have the server increment > > the semaphore by a suitably high number (e.g. MAXINT) in order to > > ensure that they all are freed at once. > > No, sorry, even this shouldn't be necessary. Have the server > create the semaphore and increment its value to 1. Then have each > client wait until the semaphore becomes 0. When the data has been > written to shared memory, have the server decrement the semaphore > to zero, which will unblock all of the clients. > Okay, now bearing in mind that I'm looking at the examples as presented in "Unix Network Programming" by W. Richard Stevens...how do n clients signal back to the server that its finished with the data and can send up the next set of data? Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Mon Nov 11 02:49:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA07410 for hackers-outgoing; Mon, 11 Nov 1996 02:49:23 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA07402 for ; Mon, 11 Nov 1996 02:49:20 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id CAA01975; Mon, 11 Nov 1996 02:49:17 -0800 (PST) To: Darren Reed cc: hackers@freebsd.org Subject: Re: Anyone care to write a novice's guide to visual UserConfig? In-reply-to: Your message of "Mon, 11 Nov 1996 20:48:39 +1100." <199611110948.BAA01651@time.cdrom.com> Date: Mon, 11 Nov 1996 02:49:17 -0800 Message-ID: <1973.847709357@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So long as they eventually get released...maybe even sooner rather than > later ? ;-) Uh, you can expect ALPHAs for both in the next week or so. These releases are very much on the near horizon. Jordan From owner-freebsd-hackers Mon Nov 11 06:16:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA15721 for hackers-outgoing; Mon, 11 Nov 1996 06:16:12 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA15713 for ; Mon, 11 Nov 1996 06:16:09 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA15080; Mon, 11 Nov 1996 09:15:02 -0500 Date: Mon, 11 Nov 1996 09:15:02 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: "Marc G. Fournier" cc: Tim Pierce , hackers@freebsd.org Subject: Re: semaphores/shared memory In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Marc G. Fournier wrote: > On Sun, 10 Nov 1996, Tim Pierce wrote: > > No, sorry, even this shouldn't be necessary. Have the server > > create the semaphore and increment its value to 1. Then have each > > client wait until the semaphore becomes 0. When the data has been > > written to shared memory, have the server decrement the semaphore > > to zero, which will unblock all of the clients. > Okay, now bearing in mind that I'm looking at the examples as > presented in "Unix Network Programming" by W. Richard Stevens...how > do n clients signal back to the server that its finished with the data > and can send up the next set of data? have the lock lock a bitmask. Then use fdsets to set/clear bits. Client 'n' does and FDSET(n, ready_mask). I've done this -- works fine. server should initially zero the mask. ron From owner-freebsd-hackers Mon Nov 11 06:20:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA16062 for hackers-outgoing; Mon, 11 Nov 1996 06:20:43 -0800 (PST) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA16048 for ; Mon, 11 Nov 1996 06:20:28 -0800 (PST) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.7.6/8.7.3) id QAA08546 for hackers@freebsd.org; Mon, 11 Nov 1996 16:20:20 +0200 (SAT) From: John Hay Message-Id: <199611111420.QAA08546@zibbi.mikom.csir.co.za> Subject: CTM running? To: hackers@freebsd.org Date: Mon, 11 Nov 1996 16:20:20 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL24 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, It has been almost 24 hours since the last cvs-cur ctm update that I received. Is there something on freefall or has it been switched off for some reason? I don't really know where to send this, so if there is some better place just tell me. John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Mon Nov 11 06:49:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA17578 for hackers-outgoing; Mon, 11 Nov 1996 06:49:45 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA17568 for ; Mon, 11 Nov 1996 06:49:42 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id JAA01072; Mon, 11 Nov 1996 09:53:19 -0500 Date: Mon, 11 Nov 1996 09:53:19 -0500 Message-Id: <199611111453.JAA01072@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "James Gardiner [hunter]" From: dennis@etinc.com (dennis) Subject: Re: Setting PPP netmask! HOW! Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hello all, > >I'm using PPP under 2.1.5 to connect to my ISP. I have my own >C-Class but currently it is trashed as PPP under freebsd seems >to not give you the option to set the netmask!! I have looked >through the manuals with no help. I have made many guess attempts >in the config files to see if it had any effect NADA! Thats because FreeBSD is smart enough to know how to route to a host address, unlike many of the more popular routers on the market. I believe that the netmask is meaningless on a PTP interface, so even if you get it to display the way you want you won't have achieved much of anything. Dennis From owner-freebsd-hackers Mon Nov 11 08:37:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24405 for hackers-outgoing; Mon, 11 Nov 1996 08:37:59 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA24394 for ; Mon, 11 Nov 1996 08:37:53 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <19527(7)>; Mon, 11 Nov 1996 08:37:16 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Mon, 11 Nov 1996 08:37:04 -0800 To: roberto@keltia.freenix.fr (Ollivier Robert) cc: freebsd-hackers@freebsd.org Subject: Re: Setting PPP netmask! HOW! In-reply-to: Your message of "Sun, 10 Nov 96 22:39:41 PST." Date: Mon, 11 Nov 1996 08:37:04 PST From: Bill Fenner Message-Id: <96Nov11.083704pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message you write: >According to James Gardiner [hunter]: >> Anyway, what I need is to change the following >> --- >> ifconfig tun0 >> tun0: flags=8051 mtu 1500 >> inet 203.16.241.10 --> 203.8.105.10 netmask 0xffffff00 >> --- >> so the netmask is 0xfffffff8. >> If anyone knows how to do this I would love to know! If ppp won't do it for you properly, you can always set it after ppp configures it; just say "ifconfig tun0 netmask 0xfffffff8". Bill From owner-freebsd-hackers Mon Nov 11 08:57:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA25542 for hackers-outgoing; Mon, 11 Nov 1996 08:57:01 -0800 (PST) Received: from delphi.bsd.uchicago.edu (delphi.bsd.uchicago.edu [128.135.5.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA25537 for ; Mon, 11 Nov 1996 08:56:59 -0800 (PST) Received: from bio-5.bsd.uchicago.edu (bio-5.bsd.uchicago.edu [128.135.75.14]) by delphi.bsd.uchicago.edu (8.7.6/8.7.3/BSD-4.0) with SMTP id KAA07022; Mon, 11 Nov 1996 10:56:57 -0600 (CST) Received: by bio-5.bsd.uchicago.edu (5.0/SMI-SVR4) id AA13857; Mon, 11 Nov 1996 10:56:51 +0600 Date: Mon, 11 Nov 1996 10:56:51 +0600 Message-Id: <9611111656.AA13857@bio-5.bsd.uchicago.edu> To: scrappy@ki.net Cc: hackers@FreeBSD.ORG In-Reply-To: (scrappy@ki.net) Subject: Re: semaphores/shared memory From: Tim Pierce Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Marc G. Fournier" wrote: > I wrote: > > > No, sorry, even this shouldn't be necessary. Have the server > > create the semaphore and increment its value to 1. Then have each > > client wait until the semaphore becomes 0. When the data has been > > written to shared memory, have the server decrement the semaphore > > to zero, which will unblock all of the clients. > > Okay, now bearing in mind that I'm looking at the examples as > presented in "Unix Network Programming" by W. Richard Stevens...how > do n clients signal back to the server that its finished with the data > and can send up the next set of data? Now the model is reversed: the clients possess a resource that the server needs to wait for. Have the server wait on the semaphore until its value becomes equal to `n' (where n is the number of clients). Each client, when it finishes using the shared memory, increments the semaphore; when they are all done, the semaphore's value will equal `n' and the server will unblock. This looks straightforward from my reading of Stevens. From owner-freebsd-hackers Mon Nov 11 09:25:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA27399 for hackers-outgoing; Mon, 11 Nov 1996 09:25:57 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA27386 for ; Mon, 11 Nov 1996 09:25:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA18275; Mon, 11 Nov 1996 10:14:57 -0700 From: Terry Lambert Message-Id: <199611111714.KAA18275@phaeton.artisoft.com> Subject: Re: working set model To: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Date: Mon, 11 Nov 1996 10:14:57 -0700 (MST) Cc: freebsd-hackers@freebsd.org, cskim@cslsun10.sogang.ac.kr In-Reply-To: <9611110805.AA23163@cslsun10.sogang.ac.kr> from "Kim Chang Seob" at Nov 11, 96 05:05:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > i have some question about FreeBSD memory management > i would that know how memory to provide to each process > to minimize the latter's page fault behavior > i know, freebsd memory management does not use the working set medel > because it lacks accurate information about the reference pattern > of a process. This really depends on if you believe LRU works for caching. This, in turn, depends on whether you believe in locality of reference. The theory is that if the buffer and vm cache are the same thing, vm references will change the LRU position, and the locality will be optimized for future hits. That is, you will not really be able to make it more efficient. A working set model is only useful in the case of badly behaved processes. The cannonically worst offender of all time is the SVR4 "ld", which mmap's .o files into memory and traverses the symbol space during linking, instead of building a link graph in memory from the object data. The result is that you will get a disproportionately high amount of locality in the pages mmapped and referenced this way... and other processes data will be forced out of cache as a result. The working set model that makes sense in this case is *not* a per process working set -- it's a per vnode working set. It is relatively trivial to implement and test this change: all you have to do is maintin a buffer count on the number of buffers hung off a vnode, and modify your LRU insertion order on freed buffers for vnodes over quota, and modify reclaimation for allocation of pages for vnodes over quota to steal from the local vnode's LRU instead of the system LRU. Together, these will prevent the working set of a single vnode from growing "too large", causing the LRU locality to break down across context switches. The final (optional) piece would allow priveledged processes to relax their quotas; there are some uses where it's important that a process be efficient at the expense of other processes on the system. I would suggest "madvise" as the best bet, but it would mean taking the memory range specified as a hint to identify the vnode that you want to affect. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 11 09:28:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA27606 for hackers-outgoing; Mon, 11 Nov 1996 09:28:31 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA27599 for ; Mon, 11 Nov 1996 09:28:28 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA18289; Mon, 11 Nov 1996 10:17:19 -0700 From: Terry Lambert Message-Id: <199611111717.KAA18289@phaeton.artisoft.com> Subject: Re: semaphores/shared memory To: scrappy@ki.net (Marc G. Fournier) Date: Mon, 11 Nov 1996 10:17:19 -0700 (MST) Cc: twpierce@bio-3.bsd.uchicago.edu, hackers@freebsd.org In-Reply-To: from "Marc G. Fournier" at Nov 11, 96 05:44:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > No, sorry, even this shouldn't be necessary. Have the server > > create the semaphore and increment its value to 1. Then have each > > client wait until the semaphore becomes 0. When the data has been > > written to shared memory, have the server decrement the semaphore > > to zero, which will unblock all of the clients. > > > > Okay, now bearing in mind that I'm looking at the examples as > presented in "Unix Network Programming" by W. Richard Stevens...how > do n clients signal back to the server that its finished with the data > and can send up the next set of data? This is why I didn't suggest the same soloution. However, now I have to question my assumptions... why is it necessary for the clients to signal the server? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 11 09:41:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA28382 for hackers-outgoing; Mon, 11 Nov 1996 09:41:48 -0800 (PST) Received: from starfire.mn.org (root@starfire.skypoint.net [199.86.32.187]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA28355; Mon, 11 Nov 1996 09:41:36 -0800 (PST) From: john@starfire.mn.org Received: (from john@localhost) by starfire.mn.org (8.7.5/1.1) id LAA15056; Mon, 11 Nov 1996 11:41:33 -0600 (CST) Message-Id: <199611111741.LAA15056@starfire.mn.org> Subject: PPP/LCP sensing getty To: hackers@FreeBSD.org (FreeBSD hackers) Date: Mon, 11 Nov 1996 11:41:33 -0600 (CST) Cc: freebsd-isp@FreeBSD.org X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I have created a version of getty that watches for the first four bytes of the LCP leader and exec's pppd (-detach auth) if it sees it. This allows dialup PPP access to FreeBSD boxes from other FreeBSD boxes, Windows 3.1, Windows NT, Windows 95, and MAC's without having to go through the pain of login scripting. I'd like to make this generally available, but am not sure how best to do so. The change is very small, only about 8 lines of code, and doesn't change the size of the stripped executable. Should it be submitted as a permanent inclusion in getty? If so, it should probably be specifically enabled by a parameter or an extension to gettytab. Of course, either of those will increase the size of the change to the program, so maybe it is best to leave it as a separate program that sites can use in place of the regular getty. On the other hand, "getty" is pretty essential to BSD and has been around forever, and is likely to stay around for a good long time, as well. That isn't as true of pppd. To have the path to pppd compiled into getty is a real lack of symmetry in that respect. I dunno. Too many options without enough information for me to make informed choices. Right now, on my system, I simply created a "gettyppp" and put it in /etc/ttys in place of getty for the log in ports. It is sort of a silly waste of RAM and/or swap space to have both "getty" and "gettyppp" so perhaps I should just plain replace getty with gettyppp. I'm not too concerned about someone accidentally typing the LCP header from a virtual terminal or something. It would be pretty hard to do, and wouldn't accomplish anything that wouldn't resolve itself. Suggestions and comments are most welcome. Please help me figure out how best to finish off this project and make it generally useful. John Lind, Starfire Consulting Services E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417 From owner-freebsd-hackers Mon Nov 11 09:46:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA28824 for hackers-outgoing; Mon, 11 Nov 1996 09:46:25 -0800 (PST) Received: from pluto.plutotech.com (root@pluto.plutotech.com [206.168.67.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA28819 for ; Mon, 11 Nov 1996 09:46:21 -0800 (PST) Received: from shane.plutotech.com (durian@shane.plutotech.com [206.168.67.21]) by pluto.plutotech.com (8.8.2/8.8.2) with ESMTP id KAA28562; Mon, 11 Nov 1996 10:35:29 -0700 (MST) Message-Id: <199611111735.KAA28562@pluto.plutotech.com> From: "Mike Durian" To: se@zpr.uni-koeln.de (Stefan Esser) cc: freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-reply-to: Your message of "Mon, 11 Nov 1996 00:10:20 +0100." Date: Mon, 11 Nov 1996 10:35:29 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996 00:10:20 +0100, se@zpr.uni-koeln.de (Stefan Esser) wrote: > >Please test the patches you'll find appended to this message ... I gave them a shot, and they seem to work fine. >Yes. > >Hmmm, but the same should apply to the memory regions! You're right. I didn't notice that. >Please test my suggested fix (you seem to have the required hardware, >or you wouldn't have noticed there was a problem, I suppose ;-) Yup. 4 PCI busses, 3 PCI-PCI bridges and about 20 adaptec conrollers. I'm guessing not many people are pushing the PCI spec as far. (In fact, we discovered a bug in the AMI bios that won't properly initialize more than 4 devices on the secondary busses). >Well, I can only agree to half of that sentence: The mapping type is >found in the address, but also in the size. The low bits of the map >registers are hardwired. For that reason, (data & 7) is guaranteed >to be identical to (map & 7) ... I'm not seeing this. I'm enclosing some output from a boot on my machine (not the one will all the PCI busses). I've added printfs to show the value of map, data and the addr, size parameters in each of the two cases. As you can see (as in the ahc device), there are cases where the lower nybble differs in the map and data variables. You can also see where a memory region gets treated as an io region. I'm still not sure about the strange 0x500a1011 io address found on the DEC ethernet cards. The BIOS is AMI. mike Nov 11 09:55:53 shane /kernel: FreeBSD 2.1.5-RELEASE #40: Mon Nov 11 09:54:30 MST 1996 Nov 11 09:55:53 shane /kernel: durian@shane.plutotech.com:/usr/src/sys-head/compile/AVIO Nov 11 09:55:53 shane /kernel: CPU: 132-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) Nov 11 09:55:53 shane /kernel: Origin = "GenuineIntel" Id = 0x52b Stepping=11 Nov 11 09:55:53 shane /kernel: Features=0x1bf Nov 11 09:55:53 shane /kernel: dedicated mem= 2097152 (2048K) from 31457280 (30720K) to 33554432 (32768K) Nov 11 09:55:54 shane /kernel: real memory = 31457280 (30720K bytes) Nov 11 09:55:54 shane /kernel: avail memory = 28557312 (27888K bytes) Nov 11 09:55:54 shane /kernel: Probing for devices on PCI bus 0: Nov 11 09:55:54 shane /kernel: ahc0 rev 0 int a irq 11 on pci0:20 Nov 11 09:55:55 shane /kernel: map = 0xfc01, data = 0xffffff01 Nov 11 09:55:55 shane /kernel: case 1,5: I/O addr = 0xfc00, size = 0x100 Nov 11 09:55:55 shane /kernel: map = 0xffbdf000, data = 0xfffff000 Nov 11 09:55:55 shane /kernel: case 0,2,4: memory addr = 0xffbdf000, size = 0x1000 Nov 11 09:55:55 shane /kernel: map = 0xffbc0000, data = 0xffff0001 Nov 11 09:55:55 shane /kernel: case 1,5: I/O addr = 0xffbc0000, size = 0x10000 Nov 11 09:55:56 shane /kernel: ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Nov 11 09:55:56 shane /kernel: ahc0 waiting for scsi devices to settle Nov 11 09:55:56 shane /kernel: ahc0: Getting Another SCB? numscb = 0 maxscb = 16 Nov 11 09:55:56 shane /kernel: (ahc0:0:0): "SEAGATE ST31230W 0640" type 0 fixed SCSI 2 Nov 11 09:55:56 shane /kernel: sd0(ahc0:0:0): Direct-Access 1010MB (2069860 512 byte sectors) Nov 11 09:55:56 shane /kernel: ahc0:A:2: refuses WIDE negotiation. Using 8bit transfers Nov 11 09:55:57 shane /kernel: (ahc0:2:0): "TOSHIBA CD-ROM XM-3701TA 3205" type 5 removable SCSI 2 Nov 11 09:55:57 shane /kernel: cd0(ahc0:2:0): CD-ROM cd present.[140377 x 2048 byte records] Nov 11 09:55:57 shane /kernel: ahc0:A:6: refuses WIDE negotiation. Using 8bit transfers Nov 11 09:55:57 shane /kernel: ahc0:A:6: refuses syncronous negotiation. Using asyncronous transfers Nov 11 09:55:57 shane /kernel: (ahc0:6:0): "HP C4324/C4325 1.27" type 5 removable SCSI 2 Nov 11 09:55:57 shane /kernel: worm0(ahc0:6:0): Write-Once - UNTESTED Nov 11 09:55:58 shane /kernel: worm0(ahc0:6:0): NOT READY asc:4,0 Nov 11 09:55:58 shane /kernel: worm0(ahc0:6:0): Logical unit not ready, cause not reportable Nov 11 09:55:58 shane /kernel: Nov 11 09:55:58 shane /kernel: worm0(ahc0:6:0): could not get size Nov 11 09:55:58 shane /kernel: - can't get capacity. Nov 11 09:55:59 shane /kernel: vga0 rev 3 on pci0:19 Nov 11 09:55:59 shane /kernel: map = 0xfe000000, data = 0xff000000 Nov 11 09:55:59 shane /kernel: case 0,2,4: memory addr = 0xfe000000, size = 0x1000000 Nov 11 09:55:59 shane /kernel: map = 0xffbe0000, data = 0xffff0001 Nov 11 09:55:59 shane /kernel: case 1,5: I/O addr = 0xffbe0000, size = 0x10000 Nov 11 09:55:59 shane /kernel: de0 rev 32 int a irq 10 on pci0:18 Nov 11 09:55:59 shane /kernel: map = 0xf881, data = 0xffffff81 Nov 11 09:56:00 shane /kernel: case 1,5: I/O addr = 0xf880, size = 0x80 Nov 11 09:56:00 shane /kernel: map = 0xffbdef80, data = 0xffffff80 Nov 11 09:56:00 shane /kernel: case 0,2,4: memory addr = 0xffbdef80, size = 0x80 Nov 11 09:56:00 shane /kernel: map = 0x500a1011, data = 0x500a1011 Nov 11 09:56:00 shane /kernel: case 1,5: I/O addr = 0x500a1010, size = 0x10 Nov 11 09:56:00 shane /kernel: map = 0xffb80000, data = 0xfffc0001 Nov 11 09:56:00 shane /kernel: case 1,5: I/O addr = 0xffb80000, size = 0x40000 Nov 11 09:56:00 shane /kernel: de0: DE500-AA DC21140A [10-100Mb/s] pass 2.0 Nov 11 09:56:00 shane /kernel: de0: address 00:00:f8:02:be:16 Nov 11 09:56:00 shane /kernel: de0(phy5): model = NS DP83840 (supports media autonegotiation) Nov 11 09:56:00 shane /kernel: de0(phy5): media = 10baseT, Full Duplex 10baseT, 100baseTX, Full Duplex 100baseTX Nov 11 09:56:01 shane /kernel: de0(phy5): autonegotiation restarted: 0x3300 Nov 11 09:56:01 shane /kernel: de1 rev 32 int a irq 15 on pci0:17 Nov 11 09:56:01 shane /kernel: map = 0xf801, data = 0xffffff81 Nov 11 09:56:01 shane /kernel: case 1,5: I/O addr = 0xf800, size = 0x80 Nov 11 09:56:01 shane /kernel: map = 0xffbdef00, data = 0xffffff80 Nov 11 09:56:01 shane /kernel: case 0,2,4: memory addr = 0xffbdef00, size = 0x80 Nov 11 09:56:01 shane /kernel: map = 0x500a1011, data = 0x500a1011 Nov 11 09:56:01 shane /kernel: case 1,5: I/O addr = 0x500a1010, size = 0x10 Nov 11 09:56:01 shane /kernel: map = 0xffb40000, data = 0xfffc0001 Nov 11 09:56:01 shane /kernel: case 1,5: I/O addr = 0xffb40000, size = 0x40000 Nov 11 09:56:01 shane /kernel: de1: DE500-AA DC21140A [10-100Mb/s] pass 2.0 Nov 11 09:56:02 shane /kernel: de1: address 00:00:f8:02:c5:5f Nov 11 09:56:02 shane /kernel: de1(phy5): model = NS DP83840 (supports media autonegotiation) Nov 11 09:56:02 shane /kernel: de1(phy5): media = 10baseT, Full Duplex 10baseT, 100baseTX, Full Duplex 100baseTX Nov 11 09:56:02 shane /kernel: de1(phy5): autonegotiation restarted: 0x3300 Nov 11 09:56:02 shane /kernel: chip0 rev 2 on pci0:7:0 Nov 11 09:56:02 shane /kernel: chip1 rev 2 on pci0:7:1 Nov 11 09:56:02 shane /kernel: map = 0xfff1, data = 0xfff1 Nov 11 09:56:02 shane /kernel: case 1,5: I/O addr = 0xfff0, size = 0x10 Nov 11 09:56:02 shane /kernel: chip2 rev 2 on pci0:0 Nov 11 09:56:02 shane /kernel: Probing for devices on the ISA bus: Nov 11 09:56:02 shane /kernel: sc0 at 0x60-0x6f irq 1 on motherboard Nov 11 09:56:03 shane /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> Nov 11 09:56:03 shane /kernel: ed0 not found at 0x320 Nov 11 09:56:03 shane /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Nov 11 09:56:03 shane /kernel: sio0: type 16550A Nov 11 09:56:03 shane /kernel: mci0 at 0x2f8-0x2ff irq 3 on isa Nov 11 09:56:03 shane /kernel: mci0: type 16550A Nov 11 09:56:03 shane /kernel: sio2 not found at 0x3e8 Nov 11 09:56:03 shane /kernel: sio3 not found at 0x2e8 Nov 11 09:56:03 shane /kernel: lpt0 at 0x378-0x37f irq 7 on isa Nov 11 09:56:03 shane /kernel: lpt0: Interrupt-driven port Nov 11 09:56:03 shane /kernel: lp0: TCP/IP capable interface Nov 11 09:56:03 shane /kernel: mse0 not found at 0x23c Nov 11 09:56:04 shane /kernel: wdog0 not found Nov 11 09:56:04 shane /kernel: weather0 not found Nov 11 09:56:04 shane /kernel: power0 not found Nov 11 09:56:04 shane /kernel: dled0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 09:56:04 shane /kernel: pled0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 09:56:04 shane /kernel: sysstat0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 09:56:04 shane /kernel: sercon0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 09:56:04 shane /kernel: smpte0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 09:56:04 shane /kernel: xilinx0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 09:56:04 shane /kernel: nvram0 not found Nov 11 09:56:04 shane /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Nov 11 09:56:05 shane /kernel: fdc0: NEC 765 Nov 11 09:56:05 shane /kernel: fd0: 1.44MB 3.5in Nov 11 09:56:05 shane /kernel: fd1: 1.2MB 5.25in Nov 11 09:56:05 shane /kernel: ep0 not found at 0x320 Nov 11 09:56:05 shane /kernel: npx0 on motherboard Nov 11 09:56:05 shane /kernel: npx0: INT 16 interface Nov 11 09:56:05 shane /kernel: changing root device to sd0a From owner-freebsd-hackers Mon Nov 11 10:10:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00179 for hackers-outgoing; Mon, 11 Nov 1996 10:10:09 -0800 (PST) Received: from mickey.umiacs.umd.edu (12222@mickey.umiacs.umd.edu [128.8.120.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA00173 for ; Mon, 11 Nov 1996 10:10:07 -0800 (PST) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.6/UMIACS-0.9/04-05-88) id NAA06383; Mon, 11 Nov 1996 13:10:03 -0500 (EST) Date: Mon, 11 Nov 1996 13:10:03 -0500 (EST) From: Sujal Patel To: Charles Henrich cc: hackers@freebsd.org Subject: Re: Xing Streamworks Player In-Reply-To: <199611111531.KAA07780@crh.cl.msu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Charles Henrich wrote: > > fd=9, typ=0xc50(P),num=0x12 > > > > But it does seem to work okay, any ideas on what that IOCTL is? > > #define SNDCTL_DSP_GETOPTR _IOR ('P',18, count_info) > > and now you know as much as I do. We can't fix this until the new sound driver is imported (what's the status John? :-). If no one objects, I'll just put a skeleton in and no-op it for now. Sujal From owner-freebsd-hackers Mon Nov 11 10:46:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA02243 for hackers-outgoing; Mon, 11 Nov 1996 10:46:26 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA02238; Mon, 11 Nov 1996 10:46:23 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id KAA20618; Mon, 11 Nov 1996 10:46:23 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id FAA15637; Tue, 12 Nov 1996 05:46:14 +1100 From: Julian Assange Message-Id: <199611111846.FAA15637@suburbia.net> Subject: Re: PPP/LCP sensing getty To: john@starfire.mn.org Date: Tue, 12 Nov 1996 05:46:13 +1100 (EST) Cc: hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG In-Reply-To: <199611111741.LAA15056@starfire.mn.org> from "john@starfire.mn.org" at Nov 11, 96 11:41:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The change is very small, only about 8 lines of code, and doesn't > change the size of the stripped executable. Should it be submitted > as a permanent inclusion in getty? If so, it should probably be Make the string to be executed an option. if it is specified ppp scanning is enabled. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Mon Nov 11 10:54:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA02580 for hackers-outgoing; Mon, 11 Nov 1996 10:54:43 -0800 (PST) Received: from ingenieria ([168.176.15.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA02575; Mon, 11 Nov 1996 10:54:40 -0800 (PST) Received: from unalslip.usc.unal.edu.co by ingenieria (SMI-8.6/SMI-SVR4) id NAA00900; Mon, 11 Nov 1996 13:54:48 +0600 Message-ID: <32879F01.14@fps.biblos.unal.edu.co> Date: Mon, 11 Nov 1996 13:47:45 -0800 From: "Pedro Giffuni S." Reply-To: m230761@ingenieria.ingsala.unal.edu.co Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: FreeBSD-fs@FreeBSD.org CC: hackers@FreeBSD.org Subject: Info on SYSV fs available: filesystem expert required Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello: Paul Monday just sent me a postscript file with the information of how he implemented an SCO filesystem for Linux. He is going to send me the tarball also. It doesn´t seem difficult, but someone that knows the inner workings of FreeBSD filesystems can do a really great job. Where should I put this information? Pedro. From owner-freebsd-hackers Mon Nov 11 11:05:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA03546 for hackers-outgoing; Mon, 11 Nov 1996 11:05:51 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA03515; Mon, 11 Nov 1996 11:05:40 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA19691; Mon, 11 Nov 1996 13:04:30 -0600 From: Joe Greco Message-Id: <199611111904.NAA19691@brasil.moneng.mei.com> Subject: Re: PPP/LCP sensing getty To: john@starfire.mn.org Date: Mon, 11 Nov 1996 13:04:29 -0600 (CST) Cc: hackers@freebsd.org, freebsd-isp@freebsd.org In-Reply-To: <199611111741.LAA15056@starfire.mn.org> from "john@starfire.mn.org" at Nov 11, 96 11:41:33 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I have created a version of getty that watches for the first four > bytes of the LCP leader and exec's pppd (-detach auth) if it sees > it. This allows dialup PPP access to FreeBSD boxes from other > FreeBSD boxes, Windows 3.1, Windows NT, Windows 95, and MAC's > without having to go through the pain of login scripting. I'd like > to make this generally available, but am not sure how best to do > so. Already been done. I did this six months ago... I haven't checked to see if anyone actually did anything with my patches though. ... JG From owner-freebsd-hackers Mon Nov 11 11:10:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA03858 for hackers-outgoing; Mon, 11 Nov 1996 11:10:24 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA03846 for ; Mon, 11 Nov 1996 11:10:19 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA19699; Mon, 11 Nov 1996 13:05:53 -0600 From: Joe Greco Message-Id: <199611111905.NAA19699@brasil.moneng.mei.com> Subject: Re: semaphores/shared memory To: terry@lambert.org (Terry Lambert) Date: Mon, 11 Nov 1996 13:05:53 -0600 (CST) Cc: scrappy@ki.net, twpierce@bio-3.bsd.uchicago.edu, hackers@FreeBSD.org In-Reply-To: <199611111717.KAA18289@phaeton.artisoft.com> from "Terry Lambert" at Nov 11, 96 10:17:19 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Okay, now bearing in mind that I'm looking at the examples as > > presented in "Unix Network Programming" by W. Richard Stevens...how > > do n clients signal back to the server that its finished with the data > > and can send up the next set of data? > > This is why I didn't suggest the same soloution. > > However, now I have to question my assumptions... why is it necessary > for the clients to signal the server? Reuse of the buffer area? It would be stupid for the server to start writing new data before everyone else is done with it. *shrug* ... JG From owner-freebsd-hackers Mon Nov 11 12:15:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07161 for hackers-outgoing; Mon, 11 Nov 1996 12:15:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA07156 for ; Mon, 11 Nov 1996 12:15:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA18571; Mon, 11 Nov 1996 13:03:02 -0700 From: Terry Lambert Message-Id: <199611112003.NAA18571@phaeton.artisoft.com> Subject: Re: semaphores/shared memory To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Mon, 11 Nov 1996 13:03:01 -0700 (MST) Cc: terry@lambert.org, scrappy@ki.net, twpierce@bio-3.bsd.uchicago.edu, hackers@FreeBSD.org In-Reply-To: <199611111905.NAA19699@brasil.moneng.mei.com> from "Joe Greco" at Nov 11, 96 01:05:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > However, now I have to question my assumptions... why is it necessary > > for the clients to signal the server? > > Reuse of the buffer area? > > It would be stupid for the server to start writing new data before > everyone else is done with it. If 99/100 of the clients succeed, we should hang the other 99 for the one that is lagging out? It would be useful to know if the data stream can be resynchronized, and what the actual effect of data loss for one client would be. Also, the effect would be negligible if you double-buffered the client buffer area. If the discrete buffer areas were large enough that the buffer could contain all the data sent in the maximum pool retention time window, then it would not be a problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 11 12:51:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08742 for hackers-outgoing; Mon, 11 Nov 1996 12:51:33 -0800 (PST) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA08735 for ; Mon, 11 Nov 1996 12:51:23 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id VAA00805 for ; Mon, 11 Nov 1996 21:50:48 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id VAA05741 for hackers@FreeBSD.ORG; Mon, 11 Nov 1996 21:49:56 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id VAA24549; Mon, 11 Nov 1996 21:42:35 +0100 (MET) Message-ID: Date: Mon, 11 Nov 1996 21:42:35 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: Setting PPP netmask! HOW! References: <199611111453.JAA01072@etinc.com> X-Mailer: Mutt 0.50.04 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2686 In-Reply-To: <199611111453.JAA01072@etinc.com>; from dennis on Nov 11, 1996 09:53:19 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to dennis: > market. I believe that the netmask is meaningless on a PTP interface, > so even if you get it to display the way you want you won't have > achieved much of anything. That's not true. Consider my case. We -- a group of friends -- have a C-class address (/24). We have cut in in 16 subnets (/28) and distributed the subnets between us. We connect thru PPP to a machine in one of these subnets. My ethernet at home has another subnet. We have an interconnection subnet for the Internet router. It would be impossible to send packets to my ethernet and to the Internet thru the PPP at the same time if subnets were not handled correctly by "pppd" (kernel PPP). ed0: flags=8843 mtu 1500 inet 193.56.58.65 netmask 0xfffffff0 broadcast 193.56.58.79 ether 00:00:c0:7c:66:48 pppd is run with this (line cut for display): $PROG $DEFOPTS connect 'chat -v ABORT "NO CARRIER" ABORT BUSY "" AT \ OK ATDTXXXXXXXX CONNECT "" ogin: XXXXXXX assword: \qXXXXXXXX' netmask \ 255.255.255.240 /dev/$DEVICE 115200 That way, I have a subnet route for my ethernet in /28... Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 2 688 lo0 193.56.58.64/28 link#1 UC 0 0 193.56.58.65 0:0:c0:7c:66:48 UHLW 0 958 lo0 ...and the default route will be added to another subnet when PPP is up. PPP correct handling of subnetting is *vital* for me. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996 From owner-freebsd-hackers Mon Nov 11 13:06:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA09965 for hackers-outgoing; Mon, 11 Nov 1996 13:06:51 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA09946 for ; Mon, 11 Nov 1996 13:06:45 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA21257; Mon, 11 Nov 1996 14:06:36 -0700 (MST) Date: Mon, 11 Nov 1996 14:06:36 -0700 (MST) Message-Id: <199611112106.OAA21257@rocky.mt.sri.com> From: Nate Williams To: roberto@keltia.freenix.fr (Ollivier Robert) Cc: hackers@freebsd.org Subject: Re: Setting PPP netmask! HOW! In-Reply-To: References: <199611111453.JAA01072@etinc.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert writes: > According to dennis: > > market. I believe that the netmask is meaningless on a PTP interface, > > so even if you get it to display the way you want you won't have > > achieved much of anything. > > That's not true. No, Dennis is correct. PPP (and all Point-Point links) use host routing, not subnet routing. You can use subnet routing over PTP links, but that's irrelevant of the netmask on the PPP link. > It would be impossible to send packets to my ethernet and to the Internet > thru the PPP at the same time if subnets were not handled correctly by > "pppd" (kernel PPP). Why? You simply setup the routing to send all traffic to each of the subnets to the PPP host which lives on that network. Nate From owner-freebsd-hackers Mon Nov 11 13:25:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10934 for hackers-outgoing; Mon, 11 Nov 1996 13:25:10 -0800 (PST) Received: from jennifer.pernet.net (jennifer.pernet.net [205.229.0.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA10889; Mon, 11 Nov 1996 13:24:51 -0800 (PST) Received: from localhost (neal@localhost) by jennifer.pernet.net (8.7.5/8.6.12) with SMTP id PAA04304; Mon, 11 Nov 1996 15:17:35 -0600 (CST) Date: Mon, 11 Nov 1996 15:17:35 -0600 (CST) From: Neal Rigney To: Joe Greco cc: john@starfire.mn.org, hackers@freebsd.org, freebsd-isp@freebsd.org Subject: Re: PPP/LCP sensing getty In-Reply-To: <199611111904.NAA19691@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Joe Greco wrote: > > I have created a version of getty that watches for the first four > > bytes of the LCP leader and exec's pppd (-detach auth) if it sees > > it. This allows dialup PPP access to FreeBSD boxes from other > > FreeBSD boxes, Windows 3.1, Windows NT, Windows 95, and MAC's > > without having to go through the pain of login scripting. I'd like > > to make this generally available, but am not sure how best to do > > so. > > Already been done. I did this six months ago... I haven't checked > to see if anyone actually did anything with my patches though. > > ... JG > I tried using the patches, but they have one small problem. My modems stupidly send a connect message in a way that getty sees as a username. So it sits at Password: waiting for test, but only getting LCP. The other times I got it to work(with different modems), it worked like a charm. -- Neal Rigney, PERnet Communications, (409)729-4638 neal@mail.pernet.net From owner-freebsd-hackers Mon Nov 11 13:40:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11936 for hackers-outgoing; Mon, 11 Nov 1996 13:40:45 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA11921; Mon, 11 Nov 1996 13:40:37 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id WAA02531; Mon, 11 Nov 1996 22:15:33 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.2/8.8.2) with ESMTP id VAA02283; Mon, 11 Nov 1996 21:30:15 +0100 (MET) Date: Mon, 11 Nov 1996 21:30:14 +0100 (MET) From: Andreas Klemm To: "Pedro Giffuni S." cc: FreeBSD-fs@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Info on SYSV fs available: filesystem expert required In-Reply-To: <32879F01.14@fps.biblos.unal.edu.co> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Pedro Giffuni S. wrote: > Hello: > Paul Monday just sent me a postscript file with the information of how > he implemented an SCO filesystem for Linux. He is going to send me the > tarball also. > It doesn´t seem difficult, but someone that knows the inner workings of > FreeBSD filesystems can do a really great job. > Where should I put this information? What about a place in /usr/share/doc ... ? Especially for technical manuals, reports ?! andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Mon Nov 11 13:41:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11995 for hackers-outgoing; Mon, 11 Nov 1996 13:41:07 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA11974 for ; Mon, 11 Nov 1996 13:40:58 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id WAA02523; Mon, 11 Nov 1996 22:15:28 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.2/8.8.2) with SMTP id WAA00239; Mon, 11 Nov 1996 22:16:11 +0100 (MET) Date: Mon, 11 Nov 1996 22:16:10 +0100 (MET) From: Andreas Klemm To: "Justin T. Gibbs" cc: "Alexsandro D. F. Correia" , hackers@FreeBSD.org Subject: Re: Problems restoring Backups !!! In-Reply-To: <199611101804.KAA21991@freefall.freebsd.org> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Your problem report had the information I needed to understand and fix your > problem. I changed the QUEUE FULL condition code to not do an > unconditional retry a little while ago, and you must be running out of > retries. You should be able to get this kind of thing to happen in other > scenarios besides dumping. I'll fix this today. With your latest patches - that I got via cvsup 2 hours ago - (3.0-current kernel) and using the options options AHC_SCBPAGING_ENABLE options AHC_TAGENABLE # still makes problems with tapes options SCSI_REPORT_GEOMETRY I get now thousands of (looping) Queue Full lines, when trying to make a backup using dump(8). -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Mon Nov 11 13:52:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12847 for hackers-outgoing; Mon, 11 Nov 1996 13:52:32 -0800 (PST) Received: from whale.gu.kiev.ua ([194.93.190.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA12817; Mon, 11 Nov 1996 13:52:07 -0800 (PST) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [194.93.190.3]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id XAA30300; Mon, 11 Nov 1996 23:48:37 +0200 Date: Mon, 11 Nov 1996 23:48:37 +0200 (EET) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: Joe Greco cc: john@starfire.mn.org, hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Subject: Re: PPP/LCP sensing getty In-Reply-To: <199611111904.NAA19691@brasil.moneng.mei.com> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dear Joe, wouldn't you mind reminding the URL for your patches, please? (It's a pity that this nice functionality seems to be missed from baseline srcs yet, but I'd like to try it out myself, and Thanks for it!) [...] > Already been done. I did this six months ago... I haven't checked > to see if anyone actually did anything with my patches though. > > ... JG > -- Best, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Mon Nov 11 14:05:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13804 for hackers-outgoing; Mon, 11 Nov 1996 14:05:25 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA13771 for ; Mon, 11 Nov 1996 14:05:10 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-46.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA17770 (5.67b/IDA-1.5 for ); Mon, 11 Nov 1996 23:04:34 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id XAA02428; Mon, 11 Nov 1996 23:04:38 +0100 (MET) Message-Id: <199611112204.XAA02428@x14.mi.uni-koeln.de> Date: Mon, 11 Nov 1996 23:04:38 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: durian@plutotech.com (Mike Durian) Cc: se@zpr.uni-koeln.de (Stefan Esser), freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-Reply-To: <199611111735.KAA28562@pluto.plutotech.com>; from Mike Durian on Nov 11, 1996 10:35:29 -0700 References: <199611111735.KAA28562@pluto.plutotech.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Durian writes: > On Mon, 11 Nov 1996 00:10:20 +0100, se@zpr.uni-koeln.de (Stefan Esser) wrote: > > >Well, I can only agree to half of that sentence: The mapping type is > >found in the address, but also in the size. The low bits of the map > >registers are hardwired. For that reason, (data & 7) is guaranteed > >to be identical to (map & 7) ... > > I'm not seeing this. I'm enclosing some output from a boot on my > machine (not the one will all the PCI busses). I've added printfs > to show the value of map, data and the addr, size parameters in each > of the two cases. As you can see (as in the ahc device), there are > cases where the lower nybble differs in the map and data variables. > You can also see where a memory region gets treated as an io region. > I'm still not sure about the strange 0x500a1011 io address found on > the DEC ethernet cards. Well, the PCI probe in your boot message logs looks different from everything I've seen before :-) Please boot the same kernel (with your debug printf()s) again, but this time with the "-v" option at the "Boot: " prompt. This will enable even more messages about the PCI maps, and I hope to understand from them what's going on ... For now I'm very surprised about the behaviour of those DEC LAN chips ... Thanks in advance, STefan From owner-freebsd-hackers Mon Nov 11 14:15:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14694 for hackers-outgoing; Mon, 11 Nov 1996 14:15:55 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA14682 for ; Mon, 11 Nov 1996 14:15:47 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA19941; Mon, 11 Nov 1996 16:12:15 -0600 From: Joe Greco Message-Id: <199611112212.QAA19941@brasil.moneng.mei.com> Subject: Re: semaphores/shared memory To: terry@lambert.org (Terry Lambert) Date: Mon, 11 Nov 1996 16:12:14 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, scrappy@ki.net, twpierce@bio-3.bsd.uchicago.edu, hackers@FreeBSD.org In-Reply-To: <199611112003.NAA18571@phaeton.artisoft.com> from "Terry Lambert" at Nov 11, 96 01:03:01 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > However, now I have to question my assumptions... why is it necessary > > > for the clients to signal the server? > > > > Reuse of the buffer area? > > > > It would be stupid for the server to start writing new data before > > everyone else is done with it. > > If 99/100 of the clients succeed, we should hang the other 99 for the > one that is lagging out? I guess that depends on the application. :-) I was not going to try to dictate to someone else how to write a UNIX multi process application, he already has the Stevens book. > It would be useful to know if the data stream can be resynchronized, > and what the actual effect of data loss for one client would be. > > Also, the effect would be negligible if you double-buffered the > client buffer area. If the discrete buffer areas were large enough > that the buffer could contain all the data sent in the maximum pool > retention time window, then it would not be a problem. Sure.. and sure again. The question did not indicate that the data was not already being double (or multi) buffered. You would still need to signal completion and acknowledgement on a per-buffer basis... same question, basically. :-) OTOH, a description of the problem being solved may not be a bad idea. It will then let us make valid guesses as to how the process might be improved... ;-) ... JG From owner-freebsd-hackers Mon Nov 11 14:18:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14924 for hackers-outgoing; Mon, 11 Nov 1996 14:18:55 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA14880; Mon, 11 Nov 1996 14:18:34 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA19966; Mon, 11 Nov 1996 16:16:24 -0600 From: Joe Greco Message-Id: <199611112216.QAA19966@brasil.moneng.mei.com> Subject: Re: PPP/LCP sensing getty To: neal@pernet.net (Neal Rigney) Date: Mon, 11 Nov 1996 16:16:24 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, john@starfire.mn.org, hackers@freebsd.org, freebsd-isp@freebsd.org In-Reply-To: from "Neal Rigney" at Nov 11, 96 03:17:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I tried using the patches, but they have one small problem. My modems > stupidly send a connect message in a way that getty sees as a username. > So it sits at Password: waiting for test, but only getting LCP. The other > times I got it to work(with different modems), it worked like a charm. Turn off result codes. ATZ ATQ1&W Also set the modem to do a reset on DTR transition. Then if you need to dial out, you can use "ATQ0" in your dial string to force the modem to provide result codes for the dialer program. No modem I have ever seen works out of the box correctly with a UNIX host for both in- and outdial applications. ... JG From owner-freebsd-hackers Mon Nov 11 14:21:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15228 for hackers-outgoing; Mon, 11 Nov 1996 14:21:32 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA15167; Mon, 11 Nov 1996 14:21:11 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA19987; Mon, 11 Nov 1996 16:19:21 -0600 From: Joe Greco Message-Id: <199611112219.QAA19987@brasil.moneng.mei.com> Subject: Re: PPP/LCP sensing getty To: stesin@gu.net (Andrew Stesin) Date: Mon, 11 Nov 1996 16:19:21 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, john@starfire.mn.org, hackers@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG In-Reply-To: from "Andrew Stesin" at Nov 11, 96 11:48:37 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Dear Joe, > > wouldn't you mind reminding the URL for your patches, please? > > (It's a pity that this nice functionality seems to be missed > from baseline srcs yet, but I'd like to try it out myself, > and Thanks for it!) > > [...] ftp://ftp.freebsd.sol.net/pub/FreeBSD/alpha/pppgetty.tar.gz for executables for 2.1.0R. ftp://ftp.freebsd.sol.net/incoming/pppgetty.tar.gz for source mods, this you will have to figure out yourself (shouldn't be too hard). Look on the list archive for references to it... if you have problems I can dig up some useful dirt. ... JG From owner-freebsd-hackers Mon Nov 11 14:22:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15273 for hackers-outgoing; Mon, 11 Nov 1996 14:22:02 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA15244 for ; Mon, 11 Nov 1996 14:21:38 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA03658; Tue, 12 Nov 1996 09:19:56 +1100 (EST) Date: Tue, 12 Nov 1996 09:19:55 +1100 (EST) From: "Daniel O'Callaghan" To: Ollivier Robert cc: hackers@FreeBSD.org Subject: Re: Setting PPP netmask! HOW! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Ollivier Robert wrote: > According to dennis: > > market. I believe that the netmask is meaningless on a PTP interface, > > so even if you get it to display the way you want you won't have > > achieved much of anything. > > That's not true. > > Consider my case. We -- a group of friends -- have a C-class address > (/24). We have cut in in 16 subnets (/28) and distributed the subnets > between us. We connect thru PPP to a machine in one of these subnets. My > ethernet at home has another subnet. We have an interconnection subnet for > the Internet router. Olivier, what you say is true, however you are using the netmask to define the netmask of the *remote* end of the ppp link, not the local end. In James' case, he is running in 'numberless' mode, and he is seeking to define a netmask for his local end. That does not make sense, and is totally unnecessary, as Denis says. Simply put, the difference is that you are running a ppp link within a single IP network (happens to be class C), while James is running a ppp link between two distinct IP networks. You: 193.56.58.20 --> 193.56.58.234 James: 203.16.20.1 --> 203.8.105.20 regards, Danny From owner-freebsd-hackers Mon Nov 11 14:22:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15279 for hackers-outgoing; Mon, 11 Nov 1996 14:22:05 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA15257 for ; Mon, 11 Nov 1996 14:21:49 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id RAA03756; Mon, 11 Nov 1996 17:26:36 -0500 Date: Mon, 11 Nov 1996 17:26:36 -0500 Message-Id: <199611112226.RAA03756@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: roberto@keltia.freenix.fr (Ollivier Robert) From: dennis@etinc.com (dennis) Subject: Re: Setting PPP netmask! HOW! Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >According to dennis: >> market. I believe that the netmask is meaningless on a PTP interface, >> so even if you get it to display the way you want you won't have >> achieved much of anything. > >That's not true. > >Consider my case. We -- a group of friends -- have a C-class address >(/24). We have cut in in 16 subnets (/28) and distributed the subnets >between us. We connect thru PPP to a machine in one of these subnets. My >ethernet at home has another subnet. We have an interconnection subnet for >the Internet router. > >It would be impossible to send packets to my ethernet and to the Internet >thru the PPP at the same time if subnets were not handled correctly by >"pppd" (kernel PPP). > >ed0: flags=8843 mtu 1500 > inet 193.56.58.65 netmask 0xfffffff0 broadcast 193.56.58.79 > ether 00:00:c0:7c:66:48 > >pppd is run with this (line cut for display): > >$PROG $DEFOPTS connect 'chat -v ABORT "NO CARRIER" ABORT BUSY "" AT \ >OK ATDTXXXXXXXX CONNECT "" ogin: XXXXXXX assword: \qXXXXXXXX' netmask \ >255.255.255.240 /dev/$DEVICE 115200 > >That way, I have a subnet route for my ethernet in /28... > >Routing tables > >Internet: >Destination Gateway Flags Refs Use Netif Expire >127.0.0.1 127.0.0.1 UH 2 688 lo0 >193.56.58.64/28 link#1 UC 0 0 >193.56.58.65 0:0:c0:7c:66:48 UHLW 0 958 lo0 > >...and the default route will be added to another subnet when PPP is up. > >PPP correct handling of subnetting is *vital* for me. Its not quite working the way you think (the PPP routes are "hosts" and the subnet is irrelevant), but it you're happy........what the heck! Dennis From owner-freebsd-hackers Mon Nov 11 14:35:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16337 for hackers-outgoing; Mon, 11 Nov 1996 14:35:41 -0800 (PST) Received: from jennifer.pernet.net (jennifer.pernet.net [205.229.0.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA16313; Mon, 11 Nov 1996 14:35:19 -0800 (PST) Received: from localhost (neal@localhost) by jennifer.pernet.net (8.7.5/8.6.12) with SMTP id QAA06614; Mon, 11 Nov 1996 16:27:38 -0600 (CST) Date: Mon, 11 Nov 1996 16:27:38 -0600 (CST) From: Neal Rigney To: Joe Greco cc: john@starfire.mn.org, hackers@freebsd.org, freebsd-isp@freebsd.org Subject: Re: PPP/LCP sensing getty In-Reply-To: <199611112216.QAA19966@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Joe Greco wrote: > Turn off result codes. > > ATZ > ATQ1&W Doh! When I tried putting in the new getty, I racked my brain for how to do this. I looked in the docs for the modems, but of course they read like stereo instructions :). > Also set the modem to do a reset on DTR transition. Then if you need to Already got this going. Thanks. -- Neal Rigney, PERnet Communications, (409)729-4638 neal@mail.pernet.net From owner-freebsd-hackers Mon Nov 11 14:45:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17157 for hackers-outgoing; Mon, 11 Nov 1996 14:45:04 -0800 (PST) Received: from pluto.plutotech.com (root@pluto.plutotech.com [206.168.67.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA17143 for ; Mon, 11 Nov 1996 14:44:52 -0800 (PST) Received: from shane.plutotech.com (durian@shane.plutotech.com [206.168.67.149]) by pluto.plutotech.com (8.8.2/8.8.2) with ESMTP id PAA04235; Mon, 11 Nov 1996 15:41:11 -0700 (MST) Message-Id: <199611112241.PAA04235@pluto.plutotech.com> From: "Mike Durian" To: se@zpr.uni-koeln.de (Stefan Esser) cc: freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-reply-to: Your message of "Mon, 11 Nov 1996 23:04:38 +0100." Date: Mon, 11 Nov 1996 15:41:11 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996 23:04:38 +0100, se@zpr.uni-koeln.de (Stefan Esser) wrote: > >Well, the PCI probe in your boot message logs looks different >from everything I've seen before :-) We've certainly made some inhouse changes, but not much to the generic pci code. You can ignore all those strange ISA devices at the end. They're for some of our custom devices, and aren't even found on this machine (despite some of the false positives). This output is from /var/log/messages, not dmesg(8). >Please boot the same kernel (with your debug printf()s) again, >but this time with the "-v" option at the "Boot: " prompt. Here you go. It looks like the mistaken i/o maps are from expansion ROM maps. I still don't know about the DEC thing. mike Nov 11 15:28:12 shane /kernel: FreeBSD 2.1.5-RELEASE #43: Mon Nov 11 15:26:34 MST 1996 Nov 11 15:28:12 shane /kernel: durian@shane.plutotech.com:/usr/src/sys-head/compile/AVIO Nov 11 15:28:13 shane /kernel: CPU: 132-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) Nov 11 15:28:13 shane /kernel: Origin = "GenuineIntel" Id = 0x52b Stepping=11 Nov 11 15:28:13 shane /kernel: Features=0x1bf Nov 11 15:28:14 shane /kernel: dedicated mem= 2097152 (2048K) from 31457280 (30720K) to 33554432 (32768K) Nov 11 15:28:14 shane /kernel: reg_physmem i=0 base=1e00000(31457280.) len=2097152. Nov 11 15:28:14 shane /kernel: real memory = 31457280 (30720K bytes) Nov 11 15:28:14 shane /kernel: avail memory = 28545024 (27876K bytes) Nov 11 15:28:15 shane /kernel: pcibus_setup(1): mode1res=0x80000000 (0x80000000), mode2res=0xff (0x0e) Nov 11 15:28:15 shane /kernel: pcibus_setup(2): mode1res=0x80000000 (0x80000000) Nov 11 15:28:15 shane /kernel: pcibus_check: device 0 is there (id=122d8086) Nov 11 15:28:15 shane /kernel: Probing for devices on PCI bus 0: Nov 11 15:28:15 shane /kernel: configuration mode 1 allows 32 devices. Nov 11 15:28:15 shane /kernel: ahc0 rev 0 int a irq 11 on pci0:20 Nov 11 15:28:15 shane /kernel: vendor = 0x9004, device = 0x8178 Nov 11 15:28:16 shane /kernel: map = 0xfc01, data = 0xffffff01 Nov 11 15:28:16 shane /kernel: case 1,5: i/o addr = 0xfc00, size = 0x100 Nov 11 15:28:16 shane /kernel: mapreg[10] type=1 addr=0000fc00 size=0100. Nov 11 15:28:16 shane /kernel: map = 0xffbdf000, data = 0xfffff000 Nov 11 15:28:16 shane /kernel: case 0,2,4: i/o addr = 0xffbdf000, size = 0x1000 Nov 11 15:28:17 shane /kernel: mapreg[14] type=0 addr=ffbdf000 size=1000. Nov 11 15:28:17 shane /kernel: map = 0xffbc0000, data = 0xffff0001 Nov 11 15:28:17 shane /kernel: case 1,5: i/o addr = 0xffbc0000, size = 0x10000 Nov 11 15:28:17 shane /kernel: mapreg[30] type=0 addr=ffbc0000 size=10000. Nov 11 15:28:17 shane /kernel: reg16: ioaddr=0xfc00 size=0x100 Nov 11 15:28:17 shane /kernel: reg48: virtual=0xf4951000 physical=0xffbc0000 size=0x10000 Nov 11 15:28:18 shane /kernel: rom_reg=ffbc0001 Nov 11 15:28:18 shane /kernel: command_status_reg=02800117 Nov 11 15:28:18 shane /kernel: ahc0 va=f4951000 pa=ffbc0000 Nov 11 15:28:18 shane /kernel: ahc0: Reading SEEPROM...done. Nov 11 15:28:18 shane /kernel: ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Nov 11 15:28:19 shane /kernel: ahc0: Reseting Channel A Nov 11 15:28:19 shane /kernel: ahc0: Downloading Sequencer Program...Done Nov 11 15:28:19 shane /kernel: ahc0: Probing channel A Nov 11 15:28:19 shane /kernel: ahc0 waiting for scsi devices to settle Nov 11 15:28:19 shane /kernel: ahc0: target 0 using 16Bit transfers Nov 11 15:28:20 shane /kernel: ahc0: target 0 synchronous at 10.0MHz, offset = 0x8 Nov 11 15:28:20 shane /kernel: (ahc0:0:0): "SEAGATE ST31230W 0640" type 0 fixed SCSI 2 Nov 11 15:28:20 shane /kernel: sd0(ahc0:0:0): Direct-Access 1010MB (2069860 512 byte sectors) Nov 11 15:28:20 shane /kernel: sd0(ahc0:0:0): with 3992 cyls, 5 heads, and an average 103 sectors/track Nov 11 15:28:20 shane /kernel: ahc0:A:2: refuses WIDE negotiation. Using 8bit transfers Nov 11 15:28:20 shane /kernel: ahc0: target 2 synchronous at 4.4MHz, offset = 0xf Nov 11 15:28:20 shane /kernel: (ahc0:2:0): "TOSHIBA CD-ROM XM-3701TA 3205" type 5 removable SCSI 2 Nov 11 15:28:20 shane /kernel: cd0(ahc0:2:0): CD-ROM Nov 11 15:28:20 shane /kernel: cd0(ahc0:2:0): NOT READY asc:4,1 Nov 11 15:28:20 shane /kernel: cd0(ahc0:2:0): Logical unit is in process of becoming ready Nov 11 15:28:21 shane /kernel: can't get the size Nov 11 15:28:21 shane /kernel: Nov 11 15:28:21 shane /kernel: ahc0:A:6: refuses WIDE negotiation. Using 8bit transfers Nov 11 15:28:21 shane /kernel: ahc0:A:6: refuses syncronous negotiation. Using asyncronous transfers Nov 11 15:28:21 shane /kernel: (ahc0:6:0): "HP C4324/C4325 1.27" type 5 removable SCSI 2 Nov 11 15:28:21 shane /kernel: worm0(ahc0:6:0): Write-Once - UNTESTED Nov 11 15:28:21 shane /kernel: worm0(ahc0:6:0): NOT READY asc:4,0 Nov 11 15:28:21 shane /kernel: worm0(ahc0:6:0): Logical unit not ready, cause not reportable Nov 11 15:28:21 shane /kernel: Nov 11 15:28:21 shane /kernel: worm0(ahc0:6:0): could not get size Nov 11 15:28:22 shane /kernel: - can't get capacity. Nov 11 15:28:22 shane /kernel: vga0 rev 3 on pci0:19 Nov 11 15:28:22 shane /kernel: vendor = 0x1002, device = 0x4758 Nov 11 15:28:22 shane /kernel: map = 0xfe000000, data = 0xff000000 Nov 11 15:28:22 shane /kernel: case 0,2,4: i/o addr = 0xfe000000, size = 0x1000000 Nov 11 15:28:22 shane /kernel: mapreg[10] type=0 addr=fe000000 size=1000000. Nov 11 15:28:22 shane /kernel: map = 0xffbe0000, data = 0xffff0001 Nov 11 15:28:22 shane /kernel: case 1,5: i/o addr = 0xffbe0000, size = 0x10000 Nov 11 15:28:22 shane /kernel: mapreg[30] type=0 addr=ffbe0000 size=10000. Nov 11 15:28:22 shane /kernel: de0 rev 32 int a irq 15 on pci0:17 Nov 11 15:28:23 shane /kernel: vendor = 0x1011, device = 0x0009 Nov 11 15:28:23 shane /kernel: map = 0xf881, data = 0xffffff81 Nov 11 15:28:23 shane /kernel: case 1,5: i/o addr = 0xf880, size = 0x80 Nov 11 15:28:23 shane /kernel: mapreg[10] type=1 addr=0000f880 size=0080. Nov 11 15:28:23 shane /kernel: map = 0xffbdef80, data = 0xffffff80 Nov 11 15:28:23 shane /kernel: case 0,2,4: i/o addr = 0xffbdef80, size = 0x80 Nov 11 15:28:23 shane /kernel: mapreg[14] type=0 addr=ffbdef80 size=0080. Nov 11 15:28:23 shane /kernel: map = 0x500a1011, data = 0x500a1011 Nov 11 15:28:23 shane /kernel: case 1,5: i/o addr = 0x500a1010, size = 0x10 Nov 11 15:28:23 shane /kernel: mapreg[2c] type=1 addr=500a1010 size=0010. Nov 11 15:28:24 shane /kernel: map = 0xffb40000, data = 0xfffc0001 Nov 11 15:28:24 shane /kernel: case 1,5: i/o addr = 0xffb40000, size = 0x40000 Nov 11 15:28:24 shane /kernel: mapreg[30] type=0 addr=ffb40000 size=40000. Nov 11 15:28:24 shane /kernel: reg16: ioaddr=0xf880 size=0x80 Nov 11 15:28:24 shane /kernel: de0: DE500-AA DC21140A [10-100Mb/s] pass 2.0 Nov 11 15:28:24 shane /kernel: de0: address 00:00:f8:02:c5:5f Nov 11 15:28:24 shane /kernel: de0(phy5): model = NS DP83840 (supports media autonegotiation) Nov 11 15:28:24 shane /kernel: de0(phy5): media = 10baseT, Full Duplex 10baseT, 100baseTX, Full Duplex 100baseTX Nov 11 15:28:24 shane /kernel: de0(phy5): autonegotiation restarted: 0x3300 Nov 11 15:28:24 shane /kernel: bpf: de0 attached Nov 11 15:28:24 shane /kernel: chip0 rev 2 on pci0:7:0 Nov 11 15:28:25 shane /kernel: vendor = 0x8086, device = 0x122e Nov 11 15:28:25 shane /kernel: I/O Recovery Timing: 8-bit 8 clocks, 16-bit 4 clocks Nov 11 15:28:25 shane /kernel: Extended BIOS: disabled Nov 11 15:28:25 shane /kernel: Lower BIOS: disabled Nov 11 15:28:25 shane /kernel: Coprocessor IRQ13: enabled Nov 11 15:28:25 shane /kernel: Mouse IRQ12: disabled Nov 11 15:28:25 shane /kernel: Interrupt Routing: A: IRQ11, B: disabled, C: disabled, D: IRQ15 Nov 11 15:28:25 shane /kernel: MB0: disabled, MB1: disabled Nov 11 15:28:25 shane /kernel: chip1 rev 2 on pci0:7:1 Nov 11 15:28:25 shane /kernel: vendor = 0x8086, device = 0x1230 Nov 11 15:28:25 shane /kernel: map = 0xfff1, data = 0xfff1 Nov 11 15:28:25 shane /kernel: case 1,5: i/o addr = 0xfff0, size = 0x10 Nov 11 15:28:26 shane /kernel: mapreg[20] type=1 addr=0000fff0 size=0010. Nov 11 15:28:26 shane /kernel: I/O Base Address: %#lx Nov 11 15:28:26 shane /kernel: Primary IDE: disabled Nov 11 15:28:26 shane /kernel: Secondary IDE: disabled Nov 11 15:28:26 shane /kernel: chip2 rev 2 on pci0:0 Nov 11 15:28:26 shane /kernel: vendor = 0x8086, device = 0x122d Nov 11 15:28:26 shane /kernel: CPU Inactivity timer: clocks Nov 11 15:28:26 shane /kernel: Peer Concurrency: enabled Nov 11 15:28:26 shane /kernel: CPU-to-PCI Write Bursting: enabled Nov 11 15:28:26 shane /kernel: PCI Streaming: enabled Nov 11 15:28:26 shane /kernel: Bus Concurrency: enabled Nov 11 15:28:27 shane /kernel: Cache: 256K pipelined-burst secondary; L1 enabled Nov 11 15:28:27 shane /kernel: DRAM: no memory hole, 66 MHz refresh Nov 11 15:28:27 shane /kernel: Read burst timing: x-3-3-3/x-4-4-4 Nov 11 15:28:27 shane /kernel: Write burst timing: x-3-3-3 Nov 11 15:28:27 shane /kernel: RAS-CAS delay: 3 clocks Nov 11 15:28:27 shane /kernel: pci0: uses 16781440 bytes of memory from fe000000 upto ffbdffff. Nov 11 15:28:27 shane /kernel: pci0: uses 416 bytes of I/O space from f880 upto ffff. Nov 11 15:28:27 shane /kernel: Probing for devices on the ISA bus: Nov 11 15:28:27 shane /kernel: sc0 at 0x60-0x6f irq 1 on motherboard Nov 11 15:28:27 shane /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> Nov 11 15:28:27 shane /kernel: ed0 not found at 0x320 Nov 11 15:28:28 shane /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Nov 11 15:28:28 shane /kernel: sio0: type 16550A Nov 11 15:28:28 shane /kernel: mci0 at 0x2f8-0x2ff irq 3 on isa Nov 11 15:28:28 shane /kernel: mci0: type 16550A Nov 11 15:28:28 shane /kernel: sio2 not found at 0x3e8 Nov 11 15:28:28 shane /kernel: sio3 not found at 0x2e8 Nov 11 15:28:28 shane /kernel: lpt0 at 0x378-0x37f irq 7 on isa Nov 11 15:28:28 shane /kernel: lpt0: Interrupt-driven port Nov 11 15:28:28 shane /kernel: lp0: TCP/IP capable interface Nov 11 15:28:28 shane /kernel: bpf: lp0 attached Nov 11 15:28:28 shane /kernel: mse0: wrong signature ff Nov 11 15:28:28 shane /kernel: mse0 not found at 0x23c Nov 11 15:28:29 shane /kernel: wdog0 not found Nov 11 15:28:29 shane /kernel: wrote 0x1 to 0xf00dfff6 Nov 11 15:28:29 shane /kernel: wrote 0x80 to 0xf00dfff7 Nov 11 15:28:29 shane /kernel: 0xf00dfff1 = 0xff Nov 11 15:28:29 shane /kernel: 0xf00dfff1 = 0xff Nov 11 15:28:29 shane /kernel: S_TBUSY never went low Nov 11 15:28:29 shane /kernel: weather0 not found Nov 11 15:28:29 shane /kernel: power0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 15:28:29 shane /kernel: dled0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 15:28:29 shane /kernel: pled0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 15:28:30 shane /kernel: sysstat0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 15:28:30 shane /kernel: sercon0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 15:28:30 shane /kernel: smpte0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 15:28:30 shane /kernel: xilinx0 at 0x0 maddr 0xdfff0 msize 16 on isa Nov 11 15:28:30 shane /kernel: nvram0 not found Nov 11 15:28:30 shane /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Nov 11 15:28:30 shane /kernel: fdc0: NEC 765 Nov 11 15:28:30 shane /kernel: fd0: 1.44MB 3.5in Nov 11 15:28:30 shane /kernel: fd1: 1.2MB 5.25in Nov 11 15:28:30 shane /kernel: ep0 not found at 0x320 Nov 11 15:28:30 shane /kernel: npx0 on motherboard Nov 11 15:28:30 shane /kernel: npx0: INT 16 interface Nov 11 15:28:31 shane /kernel: Device configuration finished. Nov 11 15:28:31 shane /kernel: Considering FFS root f/s. Nov 11 15:28:31 shane /kernel: changing root device to sd0a Nov 11 15:28:31 shane /kernel: Configuring root and swap devs. Nov 11 15:28:31 shane /kernel: configure() finished. Nov 11 15:28:31 shane /kernel: BIOS Geometries: Nov 11 15:28:31 shane /kernel: 0:03f13f20 0..1009=1010 cylinders, 0..63=64 heads, 1..32=32 sectors Nov 11 15:28:32 shane /kernel: 0 accounted for Nov 11 15:28:32 shane /kernel: bpf: lo0 attached Nov 11 15:28:32 shane /kernel: bpf: sl0 attached Nov 11 15:28:32 shane /kernel: bpf: tun0 attached From owner-freebsd-hackers Mon Nov 11 15:03:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA17962 for hackers-outgoing; Mon, 11 Nov 1996 15:03:08 -0800 (PST) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA17953 for ; Mon, 11 Nov 1996 15:02:57 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id AAA01029 for ; Tue, 12 Nov 1996 00:01:52 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id AAA07235 for hackers@FreeBSD.org; Tue, 12 Nov 1996 00:01:45 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id XAA25522; Mon, 11 Nov 1996 23:40:37 +0100 (MET) Message-ID: Date: Mon, 11 Nov 1996 23:40:37 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@FreeBSD.org Subject: Re: Setting PPP netmask! HOW! References: X-Mailer: Mutt 0.50.05 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2686 In-Reply-To: ; from Daniel O'Callaghan on Nov 12, 1996 09:19:55 +1100 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Daniel O'Callaghan: > and is totally unnecessary, as Denis says. Simply put, the difference is > that you are running a ppp link within a single IP network (happens to be > class C), while James is running a ppp link between two distinct IP networks. > You: 193.56.58.20 --> 193.56.58.234 > James: 203.16.20.1 --> 203.8.105.20 I got the difference, thanks. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996 From owner-freebsd-hackers Mon Nov 11 15:03:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA17986 for hackers-outgoing; Mon, 11 Nov 1996 15:03:16 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA17972; Mon, 11 Nov 1996 15:03:10 -0800 (PST) Message-Id: <199611112303.PAA17972@freefall.freebsd.org> To: Andreas Klemm cc: "Alexsandro D. F. Correia" , hackers@FreeBSD.org Subject: Re: Problems restoring Backups !!! In-reply-to: Your message of "Mon, 11 Nov 1996 22:16:10 +0100." Date: Mon, 11 Nov 1996 15:03:09 -0800 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >options AHC_SCBPAGING_ENABLE >options AHC_TAGENABLE # still makes problems with tap >es >options SCSI_REPORT_GEOMETRY > >I get now thousands of (looping) Queue Full lines, when trying to make >a backup using dump(8). Remove the printf and see if it works okay for you. The printf probably causes a cascade effect since it will cause syslogd to write to the disk. I'll also look into changing the code to try to actively reduce the number of transactions allowed to the target, but to do that correctly is a lot of work - which is the main reason I added it to the generic SCSI layer on the SCSI branch. >-- >andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik Gmb >H > Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.d >e >pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by << >< >ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD << >< > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Nov 11 15:28:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA19913 for hackers-outgoing; Mon, 11 Nov 1996 15:28:36 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA19887; Mon, 11 Nov 1996 15:28:14 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA18862; Mon, 11 Nov 1996 16:15:39 -0700 From: Terry Lambert Message-Id: <199611112315.QAA18862@phaeton.artisoft.com> Subject: Re: PPP/LCP sensing getty To: neal@pernet.net (Neal Rigney) Date: Mon, 11 Nov 1996 16:15:39 -0700 (MST) Cc: jgreco@brasil.moneng.mei.com, john@starfire.mn.org, hackers@freebsd.org, freebsd-isp@freebsd.org In-Reply-To: from "Neal Rigney" at Nov 11, 96 03:17:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > My modems > stupidly send a connect message in a way that getty sees as a username. > So it sits at Password: waiting for test, but only getting LCP. The other > times I got it to work(with different modems), it worked like a charm. Are you sure they are sending the message after raising DCD? It's been standard for years to send the connect messages *before* raising DCD. What might be happening is one of: o DCD is not set to follow remote carrier (modem problem) o DCD is not really DCD (cable problem) o You are using non-modem-control port for mode (/dev problem) o You are using a serial card that does not flush input buffer contents on off-to-on DCD transition on modem control ports (device driver problem) o Your modem is truly, honestly *bogus* (modem problem) I've never seen a truly bogus modem that supported the AT command set (the AT&T 4024 and the Tandy DC-15 are non-AT command set bogus modems; and the AT&T cn be firmware upgraded). You might also consider that, unless you are running the bogus uugetty (which should open with a flag to hang the open pending a "ring indicate" signal, and timeout on no DCD raid within XXX seconds of a ring indicate), response codes from the modem should be turned off anyway. They are only really useful for dialout progress reporting (before you tell me that you need them to recognize baud on a uugetty, let me point you to the RS232C and Bell 103C standards on external clocks). In any case, a uugetty or mgetty or whatever should flush input buffers before putting up a login, and should delay 1 second to ensure input buffer flush occurs, in any case, before outputting a prompt, in case the modem ignores RTS from the computer prior to raising its own DCD --- the "bogus modem" case, above). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 11 15:30:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20077 for hackers-outgoing; Mon, 11 Nov 1996 15:30:30 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA20051; Mon, 11 Nov 1996 15:30:19 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA18871; Mon, 11 Nov 1996 16:18:05 -0700 From: Terry Lambert Message-Id: <199611112318.QAA18871@phaeton.artisoft.com> Subject: Re: PPP/LCP sensing getty To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Mon, 11 Nov 1996 16:18:05 -0700 (MST) Cc: neal@pernet.net, jgreco@brasil.moneng.mei.com, john@starfire.mn.org, hackers@FreeBSD.org, freebsd-isp@FreeBSD.org In-Reply-To: <199611112216.QAA19966@brasil.moneng.mei.com> from "Joe Greco" at Nov 11, 96 04:16:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Turn off result codes. > > ATZ > ATQ1&W > > Also set the modem to do a reset on DTR transition. Then if you need to > dial out, you can use "ATQ0" in your dial string to force the modem to > provide result codes for the dialer program. Ugh... a mechanistic answer. 8-) 8-). The "reset as if powered off then on for on-to-off DCD transition" is usually Hayes "AT&D2". The "DCD follows remote carrier is usually "AT&C1". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Nov 11 15:43:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21504 for hackers-outgoing; Mon, 11 Nov 1996 15:43:56 -0800 (PST) Received: from ingenieria ([168.176.15.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA21484; Mon, 11 Nov 1996 15:43:44 -0800 (PST) Received: by ingenieria (SMI-8.6/SMI-SVR4) id SAA01317; Mon, 11 Nov 1996 18:43:35 +0600 Date: Mon, 11 Nov 1996 18:43:35 +0600 (GMT) From: Pedro Giffuni To: Andreas Klemm cc: FreeBSD-fs@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Info on SYSV fs available: filesystem expert required In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Andreas Klemm wrote: >=20 > What about a place in /usr/share/doc ... ? Especially for=20 > technical manuals, reports ?! For the time being I left a copy in freefall (/incoming), it seemed to=20 have less junk than ftp.freebsd.org. Its called main2.ps.gz (very short), when more information arrives I will= =20 write an explanatory note and make it available. Pedro. > On Mon, 11 Nov 1996, Pedro Giffuni S. wrote: >=20 > > Hello: > > Paul Monday just sent me a postscript file with the information of how > > he implemented an SCO filesystem for Linux. He is going to send me the > > tarball also. > > It doesn=B4t seem difficult, but someone that knows the inner workings = of > > FreeBSD filesystems can do a really great job. > > Where should I put this information? >=20 > andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechni= k GmbH > Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@= wup.de > pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered = by <<< > ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeB= SD <<< >=20 >=20 From owner-freebsd-hackers Mon Nov 11 15:45:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21704 for hackers-outgoing; Mon, 11 Nov 1996 15:45:47 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA21697 for ; Mon, 11 Nov 1996 15:45:43 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id RAA21351; Mon, 11 Nov 1996 17:45:21 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id RAA25570; Mon, 11 Nov 1996 17:45:20 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id RAA10212; Mon, 11 Nov 1996 17:45:18 -0600 (CST) From: Karl Denninger Message-Id: <199611112345.RAA10212@Jupiter.Mcs.Net> Subject: Re: Problems restoring Backups !!! To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Mon, 11 Nov 1996 17:45:17 -0600 (CST) Cc: andreas@klemm.gtn.com, acorreia@marlin.com.br, hackers@freebsd.org In-Reply-To: <199611112303.PAA17972@freefall.freebsd.org> from "Justin T. Gibbs" at Nov 11, 96 03:03:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >options AHC_SCBPAGING_ENABLE > >options AHC_TAGENABLE # still makes problems with tap > >es > >options SCSI_REPORT_GEOMETRY > > > >I get now thousands of (looping) Queue Full lines, when trying to make > >a backup using dump(8). > > Remove the printf and see if it works okay for you. The printf probably > causes a cascade effect since it will cause syslogd to write to the disk. > I'll also look into changing the code to try to actively reduce the number > of transactions allowed to the target, but to do that correctly is a lot of > work - which is the main reason I added it to the generic SCSI layer on the > SCSI branch. Where can I find documentation on those AHC_* options, what they do, what they might break, and when (or if) I should enable them? My problem with turning them on is that I've heard that some older disks puke badly with them enabled. On the other hand, I presume there are *serious* performance enhancements available with them, specifically tagged-queueing. On our news server systems, I bet we could use that. But if its going to be something that comes at the risk of data corruption I'm leaving it off! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Mon Nov 11 16:14:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23606 for hackers-outgoing; Mon, 11 Nov 1996 16:14:19 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23601; Mon, 11 Nov 1996 16:14:07 -0800 (PST) Message-Id: <199611120014.QAA23601@freefall.freebsd.org> To: Karl Denninger cc: andreas@klemm.gtn.com, acorreia@marlin.com.br, hackers@freebsd.org Subject: Re: Problems restoring Backups !!! In-reply-to: Your message of "Mon, 11 Nov 1996 17:45:17 CST." <199611112345.RAA10212@Jupiter.Mcs.Net> Date: Mon, 11 Nov 1996 16:14:07 -0800 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Where can I find documentation on those AHC_* options, what they do, what >they might break, and when (or if) I should enable them? man 4 ahc >My problem with turning them on is that I've heard that some older disks >puke badly with them enabled. If your worried about data corruption (ie you don't have a server you can kick around to test this before deploying it), stay away from SCB paging. I think it works now, but it has not been tested by enough people yet. >On the other hand, I presume there are *serious* performance enhancements >available with them, specifically tagged-queueing. Tagged queueing offers a serios benefit and works just fine. The only reason it is an option (defaulting to off) is that some drives that say they can do tagged queuing can't. This is being remedied in the 'SCSI' branch by moving the tagged queueing stuff to the common layer and allowing quirk entries to be added for "losing" devices. SCB Paging is usefull because it allows more tags to be active at once. >-- >Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity >http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo >Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net >/ >Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Interna >l -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Nov 11 16:53:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA02389 for hackers-outgoing; Mon, 11 Nov 1996 16:53:07 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA02373 for ; Mon, 11 Nov 1996 16:53:01 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id TAA04679; Mon, 11 Nov 1996 19:57:27 -0500 Date: Mon, 11 Nov 1996 19:57:27 -0500 Message-Id: <199611120057.TAA04679@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: roberto@keltia.freenix.fr (Ollivier Robert) From: dennis@etinc.com (dennis) Subject: Re: Setting PPP netmask! HOW! Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to a bunch of people.... >According to Daniel O'Callaghan: >> and is totally unnecessary, as Denis says. Simply put, the difference is >> that you are running a ppp link within a single IP network (happens to be >> class C), while James is running a ppp link between two distinct IP networks. >> You: 193.56.58.20 --> 193.56.58.234 >> James: 203.16.20.1 --> 203.8.105.20 It still doesnt make a difference....setting up routing over the PPP link and defining the netmask of the serial line are two different things... the bottom line is that you are using direct routes to hosts (not via a net) when getting from here to there on the link itself. From a routing perspective (where the issue is next hop), the next hop is the host at the end of a Point to point modeled network rather than a gateway on a network or subnetted network. Defining it as a network is stupid, because there is no net...there are only 2 peers. Dennis From owner-freebsd-hackers Mon Nov 11 17:52:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA05670 for hackers-outgoing; Mon, 11 Nov 1996 17:52:32 -0800 (PST) Received: (from pst@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA05664; Mon, 11 Nov 1996 17:52:31 -0800 (PST) Date: Mon, 11 Nov 1996 17:52:31 -0800 (PST) From: Paul Traina Message-Id: <199611120152.RAA05664@freefall.freebsd.org> To: hackers, committers Subject: need to test a security patch for 2.1.5/2.1.6 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Folks, I need access to a machine running 2.1 -stable (pre-2.1.6) to apply a security patch against for the kernel. Basicly: 1. apply patch to -stable source 2. compile kernel 3. reboot machine with new kernel 4. run test program against machine The patch I need to test is the final part of the TCP syn fix. This has been running on a few systems for quite some time and has been tested previously, but I had to reconstruct it from memory due to the loss of my previous code (Joe, do you have it?) Either I need to do this, or someone with access to a -stable machine needs to contact me and pick up the patch and try it out. It's a one file patch (tcp_input.c). Thanks, Paul From owner-freebsd-hackers Mon Nov 11 20:05:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13064 for hackers-outgoing; Mon, 11 Nov 1996 20:05:39 -0800 (PST) Received: from janai.thuvia.org (linus.demon.co.uk [158.152.10.220]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13056 for ; Mon, 11 Nov 1996 20:05:26 -0800 (PST) Received: (from mark@localhost) by janai.thuvia.org (8.8.2/8.8.2) id EAA23202; Tue, 12 Nov 1996 04:04:58 GMT Message-Id: <199611120404.EAA23202@janai.thuvia.org> From: mark@linus.demon.co.uk (Mark Valentine) Date: Tue, 12 Nov 1996 04:04:58 +0000 In-Reply-To: Wolfram Schneider's message of Nov 12, 3:46am X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: hackers@freebsd.org, wosch@cs.tu-berlin.de Subject: Re: cvs commit: src/share/doc/handbook porting.sgml ports.sgml Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Wolfram Schneider > Date: Tue 12 Nov, 1996 > Subject: Re: cvs commit: src/share/doc/handbook porting.sgml ports.sgml > Jordan K. Hubbard writes: > >> I'm guessing sed, I thought Jordan had a disdain dislike for perl. :-) > > > >sed, definitely. I mean, who needs perl when you've already got > >sed, sh and awk? :-) > > Perl is 8 bit clean and can edit binary data. > > $ wc /kernel > 2379 24484 808608 /kernel > $ perl -npe 's,/sbin/,/SBIN/,g' /kernel | wc > 2379 24484 808608 /kernel > $ sed 's,/sbin/,/SBIN/,g' /kernel | wc > 67 753 29419 $ wc /kernel 3672 44913 1282638 /kernel $ /usr/gnu/bin/sed 's,/sbin/,/SBIN/,g' /kernel | wc 3672 44913 1282638 Are there any bugs in the perl implementation? If there are, do I have a choice of implementations? ;-) Mark. -- Mark Valentine at Home From owner-freebsd-hackers Mon Nov 11 20:24:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13755 for hackers-outgoing; Mon, 11 Nov 1996 20:24:08 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13724 for ; Mon, 11 Nov 1996 20:23:42 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id PAA04451; Tue, 12 Nov 1996 15:20:59 +1100 (EST) Date: Tue, 12 Nov 1996 15:20:58 +1100 (EST) From: "Daniel O'Callaghan" To: dennis cc: hackers@FreeBSD.org Subject: Re: Setting PPP netmask! HOW! In-Reply-To: <199611120057.TAA04679@etinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, dennis wrote: > According to a bunch of people.... > > >According to Daniel O'Callaghan: > >> and is totally unnecessary, as Denis says. Simply put, the difference is > >> that you are running a ppp link within a single IP network (happens to be > >> class C), while James is running a ppp link between two distinct IP networks. > >> You: 193.56.58.20 --> 193.56.58.234 > >> James: 203.16.20.1 --> 203.8.105.20 > > It still doesnt make a difference....setting up routing over the PPP link > and defining the netmask of the serial line are two different things... > the bottom line is that you are using direct routes to hosts (not via a > net) when getting from here to there on the link itself. From a > routing perspective (where the issue is next hop), the next hop > is the host at the end of a Point to point modeled network rather > than a gateway on a network or subnetted network. Defining it > as a network is stupid, because there is no net...there are only > 2 peers. TrueAccording to a bunch of people.... > > >According to Daniel O'Callaghan: > >> and is totally unnecessary, as Denis says. Simply put, the difference is > >> that you are running a ppp link within a single IP network (happens to be > >> class C), while James is running a ppp link between two distinct IP networks. > >> You: 193.56.58.20 --> 193.56.58.234 > >> James: 203.16.20.1 --> 203.8.105.20 > > It still doesnt make a difference....setting up routing over the PPP link > and defining the netmask of the serial line are two different things... > the bottom line is that you are using direct routes to hosts (not via a > net) when getting from here to there on the link itself. From a > routing perspective (where the issue is next hop), the next hop > is the host at the end of a Point to point modeled network rather > than a gateway on a network or subnetted network. Defining it > as a network is stupid, because there is no net...there are only > 2 peers. True, but sliplogin or slattach or gated (something, I can't remember which) *does* apply the interface netmask to decide which hosts are gatewayed by the remote end. Probably just some fudging, as you say. Danny From owner-freebsd-hackers Mon Nov 11 20:26:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13836 for hackers-outgoing; Mon, 11 Nov 1996 20:26:17 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13829; Mon, 11 Nov 1996 20:26:13 -0800 (PST) Message-Id: <199611120426.UAA13829@freefall.freebsd.org> To: Andreas Klemm cc: "Alexsandro D. F. Correia" , hackers@FreeBSD.org Subject: Re: Problems restoring Backups !!! In-reply-to: Your message of "Mon, 11 Nov 1996 22:16:10 +0100." Date: Mon, 11 Nov 1996 20:26:12 -0800 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >I get now thousands of (looping) Queue Full lines, when trying to make >a backup using dump(8). Well, I can't fix it completely unless I change some unsigned variables to signed in the scsi code, but I don't want to do that unless its absolutely necessary as it may break more code then it fixes. This should drop you down to at most 1 more tag than your drive can handle, which should make the problem less of a problem. It also won't fill your log file up. Let me know how this works out for you... >-- >andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik Gmb >H > Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.d >e >pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by << >< >ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD << >< > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== Index: i386/scsi/aic7xxx.c =================================================================== RCS file: /usr/cvs/src/sys/i386/scsi/aic7xxx.c,v retrieving revision 1.85 diff -c -r1.85 aic7xxx.c *** aic7xxx.c 1996/11/11 05:24:44 1.85 --- aic7xxx.c 1996/11/12 04:19:04 *************** *** 1206,1226 **** if (xs->error == XS_NOERROR) xs->error = XS_DRIVER_STUFFUP; break; case SCSI_BUSY: xs->error = XS_BUSY; sc_print_addr(xs->sc_link); printf("Target Busy\n"); - break; - case SCSI_QUEUE_FULL: - /* - * The upper level SCSI code will someday - * handle this properly. - */ - printf("Queue Full\n"); - /* - * XXX requeue this unconditionally. - */ - STAILQ_INSERT_HEAD(&ahc->waiting_scbs, scb, links); break; default: sc_print_addr(xs->sc_link); --- 1206,1242 ---- if (xs->error == XS_NOERROR) xs->error = XS_DRIVER_STUFFUP; break; + case SCSI_QUEUE_FULL: + if (scb->hscb->control & TAG_ENB) { + /* + * The upper level SCSI code in 3.0 + * handles this properly... + */ + struct scsi_link *sc_link; + + sc_link = xs->sc_link; + if (sc_link->active > 2 + && sc_link->opennings != 0) { + /* truncate the opennings */ + sc_link->opennings = 0; + sc_print_addr(sc_link); + printf("Tagged openings reduced to " + "%d\n", sc_link->active); + } + /* + * XXX requeue this unconditionally. + */ + STAILQ_INSERT_TAIL(&ahc->waiting_scbs, scb, + links); + break; + } + /* Else treat as if it is a BUSY condition */ + scb->hscb->status = SCSI_BUSY; + /* Fall Through... */ case SCSI_BUSY: xs->error = XS_BUSY; sc_print_addr(xs->sc_link); printf("Target Busy\n"); break; default: sc_print_addr(xs->sc_link); From owner-freebsd-hackers Mon Nov 11 20:40:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA20798 for hackers-outgoing; Mon, 11 Nov 1996 20:40:05 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA20780 for ; Mon, 11 Nov 1996 20:40:03 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id UAA02181; Mon, 11 Nov 1996 20:39:52 -0800 (PST) Message-Id: <199611120439.UAA02181@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Sujal Patel cc: Charles Henrich , hackers@FreeBSD.org Subject: Re: Xing Streamworks Player In-reply-to: Your message of "Mon, 11 Nov 1996 13:10:03 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Nov 1996 20:39:52 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Anyone got the linux shared libraries to run Xing StreamWorks? The guspnp driver supports SNDCTL_DSP_GETOPTR Tnks, Amancio >From The Desk Of Sujal Patel : > On Mon, 11 Nov 1996, Charles Henrich wrote: > > > > fd=9, typ=0xc50(P),num=0x12 > > > > > > But it does seem to work okay, any ideas on what that IOCTL is? > > > > #define SNDCTL_DSP_GETOPTR _IOR ('P',18, count_info) > > > > and now you know as much as I do. > > We can't fix this until the new sound driver is imported (what's the > status John? :-). If no one objects, I'll just put a skeleton in and > no-op it for now. > > > Sujal > From owner-freebsd-hackers Mon Nov 11 21:03:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA21744 for hackers-outgoing; Mon, 11 Nov 1996 21:03:26 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA21738 for ; Mon, 11 Nov 1996 21:03:21 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vNAzd-0005ot-00; Mon, 11 Nov 1996 22:02:37 -0700 To: "Daniel O'Callaghan" Subject: Re: Setting PPP netmask! HOW! Cc: dennis , hackers@freebsd.org In-reply-to: Your message of "Tue, 12 Nov 1996 15:20:58 +1100." References: Date: Mon, 11 Nov 1996 22:02:37 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message "Daniel O'Callaghan" writes: : True, but sliplogin or slattach or gated (something, I can't remember : which) *does* apply the interface netmask to decide which hosts are : gatewayed by the remote end. Probably just some fudging, as you say. We use gated here to keep sane routes. We'd give it up in about 2 seconds if something better were to come along, however. It is a pain in the butt to setup. About 1/2 the time in getting a slip/ppp connection going in the village is fighting modems. The other half is gated config file problems :-(. Warner From owner-freebsd-hackers Mon Nov 11 21:14:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA22191 for hackers-outgoing; Mon, 11 Nov 1996 21:14:58 -0800 (PST) Received: from deceased.hb.north.de (deceased.hb.north.de [194.94.232.249]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA22186 for ; Mon, 11 Nov 1996 21:14:55 -0800 (PST) Received: from jelal.hb.north.de by deceased.hb.north.de with uucp (Smail3.2) id m0vNBB0-0016D4C; Tue, 12 Nov 1996 06:14:22 +0100 (MET) Received: by jelal.hb.north.de (SMail-ST 0.95gcc/2.5+) id AA00206; Tue, 12 Nov 1996 05:40:56 +0100 (CET) Received: (from nox@localhost) by saturn.hb.north.de (8.7.5/8.7.3) id FAA16955; Tue, 12 Nov 1996 05:18:48 +0100 (MET) Date: Tue, 12 Nov 1996 05:18:48 +0100 (MET) From: Juergen Lock Message-Id: <199611120418.FAA16955@saturn.hb.north.de> To: mark@quickweb.com Subject: Re: JDK 1.0.2 on FreeBSD In-Reply-To: References: <9611081547.AA08574@handset.laa.com> Organization: none Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you write: >You can try out a "beta" version by grabbing jdk.1.0.2.tar.gz at >ftp://frefall.freebsd.org/incoming > >I't quite good. The javac compiler seems perfect so far. The java >interpreter isn't so hot however -- although the only problems I've >really >had with it are in the AWT (same problems as Linux exhibits - general AWT >crappyness and inconsistency with the specification) and for some >reason I can't seem to be able to open "ServerSocket" sockets.. >I get a "Resource temporarily Unavailable" exception. I haven't tried that one but... > >And, like all Unix JKD's, it only runs in 8bpp or 24bpp. So 256 or >16Million colors are it --> no 32K or 64K color modes. :-( ..the (linux) JDK 1.0.1something i've installed seems to run on 16bpp just fine. seems they have fixed at least this problem? > >I've been testing it quite hard, cause I think it will be important for >FreeBSD to have FULL java support in the future, so take a look at it, and >report bugs to hacker@freebsd.org. Note, however, that the port isn't >officially supported by the author. > > >Oh yeah, it also seems brutal slow at bringing up dialog windows. Not sure >why! The multithreaded stuff also is VERY slow. Again, I've seen the >same problems on the Linux port from Blackdown, so I'm guessing the >FreeBSD port borrows heavily from it. I guess it's tricky to do threading >on an OS that doesn't have threads (at least not in the kernel). thats true, especially code that uses /dev/(pc)audio seems to just deadlock every once in a while. (again this is the linux JDK, haven't tried the native port yet) just thought i'd mention... cheers, Juergen From owner-freebsd-hackers Mon Nov 11 22:28:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25772 for hackers-outgoing; Mon, 11 Nov 1996 22:28:10 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA25733 for ; Mon, 11 Nov 1996 22:27:58 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id BAA08757; Tue, 12 Nov 1996 01:26:21 -0500 (EST) Date: Tue, 12 Nov 1996 01:26:20 -0500 (EST) From: "Marc G. Fournier" To: Joe Greco cc: Terry Lambert , twpierce@bio-3.bsd.uchicago.edu, hackers@FreeBSD.org Subject: Re: semaphores/shared memory In-Reply-To: <199611111905.NAA19699@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Joe Greco wrote: > > > Okay, now bearing in mind that I'm looking at the examples as > > > presented in "Unix Network Programming" by W. Richard Stevens...how > > > do n clients signal back to the server that its finished with the data > > > and can send up the next set of data? > > > > This is why I didn't suggest the same soloution. > > > > However, now I have to question my assumptions... why is it necessary > > for the clients to signal the server? > > Reuse of the buffer area? > > It would be stupid for the server to start writing new data before > everyone else is done with it. > > *shrug* > Ya, but this could be gotten around if we create several buffers that get written to sequentially...then the server can make the assumption (in my case, the assumption would be safe) that by the time the server got back to writing to area 1, the clients aren't much behind it... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Mon Nov 11 22:31:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25908 for hackers-outgoing; Mon, 11 Nov 1996 22:31:59 -0800 (PST) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA25888 for ; Mon, 11 Nov 1996 22:31:52 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.7.6/8.7.3) id QAA04641 for hackers@freebsd.org; Tue, 12 Nov 1996 16:31:37 +1000 Received: from pandora.devetir.qld.gov.au by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id QAA13565 for ; Tue, 12 Nov 1996 16:35:37 +1000 (EST) Received: from netfl15a.devetir.qld.gov.au (netfl15a.devetir.qld.gov.au [167.123.24.12]) by pandora.devetir.qld.gov.au (8.6.10/8.6.12) with ESMTP id QAA20029 for ; Tue, 12 Nov 1996 16:32:51 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id GAA27134 for ; Tue, 12 Nov 1996 06:31:29 GMT Message-Id: <199611120631.GAA27134@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: hackers@freebsd.org Subject: PPP Question - help! X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 16:31:29 +1000 From: Stephen Hocking Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to connect to a particular ISP, who normally has people using winsock et cetera as clients. When I login, the ppp.log shows the following - 11-12 16:20:37 [259] Using interface: tun0 11-12 16:20:37 [259] PPP Started. 11-12 16:21:46 [259] *Connected! 11-12 16:22:08 [259] Phase: Authenticate 11-12 16:22:08 [259] Phase: Network 11-12 16:22:11 [259] myaddr = 203.12.164.198 hisaddr = 0.0.0.0 11-12 16:22:11 [259] OsLinkup: 0.0.0.0 & I ge the message SIOCAIFADDR: Destination address required, clearly because this person (for some reason) isn't supplying the address at their end. What do I need to set up at my end to make this work? My ppp.conf file has the following - default: set line /dev/tty00 set speed 57600 set parity none set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATZ OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" ispfoo set phone 12345678 set authname noname set authkey NotReallyMyPassword set parity none set login "TIMEOUT 10 ername: \\U word: \\P oice: ppp" set timeout 0 dial -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Mon Nov 11 22:50:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26796 for hackers-outgoing; Mon, 11 Nov 1996 22:50:37 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA26782; Mon, 11 Nov 1996 22:50:32 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id HAA01455; Tue, 12 Nov 1996 07:50:26 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id HAA11669; Tue, 12 Nov 1996 07:50:00 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id HAA26728; Tue, 12 Nov 1996 07:37:35 +0100 (MET) Message-ID: Date: Tue, 12 Nov 1996 07:37:34 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@FreeBSD.org Cc: freebsd-isp@FreeBSD.org Subject: Re: PPP/LCP sensing getty References: <199611112216.QAA19966@brasil.moneng.mei.com> X-Mailer: Mutt 0.50.05 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2686 In-Reply-To: <199611112216.QAA19966@brasil.moneng.mei.com>; from Joe Greco on Nov 11, 1996 16:16:24 -0600 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Joe Greco: > Also set the modem to do a reset on DTR transition. Then if you need to > dial out, you can use "ATQ0" in your dial string to force the modem to > provide result codes for the dialer program. Some modems provide an ATQ2 command just for that. Silent when answering and verbose when calling. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996 From owner-freebsd-hackers Tue Nov 12 01:38:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA06257 for hackers-outgoing; Tue, 12 Nov 1996 01:38:13 -0800 (PST) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA06239 for ; Tue, 12 Nov 1996 01:38:03 -0800 (PST) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id BAA11137 for ; Tue, 12 Nov 1996 01:39:23 -0800 Date: Tue, 12 Nov 1996 01:39:22 -0800 (PST) From: Veggy Vinny To: hackers@FreeBSD.ORG Subject: 3Com 10/100MBps Cards in -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi everyone, I was wondering if the 3Com 100Mbps ethernet cards using 3c595 and 3c905 chipsets? I was looking in the kernel LINT config file but couldn't find an entry for it. Thanks in advance for any help. Vince GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin From owner-freebsd-hackers Tue Nov 12 01:44:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA06554 for hackers-outgoing; Tue, 12 Nov 1996 01:44:28 -0800 (PST) Received: from hq.icb.chel.su (hq.icb.chel.su [193.125.10.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA06536 for ; Tue, 12 Nov 1996 01:44:04 -0800 (PST) Received: (babkin@localhost) by hq.icb.chel.su (8.7.5/8.6.5) id OAA27878; Tue, 12 Nov 1996 14:13:27 +0500 (ESK) From: "Serge A. Babkin" Message-Id: <199611120913.OAA27878@hq.icb.chel.su> Subject: Re: Fwd: Digiboard driver To: davidn@sdev.usn.blaze.net.au (David Nugent) Date: Tue, 12 Nov 1996 14:13:27 +0500 (ESK) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "David Nugent" at Nov 11, 96 08:43:34 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > --evf6ppmFHys1AiCM > > [originally posted in -questions, but no response] > > I heard mention some time ago that the Linux Digiboard driver > had been ported to FreeBSD. > > Who maintains this port? I cannot find it in -current sources, > and I'm interested in furthering its development. > It is in /usr/src/sys/gnu/i386/isa. Really -stable has more recent version of driver than -current. -SB From owner-freebsd-hackers Tue Nov 12 02:21:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA08737 for hackers-outgoing; Tue, 12 Nov 1996 02:21:27 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA08732 for ; Tue, 12 Nov 1996 02:21:17 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id CAA03492; Tue, 12 Nov 1996 02:20:50 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id VAA30753; Tue, 12 Nov 1996 21:20:07 +1100 From: Julian Assange Message-Id: <199611121020.VAA30753@suburbia.net> Subject: predictor-clues [was ufs too slow?] To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 12 Nov 1996 21:20:06 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <7358.847790435@time.cdrom.com> from "Jordan K. Hubbard" at Nov 12, 96 01:20:35 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Xfs is pretty fragile from what I've heard. > > > > SGI's XFS is actually pretty robust. We run 16 and 32GB file > > systems with it, and the performance is good. It can handle > > an FS of some-number Terabytes. It is really a journal filesystem, > > Actually, Matt Dillon over at BEST Internet talked about their > experiences with XFS in a recent presentation, and his opinion of XFS > was far from flattering. In their experience, using XFS was a good > way of crashing IRIX far too frequently for comfort. > > Jordan One thing that never ceases to annoy me about current opperating systems, API's and compilers is the lack of support for predictor-clues. File system layout could be hugely optimised if open had predictor-clues such as "expected file size", "average read/write size", "sequential/random access factor", "minimal time response" etc. I'm suprised no one has incorporated such predictor-clues for branch optimisation in GCC. i.e this if has a 1/1,000,000 chance of actually being taken (error condition). You can optimise this so that you can thread a path of probabilities through the code, and (physically) move the inprobable code away from the probable path. This would improve code cache-hit rates so much it isn't funny. Recent Solaris cc/ld impliment a poor-man's version of this path to physical association by examining which functions are called by what functions and clustering the object code accordingly. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Tue Nov 12 04:29:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA20353 for hackers-outgoing; Tue, 12 Nov 1996 04:29:50 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA20343 for ; Tue, 12 Nov 1996 04:29:43 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id GAA20953; Tue, 12 Nov 1996 06:26:21 -0600 From: Joe Greco Message-Id: <199611121226.GAA20953@brasil.moneng.mei.com> Subject: Re: semaphores/shared memory To: scrappy@ki.net (Marc G. Fournier) Date: Tue, 12 Nov 1996 06:26:20 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, twpierce@bio-3.bsd.uchicago.edu, hackers@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at Nov 12, 96 01:26:20 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Reuse of the buffer area? > > > > It would be stupid for the server to start writing new data before > > everyone else is done with it. > > > > *shrug* > > > > Ya, but this could be gotten around if we create several buffers > that get written to sequentially...then the server can make the assumption > (in my case, the assumption would be safe) that by the time the server got > back to writing to area 1, the clients aren't much behind it... I have a friend who is fond of saying that assumption is the mother of all ****ups... :-) ... JG From owner-freebsd-hackers Tue Nov 12 05:12:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA22580 for hackers-outgoing; Tue, 12 Nov 1996 05:12:21 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA22503; Tue, 12 Nov 1996 05:12:02 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id FAA02528; Tue, 12 Nov 1996 05:12:06 -0800 (PST) To: announce@freebsd.org cc: hackers@freebsd.org Subject: Sup services no longer available from freefall.FreeBSD.ORG Date: Tue, 12 Nov 1996 05:12:05 -0800 Message-ID: <2522.847804325@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk freefall.FreeBSD.ORG AKA sup.FreeBSD.ORG is no longer providing sup services due to load problems. sup.FreeBSD.ORG now points to burka.rdy.com (aka sup3.FreeBSD.ORG) and should be ready for service as such just as soon as the DNS changes propagate. sup2.FreeBSD.ORG no longer exists, apparently, so now sup, sup2 and sup3 all point to the same machine (burka) until such time as we get more sup servers. Thanks to Dima Ruban for kindly providing what service we currently have now! freefall still provides CVSup services as cvsup.FreeBSD.ORG and people are encouraged to switch. CVSup is John Polstra's far more efficient and powerful sup replacement utility, and a far more efficient user of network bandwidth. With sup, anytime someone tagged the CVS tree Walnut Creek CDROM's T1 line would melt down as sup stupidly transfered *every single file* all over again, and FreeBSD's increasing popularity has made that situation no longer tolerable. For more information on CVSup, please see: ftp://freefall.FreeBSD.ORG/pub/CVSup Thanks! Jordan From owner-freebsd-hackers Tue Nov 12 05:23:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA23072 for hackers-outgoing; Tue, 12 Nov 1996 05:23:13 -0800 (PST) Received: from home.winc.com (root@home.winc.com [204.178.182.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA23051; Tue, 12 Nov 1996 05:22:52 -0800 (PST) Received: from phoenix.aristar.com (slip125.winc.com [204.178.182.125]) by home.winc.com (8.7.5/8.7.3) with SMTP id IAA08890; Tue, 12 Nov 1996 08:22:43 -0500 Message-ID: <32887A8B.2781E494@aristar.com> Date: Tue, 12 Nov 1996 08:24:27 -0500 From: "Matthew A. Gessner" Organization: Aristar, Inc. X-Mailer: Mozilla 3.01b1 (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: hackers , FreeBSD Hardware group Subject: Dell laptop problems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, all, Well, I *thought* I had this stupid machine working... When I boot the machine (2.1.5R) with the 3Com pc-card in it, these symptoms are a little less annoying, but they're still there: When I boot the machine, it runs SLOOOOOW (75Mhz Pentium). If I boot with -c, and then do 'vi' I get 'blocky' response: it does a few lines of text, waits for 60 seconds, does a little more, etc. If I do anything like press X to expand everything, I still wait. When I'm finally done, it hangs for about 3-4 minutes trying to find psm0, which I've configured correctly, I think. It finds all the devices, eventually. It also wants to hang on wd0 when it finds it. Finally, after init starts, I have to press Ctrl-C a few times to get it to finish the sequence of startups. When the system is all done booting, it seems to run fine when I login as root. Can anyone shed any light on what I might be doing wrong? Some of this behaviour is inconsistent: for example sometimes the CPU identification runs quickly (1-3 seconds), but other times it takes a couple of minutes. I'm guessing maybe something's wrong with the BIOS settings, but I would have no idea where to start. Thanks in advance, guys, Matt -- Matthew Gessner, Computer Scientist, Aristar, Inc. 302 N. Cleveland-Massillon Rd. Akron, OH 44333 Voice (330) 668-2267, Fax (330) 668-2961 From owner-freebsd-hackers Tue Nov 12 06:09:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA26207 for hackers-outgoing; Tue, 12 Nov 1996 06:09:41 -0800 (PST) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA26155 for ; Tue, 12 Nov 1996 06:08:52 -0800 (PST) Received: from campa.panke.de (anonymous214.ppp.cs.tu-berlin.de [130.149.17.214]) by mail.cs.tu-berlin.de (8.6.13/8.6.12) with ESMTP id OAA23793; Tue, 12 Nov 1996 14:43:41 +0100 Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id OAA00453; Tue, 12 Nov 1996 14:04:22 +0100 Date: Tue, 12 Nov 1996 14:04:22 +0100 From: Wolfram Schneider Message-Id: <199611121304.OAA00453@campa.panke.de> To: mark@linus.demon.co.uk (Mark Valentine) Cc: hackers@freebsd.org Subject: Re: cvs commit: src/share/doc/handbook porting.sgml ports.sgml In-Reply-To: <199611120404.EAA23202@janai.thuvia.org> References: <199611120404.EAA23202@janai.thuvia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Valentine writes: >> From: Wolfram Schneider >> Jordan K. Hubbard writes: >> >> I'm guessing sed, I thought Jordan had a disdain dislike for perl. :-) >> > >> >sed, definitely. I mean, who needs perl when you've already got >> >sed, sh and awk? :-) >> >> Perl is 8 bit clean and can edit binary data. >> >> $ wc /kernel >> 2379 24484 808608 /kernel >> $ perl -npe 's,/sbin/,/SBIN/,g' /kernel | wc >> 2379 24484 808608 /kernel >> $ sed 's,/sbin/,/SBIN/,g' /kernel | wc >> 67 753 29419 > >$ wc /kernel > 3672 44913 1282638 /kernel >$ /usr/gnu/bin/sed 's,/sbin/,/SBIN/,g' /kernel | wc > 3672 44913 1282638 > >Are there any bugs in the perl implementation? Yes, of course. >If there are, do I have >a choice of implementations? ;-) perl4, perl5, perl5.00x Wolfram From owner-freebsd-hackers Tue Nov 12 08:07:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA01590 for hackers-outgoing; Tue, 12 Nov 1996 08:07:35 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA01584 for ; Tue, 12 Nov 1996 08:07:14 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id LAA09550; Tue, 12 Nov 1996 11:09:30 -0500 Date: Tue, 12 Nov 1996 11:09:30 -0500 Message-Id: <199611121609.LAA09550@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: davidn@sdev.usn.blaze.net.au (David Nugent) From: dennis@etinc.com (dennis) Subject: Re: Setting PPP netmask! HOW! Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >dennis writes: >> >I'm using PPP under 2.1.5 to connect to my ISP. I have my own >> >C-Class but currently it is trashed as PPP under freebsd seems >> >to not give you the option to set the netmask!! I have looked >> >through the manuals with no help. I have made many guess attempts >> >in the config files to see if it had any effect NADA! >> >> Thats because FreeBSD is smart enough to know how to route to >> a host address, unlike many of the more popular routers on the >> market. I believe that the netmask is meaningless on a PTP interface, >> so even if you get it to display the way you want you won't have >> achieved much of anything. > >Hmm. > >davidn@unique[~]$ ifconfig ppp0 >ppp0: flags=8051 mtu 1500 > inet 203.17.53.17 --> 203.17.53.1 netmask 0xfffffff0 > >Now *that* netmask certainly means something. If it wasn't for that, >I wouldn't be able to effectively run a subnet of a class C network >over a ppp link. Study up on host routing and call me in the morning! > >And, yes, the netmask is real. It'd have to be for the sake of the >subnet, which is being correctly routed at both ends of the >connection. wrong. > >I believe you are mistaken on both counts. wrong again. I find it truly amazing that so many people that spend so much time doing stuff have no idea how it works! I guess the hackers should be very happy that they've made the process so transparent that you (apparently) don't have to know how it works to make it work. Good job guys. I'm tired of getting flamed when I'm right...this is almost as bad as the bsd/os list! Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD and LINUX From owner-freebsd-hackers Tue Nov 12 08:08:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA01693 for hackers-outgoing; Tue, 12 Nov 1996 08:08:27 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA01661 for ; Tue, 12 Nov 1996 08:08:18 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id LAA09573; Tue, 12 Nov 1996 11:13:29 -0500 Date: Tue, 12 Nov 1996 11:13:29 -0500 Message-Id: <199611121613.LAA09573@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Daniel O'Callaghan" From: dennis@etinc.com (dennis) Subject: Re: Setting PPP netmask! HOW! Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Danny O writes... >True, but sliplogin or slattach or gated (something, I can't remember >which) *does* apply the interface netmask to decide which hosts are >gatewayed by the remote end. Probably just some fudging, as you say. GateD is quite stupid....but its way too much to re-write...so I guess we're stuck with it. It would be an incredibly profitable commerical opportunity though....... Dennis From owner-freebsd-hackers Tue Nov 12 08:10:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA01845 for hackers-outgoing; Tue, 12 Nov 1996 08:10:49 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA01827; Tue, 12 Nov 1996 08:10:34 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.8.2/8.8.2) id KAA13353; Tue, 12 Nov 1996 10:10:20 -0600 (CST) Date: Tue, 12 Nov 1996 10:10:20 -0600 (CST) From: Mark Tinguely Message-Id: <199611121610.KAA13353@plains.nodak.edu> To: freebsd-hackers@freebsd.org Subject: -current mbuf reference function Cc: freebsd-current@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't think the external reference (m_ext.ext_ref) function in the -current sys/mbuf.h is complete. First, the function m_copypacket in kern/uipc_mbuf.c only uses the old style reference incrememnt of: mclrefcnt[mtocl(m->m_ext.ext_buf)]++ and even worse the MCLFREE macros in sys/mbuf.h only uses: --mclrefcnt[mtocl(p)] == 0 to decrement the reference count and check to see if it time to release. I think either a increment/decrement flag is needed to m_ext.ext_ref, or an additional decrement function is needed, and this function is needed in the MCLFREE macro. --mark. From owner-freebsd-hackers Tue Nov 12 09:14:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA06534 for hackers-outgoing; Tue, 12 Nov 1996 09:14:35 -0800 (PST) Received: from dyslexic.phoenix.net (root@dyslexic.phoenix.net [199.3.233.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA06523 for ; Tue, 12 Nov 1996 09:14:24 -0800 (PST) Received: (from freebsd@localhost) by dyslexic.phoenix.net (8.7.5/8.7.3) id LAA13119; Tue, 12 Nov 1996 11:14:23 -0600 (CST) Date: Tue, 12 Nov 1996 11:14:23 -0600 (CST) From: FreeBSD Acct To: hackers@freebsd.org Subject: Trafshow Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone a clue why trafshow will not use my fpa0 device. It seems not to support it. From owner-freebsd-hackers Tue Nov 12 09:32:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07528 for hackers-outgoing; Tue, 12 Nov 1996 09:32:18 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA07464; Tue, 12 Nov 1996 09:32:00 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id JAA00583; Tue, 12 Nov 1996 09:29:44 -0800 (PST) Message-ID: <3288B3F1.41C67EA6@whistle.com> Date: Tue, 12 Nov 1996 09:29:21 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Mark Tinguely CC: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: -current mbuf reference function References: <199611121610.KAA13353@plains.nodak.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Mark Tinguely wrote: > > I don't think the external reference (m_ext.ext_ref) function in the -current > sys/mbuf.h is complete. First, the function m_copypacket in kern/uipc_mbuf.c > only uses the old style reference incrememnt of: > > mclrefcnt[mtocl(m->m_ext.ext_buf)]++ > > and even worse the MCLFREE macros in sys/mbuf.h only uses: > > --mclrefcnt[mtocl(p)] == 0 > > to decrement the reference count and check to see if it time to release. > > I think either a increment/decrement flag is needed to m_ext.ext_ref, or an > additional decrement function is needed, and this function is needed in the > MCLFREE macro. > > --mark. This code was originally in BSD4.3. We use it in our 4.3 , OSF1 and FreeBSD based systems to pass around externally defined objects the idea is that if the M_EXT flag is set but there is no ext_free function defined, then is is a default Mbuf cluster and the default functions are called. If there is a special ext_free function defined then use it instead. A cleaner method would be to Impliment the default functions in the same was as teh exception functions, in other words always have ext_free and ext_ref pointers defined, but in the default case they point to the default functions. I think it wasn't done that way simply to reduce the impact of the change, as the Mbuf cluster code was pre-existing. the function ext_ref is to increment the number of references to the object (e.g. if you were to duplicate the mbuf, but not duplicate the buffer,) and the ext_free routine is to decrement the references, (and presumably free the item in an item-specific manner if the reference count reaches 0 ). The MCLFREE macro is not included in the MFREE macro only because that would duplicate the MBUFLOCK code. The MCLFREE code should only be called if the ext_free entry is NULL (as it is set to NULL in MCLGET). It could be argued that the MCLFREE macro should be able to handle the case inn which the free function exists, and call that instead.. I don't know how many active cases of MCLFREE there are in the code.. I can probably put up a good case that there shouldn't be many if any. usually MFREE could surfice as usually the whole mbuf is being freed. there is a further enhancement from the OSF code that is rather stunningly brilliant, that Matt Thomas wants to bring in.. I once had a version that incoporated it as well.. (for some ATM code he wants to import I believe) I may still do it.. julian From owner-freebsd-hackers Tue Nov 12 09:39:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08057 for hackers-outgoing; Tue, 12 Nov 1996 09:39:11 -0800 (PST) Received: from mickey.umiacs.umd.edu (12222@mickey.umiacs.umd.edu [128.8.120.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA08035 for ; Tue, 12 Nov 1996 09:38:38 -0800 (PST) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.6/UMIACS-0.9/04-05-88) id MAA06001; Tue, 12 Nov 1996 12:38:15 -0500 (EST) Date: Tue, 12 Nov 1996 12:38:15 -0500 (EST) From: Sujal Patel To: Amancio Hasty cc: Charles Henrich , hackers@FreeBSD.org Subject: Re: Xing Streamworks Player In-Reply-To: <199611120439.UAA02181@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Nov 1996, Amancio Hasty wrote: > Anyone got the linux shared libraries to run Xing StreamWorks? > > The guspnp driver supports SNDCTL_DSP_GETOPTR > > > > We can't fix this until the new sound driver is imported (what's the > > status John? :-). If no one objects, I'll just put a skeleton in and > > no-op it for now. I suppose we can just wrap the correct solution in an #ifdef notyet, and you can just undo it for your driver. Sujal From owner-freebsd-hackers Tue Nov 12 10:34:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA12166 for hackers-outgoing; Tue, 12 Nov 1996 10:34:02 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA12146 for ; Tue, 12 Nov 1996 10:33:39 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA20599; Tue, 12 Nov 1996 11:22:44 -0700 From: Terry Lambert Message-Id: <199611121822.LAA20599@phaeton.artisoft.com> Subject: Re: Linux compat issue(s) To: peter@taronga.com (Peter da Silva) Date: Tue, 12 Nov 1996 11:22:44 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199611101841.MAA22803@bonkers.taronga.com> from "Peter da Silva" at Nov 10, 96 12:41:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I am not familiar with ELF in particular, but other modern binary file > formats (IFF, MFF, PNG, even GIF) support a mechanism for adding entries > to the file without having to understand the file's content completely. > > What's wrong with using a NOTE field. Sure, the binary's size will change > but all the offsets should automagically drop in... How do you tell the difference between Linux binaries (which do not use the note field you suggest) and SVR4 binaries (which do not use the note field you suggest) on a FreeBSD box (which will create binaries with the note field, so all you can tell about the other binaries is that they are "ELF, not FreeBSD")? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 12 10:47:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA13089 for hackers-outgoing; Tue, 12 Nov 1996 10:47:02 -0800 (PST) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA13079 for ; Tue, 12 Nov 1996 10:46:30 -0800 (PST) Received: from campa.panke.de (anonymous214.ppp.cs.tu-berlin.de [130.149.17.214]) by mail.cs.tu-berlin.de (8.6.13/8.6.12) with ESMTP id TAA10034; Tue, 12 Nov 1996 19:25:42 +0100 Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id TAA00674; Tue, 12 Nov 1996 19:25:36 +0100 Date: Tue, 12 Nov 1996 19:25:36 +0100 From: Wolfram Schneider Message-Id: <199611121825.TAA00674@campa.panke.de> To: mark@linus.demon.co.uk (Mark Valentine), hackers@freebsd.org, Keith Bostic Subject: Re: cvs commit: src/share/doc/handbook porting.sgml ports.sgml In-Reply-To: <199611121304.OAA00453@campa.panke.de> References: <199611120404.EAA23202@janai.thuvia.org> <199611121304.OAA00453@campa.panke.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wolfram Schneider writes: >>> Jordan K. Hubbard writes: >>> >> I'm guessing sed, I thought Jordan had a disdain dislike for perl. :-) >>> > >>> >sed, definitely. I mean, who needs perl when you've already got >>> >sed, sh and awk? :-) >>> >>> Perl is 8 bit clean and can edit binary data. >>> >>> $ wc /kernel >>> 2379 24484 808608 /kernel >>> $ perl -npe 's,/sbin/,/SBIN/,g' /kernel | wc >>> 2379 24484 808608 /kernel >>> $ sed 's,/sbin/,/SBIN/,g' /kernel | wc >>> 67 753 29419 >> >>$ wc /kernel >> 3672 44913 1282638 /kernel >>$ /usr/gnu/bin/sed 's,/sbin/,/SBIN/,g' /kernel | wc >> 3672 44913 1282638 Ok, here is the patch. The problem occurs if a line *start* with character '\377'. C beginners bug, getc() return an int and not a char or unsigned char. Index: main.c =================================================================== RCS file: /usr/cvs/src/usr.bin/sed/main.c,v retrieving revision 1.3 diff -u -r1.3 main.c --- 1.3 1996/08/11 17:46:34 +++ main.c 1996/11/12 18:11:37 @@ -274,8 +274,7 @@ err(FATAL, "%s: %s", fname, strerror(errno)); } - if ((c = getc(f)) != EOF) { - (void)ungetc(c, f); + if (!feof(f)) { break; } (void)fclose(f); @@ -299,7 +298,7 @@ linenum++; /* Advance to next non-empty file */ - while ((c = getc(f)) == EOF) { + while (feof(f)) { (void)fclose(f); files = files->next; if (files == NULL) { @@ -315,7 +314,6 @@ err(FATAL, "%s: %s", fname, strerror(errno)); } } - (void)ungetc(c, f); return (1); } From owner-freebsd-hackers Tue Nov 12 10:48:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA13153 for hackers-outgoing; Tue, 12 Nov 1996 10:48:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA13125 for ; Tue, 12 Nov 1996 10:47:53 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA20668; Tue, 12 Nov 1996 11:35:50 -0700 From: Terry Lambert Message-Id: <199611121835.LAA20668@phaeton.artisoft.com> Subject: Re: predictor-clues [was ufs too slow?] To: proff@suburbia.net (Julian Assange) Date: Tue, 12 Nov 1996 11:35:50 -0700 (MST) Cc: jkh@time.cdrom.com, hackers@freebsd.org In-Reply-To: <199611121020.VAA30753@suburbia.net> from "Julian Assange" at Nov 12, 96 09:20:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > One thing that never ceases to annoy me about current opperating systems, > API's and compilers is the lack of support for predictor-clues. > > File system layout could be hugely optimised if open had predictor-clues > such as "expected file size", "average read/write size", > "sequential/random access factor", "minimal time response" etc. One thing that has always annoyed me about X11, Windows, and Macintosh is that they expect the application to do their work for them. Specifically, I can never be *guaranteed* backing store for graphics data for an occluded window; as a result, the application must redraw the image on expose events. Never mind that it took me 12 hours to generate the image in the first place. So every application, with the random *infrequent* exception that they were apparently optimizing for, has to do its own double buffering. As a result, there is no standard method for doing the damn thing, even though it's the most frequent thing anyone ever wants to do. Further, it means I have to jerk around with color maps and square root my colors (total bits minus one bit over two, round down) to get minimal scrolling dual playfield effects (as in ACM). The reason I mention this is that the default behaviour should be optimized for the most common case. In most cases, this means *not* using predictors even if they exist, because the default handles it for us like it's supposed to. In rare (non-default) cases, this means using madvise(). Feel free to make an OpenFile(3) that calls the appropriate open(2) and then ioctl(), madvise(), whatever, to it's hearts content. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Nov 12 11:58:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20694 for hackers-outgoing; Tue, 12 Nov 1996 11:58:13 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA20672 for ; Tue, 12 Nov 1996 11:58:08 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id LAA02102 for ; Tue, 12 Nov 1996 11:58:05 -0800 (PST) Message-Id: <199611121958.LAA02102@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@FreeBSD.org Subject: Re: Xing Streamworks Player In-reply-to: Your message of "Tue, 12 Nov 1996 12:38:15 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 11:58:05 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Cool, still no sign of the linux shared libraries to enable the Xing player to work .... Cheers, Amancio From owner-freebsd-hackers Tue Nov 12 12:15:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24614 for hackers-outgoing; Tue, 12 Nov 1996 12:15:40 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA24608 for ; Tue, 12 Nov 1996 12:15:37 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-38.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA05754 (5.67b/IDA-1.5 for ); Tue, 12 Nov 1996 21:15:30 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id VAA24764; Tue, 12 Nov 1996 21:03:30 +0100 (MET) Message-Id: <199611122003.VAA24764@x14.mi.uni-koeln.de> Date: Tue, 12 Nov 1996 21:02:10 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: durian@plutotech.com (Mike Durian) Cc: se@zpr.uni-koeln.de (Stefan Esser), freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-Reply-To: <199611112241.PAA04235@pluto.plutotech.com>; from Mike Durian on Nov 11, 1996 15:41:11 -0700 References: <199611112241.PAA04235@pluto.plutotech.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Durian writes: > On Mon, 11 Nov 1996 23:04:38 +0100, se@zpr.uni-koeln.de (Stefan Esser) wrote: > > > >Well, the PCI probe in your boot message logs looks different > >from everything I've seen before :-) > > We've certainly made some inhouse changes, but not much to the generic > pci code. You can ignore all those strange ISA devices at the end. > They're for some of our custom devices, and aren't even found on this > machine (despite some of the false positives). This output is from > /var/log/messages, not dmesg(8). > > >Please boot the same kernel (with your debug printf()s) again, > >but this time with the "-v" option at the "Boot: " prompt. > > Here you go. It looks like the mistaken i/o maps are from expansion > ROM maps. I still don't know about the DEC thing. Thanks! And I think I found something interesting ... Could you please let me know the value of PCI_MAP_REG_END that is defined in your version of /sys/pci/pcireg.h ? (It should be 0x28, in order to make the following for loop do the right thing: for (reg=PCI_MAP_REG_START;reg Nov 11 15:28:15 shane /kernel: ahc0 rev 0 int a irq 11 on pci0:20 > Nov 11 15:28:15 shane /kernel: vendor = 0x9004, device = 0x8178 > Nov 11 15:28:16 shane /kernel: map = 0xfc01, data = 0xffffff01 > Nov 11 15:28:16 shane /kernel: case 1,5: i/o addr = 0xfc00, size = 0x100 > Nov 11 15:28:16 shane /kernel: mapreg[10] type=1 addr=0000fc00 size=0100. > Nov 11 15:28:16 shane /kernel: map = 0xffbdf000, data = 0xfffff000 > Nov 11 15:28:16 shane /kernel: case 0,2,4: i/o addr = 0xffbdf000, size = 0x1000 > Nov 11 15:28:17 shane /kernel: mapreg[14] type=0 addr=ffbdf000 size=1000. Everything is fine so far ... > Nov 11 15:28:17 shane /kernel: map = 0xffbc0000, data = 0xffff0001 > Nov 11 15:28:17 shane /kernel: case 1,5: i/o addr = 0xffbc0000, size = 0x10000 > Nov 11 15:28:17 shane /kernel: mapreg[30] type=0 addr=ffbc0000 size=10000. Hmmm, what's that ? A map register at 0x30 in config space ??? > Nov 11 15:28:17 shane /kernel: reg16: ioaddr=0xfc00 size=0x100 > Nov 11 15:28:17 shane /kernel: reg48: virtual=0xf4951000 physical=0xffbc0000 size=0x10000 > Nov 11 15:28:18 shane /kernel: rom_reg=ffbc0001 Yes, it is a ROM, and the LSB is an enable ... And it is NOT allowed to be enabled while the adapter is used, or bad things may happen! > Nov 11 15:28:22 shane /kernel: map = 0xffbe0000, data = 0xffff0001 > Nov 11 15:28:22 shane /kernel: case 1,5: i/o addr = 0xffbe0000, size = 0x10000 > Nov 11 15:28:22 shane /kernel: mapreg[30] type=0 addr=ffbe0000 size=10000. > Nov 11 15:28:22 shane /kernel: de0 rev 32 int a irq 15 on pci0:17 > Nov 11 15:28:23 shane /kernel: vendor = 0x1011, device = 0x0009 > Nov 11 15:28:23 shane /kernel: map = 0xf881, data = 0xffffff81 > Nov 11 15:28:23 shane /kernel: case 1,5: i/o addr = 0xf880, size = 0x80 > Nov 11 15:28:23 shane /kernel: mapreg[10] type=1 addr=0000f880 size=0080. > Nov 11 15:28:23 shane /kernel: map = 0xffbdef80, data = 0xffffff80 > Nov 11 15:28:23 shane /kernel: case 0,2,4: i/o addr = 0xffbdef80, size = 0x80 > Nov 11 15:28:23 shane /kernel: mapreg[14] type=0 addr=ffbdef80 size=0080. > Nov 11 15:28:23 shane /kernel: map = 0x500a1011, data = 0x500a1011 > Nov 11 15:28:23 shane /kernel: case 1,5: i/o addr = 0x500a1010, size = 0x10 > Nov 11 15:28:23 shane /kernel: mapreg[2c] type=1 addr=500a1010 size=0010. Hmmm, that one is interesting, too: This is the subvendor data register, and your card is the first one I see has that register implemented and set to a value not equal 0. > Nov 11 15:28:24 shane /kernel: map = 0xffb40000, data = 0xfffc0001 > Nov 11 15:28:24 shane /kernel: case 1,5: i/o addr = 0xffb40000, size = 0x40000 > Nov 11 15:28:24 shane /kernel: mapreg[30] type=0 addr=ffb40000 size=40000. > Nov 11 15:28:24 shane /kernel: reg16: ioaddr=0xf880 size=0x80 Ok, the rest just repeated, what we already know: On your system, the probe for PCI map registers (which should be limited to the range 0x10 to 0x24 (+3)) does not stop when it has completed looking at the defined registers. And it does bad things, when it walks over all the higher numbered registers and writes a 0xffffffff probe value into them ! Please check why this happens on your system. I can't reprocuce it here ... Regards, STefan From owner-freebsd-hackers Tue Nov 12 12:39:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA25646 for hackers-outgoing; Tue, 12 Nov 1996 12:39:29 -0800 (PST) Received: from babs.netgazer.net (babs.netgazer.net [208.12.177.9]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA25635 for ; Tue, 12 Nov 1996 12:39:24 -0800 (PST) Received: from [208.12.177.224] (furball.netgazer.com [208.12.177.224]) by babs.netgazer.net (8.7.5/8.7.3) with ESMTP id OAA03126 for ; Tue, 12 Nov 1996 14:42:17 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 14:42:28 -0600 To: freebsd-hackers@freebsd.org From: "Darrin R. Woods" Subject: compiling and running inn Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have been trying for two days to get inn running on one of my servers and have run into one problem after another. When I do a make I get the following error after all the files have been downloaded via ftp: ===> Configuring for inn-1.4 echo "-O" >/tmp/build-ports-news-inn-cflags cc -o subst subst.c subst.c: In function `xstrerror': subst.c:53: conflicting types for `sys_errlist' /usr/include/stdio.h:244: previous declaration of `sys_errlist' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. This is really eating my lunch and I need to get this up and running. Since I'm not a code-warrier, I'm kinda lost here. This is running on a P166, 64mb ram, 128mb swap, 12gb disk with FreeBSD 2.1.5 Any and all help appreciated. Darrin R. Woods | dwoods@netgazer.com Director | Netgazer Solutions, Inc. | http://www.netgazer.net Dallas, Texas | My employer most whole-heartedly denies everything I say From owner-freebsd-hackers Tue Nov 12 12:49:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA26306 for hackers-outgoing; Tue, 12 Nov 1996 12:49:02 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA26283; Tue, 12 Nov 1996 12:48:57 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA22023; Tue, 12 Nov 1996 14:48:26 -0600 From: Joe Greco Message-Id: <199611122048.OAA22023@brasil.moneng.mei.com> Subject: sol.net problems To: hubs@freebsd.org Date: Tue, 12 Nov 1996 14:48:25 -0600 (CST) Cc: hackers@freebsd.org, isp@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, My core router (FreeBSD 2.1.0R, half a dozen Ethernet cards, etc) has been blowing chunks since late morning. A workaround will be in place by 18:00 CST until the machine can be replaced or repaired. A gross hack is currently providing connectivity to my services network, where {ftp,mail}.freebsd.sol.net live, but any other services may be temporarily interrupted until this problem is corrected. The problem is compounded by the fact that I am not able to get down to the office until after 17:00 CST. My apologies. This brings up a side issue. I have been talking for months about building in more redundancy to my networking infrastructure. With Ethernet stuff being dirt cheap, there is no reason for this kind of thing... I am seriously intending to start running redundant Ethernets and stuff to all key systems. I believe that if I start using OSPF internally, this should be practical and possible, but I am no GateD whiz, and I don't know how to go about this. I did buy "Routing in the Internet" but haven't made a serious dent in trying to understand the OSPF routing stuff yet. (Issues never come up at convenient times). What I would like to do, best case, is something like this... Net 206.55.64.0/28 Net 206.55.64.16/28 ---------- ---------- ---------- b |---| Router | ------------| Box 1 |------------ | Router |---| b b | ---------- / ---------- \ ---------- | b 1 | / \ | 2 | ----------/ ---------- \---------- | |---| Router |---------------| Box 2 |---------------| Router |---| | ---------- ---------- ---------- | Obviously not a complete net view... Right now, "Box 1" and "Box 2" are connected to a common ethernet which is in turn connected to my core router, which connects via my backbone Ethernet to a border router. What I would like to do is to set up a second core router... the obvious way is to simply connect it to the current "common ethernet" for Box 1 and Box 2. However, that does not protect against a failed hub or a bad wire. Running a separate wire from each core router to the box seems absurd at first until you realize it can be done with no hubs, and good hubs being rather pricey, this starts to look attractive. Any comments from OSPF gurus? ... JG From owner-freebsd-hackers Tue Nov 12 12:57:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA26718 for hackers-outgoing; Tue, 12 Nov 1996 12:57:34 -0800 (PST) Received: from pluto.plutotech.com (root@pluto.plutotech.com [206.168.67.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA26713 for ; Tue, 12 Nov 1996 12:57:28 -0800 (PST) Received: from shane.plutotech.com (durian@shane.plutotech.com [206.168.67.149]) by pluto.plutotech.com (8.8.2/8.8.2) with ESMTP id NAA04343; Tue, 12 Nov 1996 13:57:10 -0700 (MST) Message-Id: <199611122057.NAA04343@pluto.plutotech.com> From: "Mike Durian" To: se@zpr.uni-koeln.de (Stefan Esser) cc: freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-reply-to: Your message of "Tue, 12 Nov 1996 21:02:10 +0100." Date: Tue, 12 Nov 1996 13:57:09 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Nov 1996 21:02:10 +0100, se@zpr.uni-koeln.de (Stefan Esser) wrote: > >Thanks! And I think I found something interesting ... > >Could you please let me know the value of PCI_MAP_REG_END >that is defined in your version of /sys/pci/pcireg.h ? > >(It should be 0x28, in order to make the following for loop >do the right thing: You are absolutely right. For some reason mine was set to 0x34. I have no explaination for this. Either we made the change locally (and I have no idea why), or it was in the FreeBSD source tree at one point and we missed picking up the change during one of our imports. >Ok, the rest just repeated, what we already know: > >On your system, the probe for PCI map registers (which should be >limited to the range 0x10 to 0x24 (+3)) does not stop when it has >completed looking at the defined registers. And it does bad things, >when it walks over all the higher numbered registers and writes a >0xffffffff probe value into them ! > >Please check why this happens on your system. I can't reprocuce it >here ... It is just as your surmised. Thanks for your help, and sorry about the wild goose chase. As for the ROM on the adaptec being enabled, I'm not sure what to do about that. Isn't that a BIOS issue? I mean, shouldn't the BIOS have disabled it? mike From owner-freebsd-hackers Tue Nov 12 13:05:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27122 for hackers-outgoing; Tue, 12 Nov 1996 13:05:17 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA27106 for ; Tue, 12 Nov 1996 13:04:48 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-48.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA06194 (5.67b/IDA-1.5 for ); Tue, 12 Nov 1996 22:04:10 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id VAA26502; Tue, 12 Nov 1996 21:52:32 +0100 (MET) Message-Id: <199611122052.VAA26502@x14.mi.uni-koeln.de> Date: Tue, 12 Nov 1996 21:52:32 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: durian@plutotech.com (Mike Durian) Cc: se@zpr.uni-koeln.de (Stefan Esser), freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-Reply-To: <199611122057.NAA04343@pluto.plutotech.com>; from Mike Durian on Nov 12, 1996 13:57:09 -0700 References: <199611122057.NAA04343@pluto.plutotech.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike Durian writes: > > You are absolutely right. For some reason mine was set to 0x34. > I have no explaination for this. Either we made the change locally > (and I have no idea why), or it was in the FreeBSD source tree at > one point and we missed picking up the change during one of our > imports. Well, I'm sure it never was set to anything but 0x28 as the address of the first register beyond the map registers. (I even checked the CVS file ...) > As for the ROM on the adaptec being enabled, I'm not sure what to do > about that. Isn't that a BIOS issue? I mean, shouldn't the BIOS have > disabled it? It was disabled, but as part of the map information retrieval a value of 0xffffffff gets written to that register, which will enable the expansion ROM decode. But it was a false alarm anyway: The code will restore the old value of each map register at the end of the probe, and it will disbale the ROM at that point again. Regards, STefan From owner-freebsd-hackers Tue Nov 12 13:19:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27716 for hackers-outgoing; Tue, 12 Nov 1996 13:19:59 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA27711 for ; Tue, 12 Nov 1996 13:19:54 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA22113; Tue, 12 Nov 1996 15:18:46 -0600 From: Joe Greco Message-Id: <199611122118.PAA22113@brasil.moneng.mei.com> Subject: Re: compiling and running inn To: dwoods@netgazer.com (Darrin R. Woods) Date: Tue, 12 Nov 1996 15:18:46 -0600 (CST) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Darrin R. Woods" at Nov 12, 96 02:42:28 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello Darrin, I don't know too much about the ports version of INN, but I can tell you that you can probably go into the INN source directory, and type sh BUILD and then tell it to use the "sh" version of subst. But I have not seen this even using the C version of subst... hmm. ... JG > I have been trying for two days to get inn running on one of my servers and > have run into one problem after another. > > When I do a make I get the following error after all the files have been > downloaded via ftp: > > ===> Configuring for inn-1.4 > echo "-O" >/tmp/build-ports-news-inn-cflags > cc -o subst subst.c > subst.c: In function `xstrerror': > subst.c:53: conflicting types for `sys_errlist' > /usr/include/stdio.h:244: previous declaration of `sys_errlist' > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > > This is really eating my lunch and I need to get this up and running. > Since I'm not a code-warrier, I'm kinda lost here. > > This is running on a P166, 64mb ram, 128mb swap, 12gb disk with FreeBSD 2.1.5 > > Any and all help appreciated. > > > Darrin R. Woods | dwoods@netgazer.com > Director | > Netgazer Solutions, Inc. | http://www.netgazer.net > Dallas, Texas | > > My employer most whole-heartedly denies everything I say > > > From owner-freebsd-hackers Tue Nov 12 13:21:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27854 for hackers-outgoing; Tue, 12 Nov 1996 13:21:03 -0800 (PST) Received: from pluto.plutotech.com (root@pluto.plutotech.com [206.168.67.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA27849 for ; Tue, 12 Nov 1996 13:20:59 -0800 (PST) Received: from shane.plutotech.com (durian@shane.plutotech.com [206.168.67.149]) by pluto.plutotech.com (8.8.2/8.8.2) with ESMTP id OAA04654; Tue, 12 Nov 1996 14:20:04 -0700 (MST) Message-Id: <199611122120.OAA04654@pluto.plutotech.com> From: "Mike Durian" To: se@zpr.uni-koeln.de (Stefan Esser) cc: freebsd-hackers@freebsd.org Subject: Re: small bugs in pci code In-reply-to: Your message of "Tue, 12 Nov 1996 21:52:32 +0100." Date: Tue, 12 Nov 1996 14:20:03 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Nov 1996 21:52:32 +0100, se@zpr.uni-koeln.de (Stefan Esser) wrote: > >Well, I'm sure it never was set to anything but 0x28 as the >address of the first register beyond the map registers. >(I even checked the CVS file ...) I've tracked it down. We did change it because it limited the registers that could be mapped with pci_map_mem. We need to be able to read and write (reprogram) our adaptecs' seeproms. To do this, we map in the eeprom memory and thus need to work around the pci_map_mem restriction. We never realized (or even noticed until now) the ramifications of changing the PCI_MAP_REG_END value. Thanks for showing us the error of our ways. >But it was a false alarm anyway: The code will restore the old >value of each map register at the end of the probe, and it will >disbale the ROM at that point again. And it looks like we go and re-enable it later. Sigh. I need to talk to some people about this. mike From owner-freebsd-hackers Tue Nov 12 15:10:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA03078 for hackers-outgoing; Tue, 12 Nov 1996 15:10:16 -0800 (PST) Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA03029 for ; Tue, 12 Nov 1996 15:09:46 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 12 Nov 1996 16:07:07 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 12 Nov 1996 16:06:19 -0700 From: Darren Davis To: hackers@freebsd.org Subject: Novell offers free NDS, just a thought... Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Novell Removes the Barriers for Widespread Adoption of Directory Services for Networks Novell Offers Feature Rich LDAP Directory Server Free of Charge OREM, Utah C November 12, 1996 C Novell Inc. today announced an aggressive distribution strategy for Novell Directory Services (NDS) to accelerate its adoption by the industryAEs leading operating system vendors, creating a common directory service across heterogenous environments. Starting immediately, operating system developers can obtain a royalty-free source code and distribution license for NDS. Novell also disclosed its plans to offer a royalty-free binary distribution license for NDS on NT. As a cross-platform directory service, NDS provides a single point of access and management, increasing user productivity, reducing network administration costs and easing application development. In parallel with the new distribution strategy, Novell and its partners are creating new businesses through the licensing of replication, file, print, certificates and other directory-based products as add-ons to NDS. ANDS is years ahead of other directories in terms of technology and market share,@ said Tom Arthur, vice president and general manager of NovellAEs Internet Infrastructure Division. ANovell understands that the value of a network directory depends on the extent of its adoption. While other vendors are hoping to make a business of selling directories as servers or embedding them in proprietary operating systems, Novell is taking a different approach and seeding the market with NDS for directory-based applications and services.@ Novell is committed to integrating NDS into all major server platforms. The company has taken the first step by allowing the NDS source code to be licensed by industry-leading operating system providers, royalty-free. The company will also distribute a single server binary version of NDS on NT over the Internet and through agreements with independent software vendors (ISVs) and independent hardware vendors (IHVs). Partnerships with major ISVs and IHVs will be announced over the next several months. Customer Benefits NovellAEs platform-independent directory strategy will significantly increase user productivity by making it easier to find information on the network, regardless of where the information resides (corporate networks, intranets and the Internet). The directory will also help administrators to decrease network administration costs by reducing the time and complexity of managing disparate corporate networks. AAs one of the worldAEs largest network integrators we have been providing NDS solutions in the NetWare environment for many years,@ said Stan Ratcliffe, vice president of EDSAE Client/Server Group. AWe are very encouraged to see that NDS is becoming widely available on Unix and NT, thus providing simpler access, administration and development for heterogeneous networking systems.@ AThe availability of NDS on multiple operating systems gives us an opportunity that weAEve never had before to merge disparate platforms in our company under a single directory service,@ said Lee Roth, LAN Systems group leader, Southwest Airlines. NDS is an Open Directory By basing NDS on X.500 naming, Novell anticipated the industryAEs adoption of industry standards thus allowing NDS to be one of the first directories to offer LDAP support. To further its commitment to open standards, Novell plans to open NDS access APIs to Internet/intranet standards and ruling committees. The API documentation for NDS, including all of the directory service APIs for both client and service facilities are openly available on NovellAEs Web site at Developer Benefits Developers will finally be able to exploit new market opportunities by creating networked applications that leverage the performance benefits of distributed computing. NDS enables networked applications to share objects, such as Java applets, across networks, including intranets and the Internet. NovellAEs plans to openly distribute NDS, and its commitment to LDAP and X.500, offer a compelling, open environment for developing directory-enabled applications. Novell is also offering developers the opportunity to bundle NDS with their applications. This will provide the administration and security features they require, thus reducing the time and expense to develop and implement user account databases. With its directory services strategy, Novell provides a common directory infrastructure for developers to incorporate LDAP-compliant directory services into their networked applications and solutions, paving the way for developers to designate NDS as the LDAP directory of choice. Novell is (NASDAQ:NOVL) is the worldAEs leading network software provider. Novell software provides the infrastructure for a networked world, enabling customers to connect with other people and the information they need, anytime and anyplace. Novell partners with other technology and market leaders to help customers make networks a part of their everyday lives. ### Novell is a registered trademark. Novell Directory Services, NDS are trademarks of Novell, Inc. All other registered trademarks are the property of their respective holders. Press Contact: Pattie Adams, Novell, Inc. Lori Hafen, Cunningham Communication, Inc. (408) 577-6056 (408) 764-0787 Internet: padams@novell.com Internet: lori@ccipr.com From owner-freebsd-hackers Tue Nov 12 16:04:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA05534 for hackers-outgoing; Tue, 12 Nov 1996 16:04:22 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA05493 for ; Tue, 12 Nov 1996 16:03:59 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id QAA29413 for ; Tue, 12 Nov 1996 16:04:01 -0800 (PST) To: hackers@freebsd.org Subject: Is our ASYNC I/O support for ttys broken? Date: Tue, 12 Nov 1996 16:04:01 -0800 Message-ID: <29402.847843441@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thomas Roell over at X Inside just sent me this little snippet, complaining that ASYNC I/O was broken in FreeBSD where it worked with Linux and SVR4. Any comments? #include #include #include #include int fd; void signal_handler( int signo ) { char buf[64]; printf("bazoing %d\n", read(fd, buf, sizeof(buf))); } main() { struct sigaction sa; sa.sa_handler = signal_handler; sa.sa_flags = SA_RESTART; sigemptyset(&sa.sa_mask); sigaction(SIGIO, &sa, NULL); fd = open("/dev/ttyd0", O_RDONLY | O_NONBLOCK); fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | FASYNC); fcntl(fd, F_SETOWN, getpid()); for (;;) { sleep(10000); } } And yes indeed, the signal handler never goes off when you're trying to talk to a standard TTY device. I changed the /dev/ttyd0 in the example to /dev/cuaa1, which is where my mouse is (and from which I can provably read data with cat) and the signal handler was never called. Jordan From owner-freebsd-hackers Tue Nov 12 16:15:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA06083 for hackers-outgoing; Tue, 12 Nov 1996 16:15:36 -0800 (PST) Received: from tahoma.cwu.edu (skynyrd@tahoma.cwu.edu [198.104.65.220]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA06071 for ; Tue, 12 Nov 1996 16:15:19 -0800 (PST) Received: by tahoma.cwu.edu; id AA23701; Tue, 12 Nov 1996 16:15:10 -0800 Date: Tue, 12 Nov 1996 16:15:10 -0800 (PST) From: Chris Timmons To: FreeBSD Acct Cc: hackers@FreeBSD.org Subject: Re: Trafshow In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Yes; trafshow does not understand the link layer encapsulation of the fddi packets. Have a look at the appropriate code from tcpdump for doing this; it probably wouldn't take very long to get trafshow working. (On my list to do at some point...) -Chris On Tue, 12 Nov 1996, FreeBSD Acct wrote: > Has anyone a clue why trafshow will not use my fpa0 device. > > It seems not to support it. > From owner-freebsd-hackers Tue Nov 12 16:46:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09312 for hackers-outgoing; Tue, 12 Nov 1996 16:46:27 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA09292 for ; Tue, 12 Nov 1996 16:46:18 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id TAA18092 for ; Tue, 12 Nov 1996 19:45:09 -0500 (EST) Date: Tue, 12 Nov 1996 19:45:09 -0500 (EST) From: Mark Mayo To: hackers@freebsd.org Subject: NCR 53c810 -> Where can I get them now? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just asked a local shop for an NCR 53c810 SCSI controller to replace a friend's IDE crap. The shop got back to me and informed me that NCR had been bought out by Symbios Logic, who were in turn bought out by AT&T (which I was aware of) and he couldn't find anyone to sell him this controller!! Anyone know of any other manufacturers (Kingston or someone perhaps) that used the NCR chipset and have an on board bios so my friend can boot of a scsi drive? Or do I have to go Adaptec 2940.... TIA, -mark --------------------------------------------------- | Mark Mayo mark@quickweb.com | | RingZero Comp. vinyl.quickweb.com/mark | --------------------------------------------------- "To iterate is human, to recurse divine." - L. Peter Deutsch From owner-freebsd-hackers Tue Nov 12 17:10:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA15828 for hackers-outgoing; Tue, 12 Nov 1996 17:10:27 -0800 (PST) Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA15809; Tue, 12 Nov 1996 17:10:18 -0800 (PST) Received: from base.jnx.com (base.jnx.com [208.197.169.238]) by red.jnx.com (8.7.6/8.7.3) with ESMTP id RAA14659; Tue, 12 Nov 1996 17:07:54 -0800 (PST) Received: (from pst@localhost) by base.jnx.com (8.7.6/8.7.3) id RAA14152; Tue, 12 Nov 1996 17:07:47 -0800 (PST) To: jgreco@brasil.moneng.mei.com (Joe Greco) Cc: stesin@gu.net (Andrew Stesin), john@starfire.mn.org, hackers@FreeBSD.org, freebsd-isp@FreeBSD.org Subject: Re: PPP/LCP sensing getty References: <199611112219.QAA19987@brasil.moneng.mei.com> From: Paul Traina Date: 12 Nov 1996 17:07:46 -0800 In-Reply-To: jgreco@brasil.moneng.mei.com's message of 11 Nov 96 22:19:21 GMT Message-ID: <7ysp6eyf8d.fsf@base.jnx.com> Lines: 10 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk jgreco@brasil.moneng.mei.com (Joe Greco) writes: > ftp://ftp.freebsd.sol.net/incoming/pppgetty.tar.gz for source > mods, this you will have to figure out yourself (shouldn't be too > hard). Ask and you shall receive. Just committed to -current. I haven't committed ppplogin yet, since it appears as if pppd can handle this directly under certain circumstances... From owner-freebsd-hackers Tue Nov 12 17:20:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA16373 for hackers-outgoing; Tue, 12 Nov 1996 17:20:22 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA16368 for ; Tue, 12 Nov 1996 17:20:20 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id RAA18362; Tue, 12 Nov 1996 17:19:45 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma018360; Tue Nov 12 17:19:43 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id RAA08629; Tue, 12 Nov 1996 17:19:42 -0800 (PST) From: Archie Cobbs Message-Id: <199611130119.RAA08629@bubba.whistle.com> Subject: kernel and/or fsck(8) bug To: freebsd-hackers@freebsd.org Date: Tue, 12 Nov 1996 17:19:41 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello We encountered an interesting situation where the superblock for a file system got written to disk with the "fs_fmod" flag set to one. It appears that this flag is normally supposed to be cleared during ffs_sync(), but we experienced a crash, or some other weird occurrence that left it on the disk set to 1. Later this partition was mounted read-only... and the fs_fmod field was never cleared, causing ffs_sync() to panic "rofs mod" when trying to unmount that filesystem (ffs_vfsops.c: line 790). Observation #1: As far as I can tell, the meaning of this field is ``this copy of the superblock has been modified from the real one on the disk.'' Therefore, the value of this field **in the actual superblock on the disk** should either: (a) ALWAYS be zero, in which case fsck(8) should be responsible for checking/fixing it; or (b) ALWAYS be ignored, in which case every time the superblock is read from disk this field should be set to zero. Observation #2: Currently, the only place this field is actually *used* for anything is to detect this panic condition. Presumably there is some intended future use for it; if not, it should just be taken out! Below are patches for both (a) and (b), either of which should (hopefully) address the problem. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com FSCK PATCH: Index: pass5.c =================================================================== RCS file: /cvs/freebsd/src/sbin/fsck/pass5.c,v retrieving revision 1.5 diff -c -r1.5 pass5.c *** 1.5 1995/05/30 06:09:06 --- pass5.c 1996/11/13 01:05:39 *************** *** 318,323 **** --- 318,332 ---- fs->fs_fmod = 0; sbdirty(); } + if (fs->fs_fmod != 0) { + pwarn("MODIFIED FLAG SET IN SUPERBLOCK"); + if (preen) + printf(" (FIXED)\n"); + if (preen || reply("FIX") == 1) { + fs->fs_fmod = 0; + sbdirty(); + } + } if (fs->fs_clean == 0) { pwarn("CLEAN FLAG NOT SET IN SUPERBLOCK"); if (preen) KERNEL PATCH: Index: ffs_vfsops.c =================================================================== RCS file: /cvs/freebsd/src/sys/ufs/ffs/ffs_vfsops.c,v retrieving revision 1.41 diff -c -r1.41 ffs_vfsops.c *** 1.41 1996/09/07 17:34:57 --- ffs_vfsops.c 1996/11/13 01:06:25 *************** *** 383,388 **** --- 383,389 ---- if (error) return (error); fs = (struct fs *)bp->b_data; + fs->fs_fmod = 0; if (fs->fs_magic != FS_MAGIC || fs->fs_bsize > MAXBSIZE || fs->fs_bsize < sizeof(struct fs)) { brelse(bp); *************** *** 506,511 **** --- 507,513 ---- if (error) goto out; fs = (struct fs *)bp->b_data; + fs->fs_fmod = 0; if (fs->fs_magic != FS_MAGIC || fs->fs_bsize > MAXBSIZE || fs->fs_bsize < sizeof(struct fs)) { error = EINVAL; /* XXX needs translation */ From owner-freebsd-hackers Tue Nov 12 17:41:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA17355 for hackers-outgoing; Tue, 12 Nov 1996 17:41:52 -0800 (PST) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA17343 for ; Tue, 12 Nov 1996 17:41:47 -0800 (PST) Received: from thurston.eng.umd.edu (thurston.eng.umd.edu [129.2.103.25]) by po2.glue.umd.edu (8.8.2/8.7.3) with ESMTP id UAA15966; Tue, 12 Nov 1996 20:41:41 -0500 (EST) Received: from localhost (chuckr@localhost) by thurston.eng.umd.edu (8.7.5/8.7.3) with SMTP id UAA15037; Tue, 12 Nov 1996 20:41:40 -0500 (EST) X-Authentication-Warning: thurston.eng.umd.edu: chuckr owned process doing -bs Date: Tue, 12 Nov 1996 20:41:40 -0500 (EST) From: Chuck Robey X-Sender: chuckr@thurston.eng.umd.edu To: Mark Mayo cc: hackers@FreeBSD.org Subject: Re: NCR 53c810 -> Where can I get them now? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Nov 1996, Mark Mayo wrote: > I just asked a local shop for an NCR 53c810 SCSI controller to replace a > friend's IDE crap. The shop got back to me and informed me that NCR had > been bought out by Symbios Logic, who were in turn bought out by AT&T > (which I was aware of) and he couldn't find anyone to sell him this > controller!! > > Anyone know of any other manufacturers (Kingston or someone perhaps) that > used the NCR chipset and have an on board bios so my friend can boot of a > scsi drive? Or do I have to go Adaptec 2940.... I got the same story when I went to get my new system. I wanted another of the Tyan controllers, based on the NCR825, and I was told they were going to be phased out in favor of a new, much more expensive 875 based system that Tyan didn't even (and still doesn't) have announced yet. I went looking around some more, and found the Tyan 825 based one available still from a place that specializes in BSDI systems, in Calif, called Telenet Systems Solutions, (408) 383-0334. They charged me $105 for it, very reasonable, very friendly, and they seemed to know what they were doing. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Tue Nov 12 17:54:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA18042 for hackers-outgoing; Tue, 12 Nov 1996 17:54:44 -0800 (PST) Received: from nexgen.n4hhe.ampr.org (max7-69.HiWAAY.net [206.104.17.69]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA18035 for ; Tue, 12 Nov 1996 17:54:35 -0800 (PST) Received: (from dkelly@localhost) by nexgen.n4hhe.ampr.org (8.7.5/8.7.3) id TAA02947; Tue, 12 Nov 1996 19:54:24 -0600 (CST) Message-ID: X-Mailer: XFMail 0.5-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 12 Nov 1996 19:51:55 -0600 (CST) Organization: Amateur Radio N4HHE, Madison, AL. From: David Kelly To: Mark Mayo Subject: RE: NCR 53c810 -> Where can I get them now? Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 01:45:09 Mark Mayo wrote: >>I just asked a local shop for an NCR 53c810 SCSI controller to replace a >friend's IDE crap. The shop got back to me and informed me that NCR had >been bought out by Symbios Logic, who were in turn bought out by AT&T >(which I was aware of) and he couldn't find anyone to sell him this >controller!! http://www.symbios.com/aboutsym/history.htm says: A RICH HERITAGE Our name is new, but at Symbios Logic, our history spans nearly a quarter-century. Symbios Logic Inc. is a wholly owned,independently operated subsidiary of Hyundai Electronics America (HEA) and was established on February 15, 1995, with HEA's purchase of the Company from AT&T Global Information Solutions Co. >Anyone know of any other manufacturers (Kingston or someone perhaps) that >used the NCR chipset and have an on board bios so my friend can boot of a >scsi drive? Or do I have to go Adaptec 2940.... Either or both Asus and Tyan offer PCI SCSI cards with the Symbios chips. Might browse around the above site and find others. -- David Kelly N4HHE, dkelly@tomcat1.tbe.com (wk), dkelly@hiwaay.net (hm) ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Tue Nov 12 18:50:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA20315 for hackers-outgoing; Tue, 12 Nov 1996 18:50:48 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA20310 for ; Tue, 12 Nov 1996 18:50:44 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA05437; Tue, 12 Nov 1996 21:50:06 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 12 Nov 1996 21:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id UAA29450; Tue, 12 Nov 1996 20:41:51 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id UAA16800; Tue, 12 Nov 1996 20:43:19 -0500 (EST) Date: Tue, 12 Nov 1996 20:43:19 -0500 (EST) From: Thomas David Rivers Message-Id: <199611130143.UAA16800@lakes.water.net> To: ponds!freefall.freebsd.org!dyson, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lambert.org!terry Subject: Even more info on daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - just a status update... It's now been 5+ days since I installed the kernel with the vrele() panic and Terry's other vfs_subr.c fix... The machine has yet to panic, at all...: ponds# uptime 8:31PM up 5 days, 7:34, 1 user, load averages: 0.33, 0.55, 0.60 At this point, my only explanation is that I must have installed the wrong kernel when originally testing Terry's change to vfs_subr.c; and, in fact, Terry's suggested change to not walk around the end of the list is the reason for the success I'm having. It seems to me it couldn't have been the other change to vrele() which is simply to add some consistency checks that weren't present before. I'd like to ensure this improvement makes it into 2.1.6... (I believe it's already in -current.) Who do I talk to for that? - Dave Rivers - From owner-freebsd-hackers Tue Nov 12 20:52:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA24469 for hackers-outgoing; Tue, 12 Nov 1996 20:52:32 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA24458 for ; Tue, 12 Nov 1996 20:52:22 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id EAA11364; Wed, 13 Nov 1996 04:52:14 GMT Date: Wed, 13 Nov 1996 13:52:14 +0900 (JST) From: Michael Hancock To: Thomas David Rivers cc: FreeBSD Hackers Subject: Re: Even more info on daily panics... In-Reply-To: <199611130143.UAA16800@lakes.water.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk IMHO, it's not good to speculate. You need to confirm with absolute certainty that the patch is what actually fixed it. You might want to do either of the following: 1) Remove the patch and see if what happens. 2) Put in print statements and see if the relevent section of code ever gets executed. See other #ifdef DIAGNOSTICS for examples of how to do this. I think vrele() had one. Regards, Mike Hancock On Tue, 12 Nov 1996, Thomas David Rivers wrote: > > Well - just a status update... > > It's now been 5+ days since I installed the kernel with > the vrele() panic and Terry's other vfs_subr.c fix... > > The machine has yet to panic, at all...: > > ponds# uptime > 8:31PM up 5 days, 7:34, 1 user, load averages: 0.33, 0.55, 0.60 > > At this point, my only explanation is that I must have > installed the wrong kernel when originally testing Terry's > change to vfs_subr.c; and, in fact, Terry's suggested change > to not walk around the end of the list is the reason for > the success I'm having. It seems to me it couldn't have > been the other change to vrele() which is simply to add > some consistency checks that weren't present before. > > I'd like to ensure this improvement makes it into 2.1.6... (I believe > it's already in -current.) Who do I talk to for that? > > - Dave Rivers - > From owner-freebsd-hackers Tue Nov 12 21:05:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA25026 for hackers-outgoing; Tue, 12 Nov 1996 21:05:54 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA25017 for ; Tue, 12 Nov 1996 21:05:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id VAA07192; Tue, 12 Nov 1996 21:04:57 -0800 (PST) Message-Id: <199611130504.VAA07192@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Hancock cc: Thomas David Rivers , FreeBSD Hackers Subject: Re: Even more info on daily panics... In-reply-to: Your message of "Wed, 13 Nov 1996 13:52:14 +0900." From: David Greenman Reply-To: dg@root.com Date: Tue, 12 Nov 1996 21:04:57 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >IMHO, it's not good to speculate. You need to confirm with absolute >certainty that the patch is what actually fixed it. > >You might want to do either of the following: > >1) Remove the patch and see if what happens. > >2) Put in print statements and see if the relevent section of code ever >gets executed. See other #ifdef DIAGNOSTICS for examples of how to do >this. I think vrele() had one. I would also like to hear an explaination of how it is possible, after the patch to vrele to prevent it from going negative, for a vnode with a non-zero v_usecount can be on the freelist in the first place. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Nov 12 22:03:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA27216 for hackers-outgoing; Tue, 12 Nov 1996 22:03:47 -0800 (PST) Received: from lithuania.it.earthlink.net (lithuania-c.it.earthlink.net [204.250.46.58]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA27199; Tue, 12 Nov 1996 22:03:43 -0800 (PST) Received: from default (max1-800-21.earthlink.net [206.149.205.22]) by lithuania.it.earthlink.net (8.7.5/8.7.3) with SMTP id VAA10274; Tue, 12 Nov 1996 21:53:48 -0800 (PST) Message-ID: <3289605F.325@earthlink.net> Date: Tue, 12 Nov 1996 21:45:03 -0800 From: Steven Swanson X-Mailer: Mozilla 2.0 (Win95; U) MIME-Version: 1.0 To: ziggy69@earthlink.net CC: Joe Greco , Andrew Stesin , john@starfire.mn.org, hackers@FreeBSD.org, freebsd-isp@FreeBSD.org Subject: Re: PPP/LCP sensing getty References: <199611112219.QAA19987@brasil.moneng.mei.com> <7ysp6eyf8d.fsf@base.jnx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Paul Traina wrote: > > jgreco@brasil.moneng.mei.com (Joe Greco) writes: > > > ftp://ftp.freebsd.sol.net/incoming/pppgetty.tar.gz for source > > mods, this you will have to figure out yourself (shouldn't be too > > hard). > > Ask and you shall receive. Just committed to -current. I haven't > committed ppplogin yet, since it appears as if pppd can handle this > directly under certain circumstances...Please remove me from your mailing lists. Thank you From owner-freebsd-hackers Tue Nov 12 23:37:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA00219 for hackers-outgoing; Tue, 12 Nov 1996 23:37:35 -0800 (PST) Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA00214 for ; Tue, 12 Nov 1996 23:37:25 -0800 (PST) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.8.2/Sogang) id QAA28449; Wed, 13 Nov 1996 16:32:00 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA04463; Wed, 13 Nov 96 16:35:32 KST From: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Message-Id: <9611130735.AA04463@cslsun10.sogang.ac.kr> Subject: memory management To: freebsd-hackers@FreeBSD.ORG Date: Wed, 13 Nov 1996 16:35:31 +0900 (KST) Cc: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk yes. i have some a question about memory management. in /usr/src/sys/vm/vm_page.c is the function vm_page_startup() memory allocation per one process or per all system memory. and send me a good answer. i s From owner-freebsd-hackers Tue Nov 12 23:40:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA00407 for hackers-outgoing; Tue, 12 Nov 1996 23:40:15 -0800 (PST) Received: from nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA00398 for ; Tue, 12 Nov 1996 23:40:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id XAA24630 for ; Tue, 12 Nov 1996 23:38:38 -0800 (PST) Date: Tue, 12 Nov 1996 23:38:38 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: FreeBSD Hackers Subject: ypserv not reloading passwd database Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... when I change my NIS passwd ypserv does not reload the new password until I manually send the HUP signal to ypserv... this is a 960801-SNAP system running the ypserv from current... thanks for your help... and I hope I have provided enough info... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Wed Nov 13 00:22:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA02301 for hackers-outgoing; Wed, 13 Nov 1996 00:22:06 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA02294 for ; Wed, 13 Nov 1996 00:21:55 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id TAA28631; Wed, 13 Nov 1996 19:16:18 +1100 Date: Wed, 13 Nov 1996 19:16:18 +1100 From: Bruce Evans Message-Id: <199611130816.TAA28631@godzilla.zeta.org.au> To: hackers@freebsd.org, jkh@time.cdrom.com Subject: Re: Is our ASYNC I/O support for ttys broken? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Thomas Roell over at X Inside just sent me this little snippet, >complaining that ASYNC I/O was broken in FreeBSD where it worked with >Linux and SVR4. Any comments? The status hasn't changed since he complained a year or so ago. SIGIO for ASYNC tty i/o is only sent to the process group of the tty, and process group stuff is limited by it being POSIX conformant with few extensions - the process group can not be changed using F_SETOWN (although F_SETOWN takes you outside of POSIX) unless the corresponding change using tcsetpgrp() would work. SIGIO for ASYNC socket i/o works better because the process or process group of the socket, and this is unrelated to the POSIX process group. > fd = open("/dev/ttyd0", O_RDONLY | O_NONBLOCK); > > fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | FASYNC); > fcntl(fd, F_SETOWN, getpid()); The second fcntl is guaranteed to fail, since `fd' isn't a controlling terminal. To make fd a controlling terminal, something like the following must be done: fork() wait in parent, continue as follows in child: setsid(); /* become a session leader with no ctty */ open as above first fcntl as above ioctl(fd, TIOCSCTTY, NULL); /* make fd the ctty */ second fcntl as above Bruce From owner-freebsd-hackers Wed Nov 13 01:40:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA04965 for hackers-outgoing; Wed, 13 Nov 1996 01:40:13 -0800 (PST) Received: from whale.gu.kiev.ua ([194.93.190.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA04891; Wed, 13 Nov 1996 01:39:58 -0800 (PST) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [194.93.190.3]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id LAA36994; Wed, 13 Nov 1996 11:37:57 +0200 Date: Wed, 13 Nov 1996 11:37:56 +0200 (EET) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: Paul Traina cc: Joe Greco , john@starfire.mn.org, hackers@FreeBSD.org, freebsd-isp@FreeBSD.org Subject: Re: PPP/LCP sensing getty In-Reply-To: <7ysp6eyf8d.fsf@base.jnx.com> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Thanks a bunch! On 12 Nov 1996, Paul Traina wrote: > Ask and you shall receive. Just committed to -current. [...] -- Best, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Wed Nov 13 02:06:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA06130 for hackers-outgoing; Wed, 13 Nov 1996 02:06:38 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA06122 for ; Wed, 13 Nov 1996 02:06:32 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id CAA16179; Wed, 13 Nov 1996 02:06:20 -0800 (PST) To: Chuck Robey cc: Mark Mayo , hackers@FreeBSD.org Subject: Re: NCR 53c810 -> Where can I get them now? In-reply-to: Your message of "Tue, 12 Nov 1996 20:41:40 EST." Date: Wed, 13 Nov 1996 02:06:19 -0800 Message-ID: <16177.847879579@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > went looking around some more, and found the Tyan 825 based one available > still from a place that specializes in BSDI systems, in Calif, called > Telenet Systems Solutions, (408) 383-0334. They charged me $105 for it, > very reasonable, very friendly, and they seemed to know what they were > doing. Just to back up this endorsement - Telenet Systems is run by Billy Bath, formerly of ASA Computers, and one of the few places in silicon valley who really understand BSDI/FreeBSD systems (I've been working with Billy for the last couple of months getting him up to speed on building FreeBSD boxes). Paul Vixie has been getting his custom BSDI boxes from Billy for years now, and swears by him, so I've been quite keen to get Telenet into the FreeBSD business. I believe he's ramped up and ready to go now, though I'm still waiting for him to submit a commercial entry for our web pages. :-) Jordan From owner-freebsd-hackers Wed Nov 13 02:32:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA07048 for hackers-outgoing; Wed, 13 Nov 1996 02:32:48 -0800 (PST) Received: from whale.gu.kiev.ua ([194.93.190.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA07039 for ; Wed, 13 Nov 1996 02:32:41 -0800 (PST) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [194.93.190.3]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id MAA39434; Wed, 13 Nov 1996 12:32:34 +0200 Date: Wed, 13 Nov 1996 12:32:33 +0200 (EET) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: hackers@freebsd.org cc: squid-users@nlanr.net Subject: Programming technique for non-forking servers? In-Reply-To: <199611130952.JAA17498@corp.netcom.net.uk> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello people, can anyone point me to some book, or URL(s), where the programming technique for writing non-forking network server daemons is described in details? with caveats, non-obvious places... I mean those like Squid, Harvest cached, probably Gated (there is also a non-forking WWW server somewhere, but I forgot it's name, for a pity). AFAIK they are written around a huge select(), and are using asynchronous I/O. Yes, there are sources, but I'd really like to read some general theory on the subject. Thanks in advanse! -- Best, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Wed Nov 13 05:25:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA16131 for hackers-outgoing; Wed, 13 Nov 1996 05:25:00 -0800 (PST) Received: from lenlen.mt.cs.keio.ac.jp (lenlen.mt.cs.keio.ac.jp [131.113.32.126]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA16120; Wed, 13 Nov 1996 05:24:46 -0800 (PST) Received: (from hosokawa@localhost) by lenlen.mt.cs.keio.ac.jp (8.7.6/8.7.3) id WAA24145; Wed, 13 Nov 1996 22:08:00 +0900 (JST) Date: Wed, 13 Nov 1996 22:08:00 +0900 (JST) Message-Id: <199611131308.WAA24145@lenlen.mt.cs.keio.ac.jp> To: mgessner@aristar.com Cc: hackers@FreeBSD.org, hardware@FreeBSD.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: Dell laptop problems In-Reply-To: Your message of Tue, 12 Nov 1996 08:24:27 -0500. <32887A8B.2781E494@aristar.com> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.19] 1995-07/21(Fri) Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <32887A8B.2781E494@aristar.com> mgessner@aristar.com writes: >> When I boot the machine, it runs SLOOOOOW (75Mhz Pentium). If I boot Default IRQ of zp driver is 10. Does your laptop have any inactive (it means a device not probed or used by FreeBSD) device that uses IRQ 10? -- HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp hosokawa@jp.FreeBSD.org WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html From owner-freebsd-hackers Wed Nov 13 05:53:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA17613 for hackers-outgoing; Wed, 13 Nov 1996 05:53:14 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA17606 for ; Wed, 13 Nov 1996 05:53:10 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id HAA05458; Wed, 13 Nov 1996 07:52:16 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma005443; Wed Nov 13 07:51:52 1996 Received: from jake.lodgenet.com (jake.lodgenet.com [10.0.11.30]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id HAA01823; Wed, 13 Nov 1996 07:52:09 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.8.2/8.6.12) with ESMTP id HAA09086; Wed, 13 Nov 1996 07:52:33 -0600 (CST) Message-Id: <199611131352.HAA09086@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Amancio Hasty cc: hackers@FreeBSD.org Subject: Re: Xing Streamworks Player In-reply-to: Your message of "Tue, 12 Nov 1996 11:58:05 PST." <199611121958.LAA02102@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 07:52:33 -0600 From: "Eric L. Hernes" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty writes: > >Cool, still no sign of the linux shared libraries to enable the Xing >player to work .... > I've seen it work with the latest linux_lib-2.1, except I made the following symlinks and ran /compat/linux/sbin/ldconfig (ttyp0@jake)$ pwd /compat/linux/usr/lib (ttyp0@jake)$ ls -l *so.26* lrwxr-xr-x 1 root wheel 16 Nov 13 07:50 libg++.so.26@ -> libg++.so.27.1.4 lrwxr-xr-x 1 root wheel 19 Nov 13 07:50 libstdc++.so.26@ -> libstdc++.so.27.1.4 It's probably not quite according to hoyle, but the windows come up, now if it'd just work through our firewall :( > > Cheers, > Amancio > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Wed Nov 13 05:58:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA17832 for hackers-outgoing; Wed, 13 Nov 1996 05:58:27 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA17814 for ; Wed, 13 Nov 1996 05:58:23 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id NAA14940; Wed, 13 Nov 1996 13:57:59 GMT Date: Wed, 13 Nov 1996 22:57:59 +0900 (JST) From: Michael Hancock To: "Jordan K. Hubbard" cc: Chuck Robey , Mark Mayo , hackers@freebsd.org Subject: Re: NCR 53c810 -> Where can I get them now? In-Reply-To: <16177.847879579@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 13 Nov 1996, Jordan K. Hubbard wrote: > > went looking around some more, and found the Tyan 825 based one available > > still from a place that specializes in BSDI systems, in Calif, called > > Telenet Systems Solutions, (408) 383-0334. They charged me $105 for it, > > very reasonable, very friendly, and they seemed to know what they were > > doing. > > Just to back up this endorsement - Telenet Systems is run by Billy > Bath, formerly of ASA Computers, and one of the few places in silicon > valley who really understand BSDI/FreeBSD systems (I've been working > with Billy for the last couple of months getting him up to speed on > building FreeBSD boxes). Paul Vixie has been getting his custom BSDI > boxes from Billy for years now, and swears by him, so I've been > quite keen to get Telenet into the FreeBSD business. I believe > he's ramped up and ready to go now, though I'm still waiting for > him to submit a commercial entry for our web pages. :-) > > Jordan YASP ... Hey, I use these guys too. A box configured for BSDI is a good fit for FreeBSD too. The only thing they weren't used to doing was using Adaptec SCSI adapters. Btw, Kedar at ASA Computers can do FreeBSD boxes too. Paul's investment in time working with these guys has made things real easy for BSD. Both companies have learned the importance of a good power supply and additional fans. Mike From owner-freebsd-hackers Wed Nov 13 06:03:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA18122 for hackers-outgoing; Wed, 13 Nov 1996 06:03:58 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA18117 for ; Wed, 13 Nov 1996 06:03:54 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA23116; Wed, 13 Nov 1996 08:02:48 -0600 From: Joe Greco Message-Id: <199611131402.IAA23116@brasil.moneng.mei.com> Subject: Re: NCR 53c810 -> Where can I get them now? To: mark@quickweb.com (Mark Mayo) Date: Wed, 13 Nov 1996 08:02:47 -0600 (CST) Cc: hackers@FreeBSD.org In-Reply-To: from "Mark Mayo" at Nov 12, 96 07:45:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I just asked a local shop for an NCR 53c810 SCSI controller to replace a > friend's IDE crap. The shop got back to me and informed me that NCR had > been bought out by Symbios Logic, who were in turn bought out by AT&T > (which I was aware of) and he couldn't find anyone to sell him this > controller!! > > Anyone know of any other manufacturers (Kingston or someone perhaps) that > used the NCR chipset and have an on board bios so my friend can boot of a > scsi drive? Or do I have to go Adaptec 2940.... You might wish to check to see if the MB already has support for the NCR built in... many do even though they do not advertise it. I think most MB's with Award BIOS'es tend to support it, from what I have seen and/or heard. If so, all you need is something like an ASUS SC-200 (highly recommended, they work GREAT!)... Rod Grimes at Accurate Automation, Inc. sells them for about $75.00. Some boards can also be "upgraded" to support the NCR in the on-board BIOS, I am thinking particularly of the Intel Endeavour boards. (The real solution is just to buy a decent MB which supports them in the first place, I have become convinced time and time again that ASUS is a good mfr of motherboards). ... JG From owner-freebsd-hackers Wed Nov 13 06:05:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA18228 for hackers-outgoing; Wed, 13 Nov 1996 06:05:47 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA18223 for ; Wed, 13 Nov 1996 06:05:44 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id OAA14989; Wed, 13 Nov 1996 14:05:25 GMT Date: Wed, 13 Nov 1996 23:05:25 +0900 (JST) From: Michael Hancock To: Andrew Stesin cc: FreeBSD Hackers Subject: Re: Programming technique for non-forking servers? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [cc:Trimmed] Is forking on FreeBSD all that bad? On Wed, 13 Nov 1996, Andrew Stesin wrote: > I mean those like Squid, Harvest cached, probably Gated > (there is also a non-forking WWW server somewhere, but > I forgot it's name, for a pity). Roxen, previously Spinner. Regards, Mike Hancock From owner-freebsd-hackers Wed Nov 13 06:49:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA19951 for hackers-outgoing; Wed, 13 Nov 1996 06:49:57 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA19926; Wed, 13 Nov 1996 06:49:46 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id OAA15158; Wed, 13 Nov 1996 14:49:44 GMT Date: Wed, 13 Nov 1996 23:49:43 +0900 (JST) From: Michael Hancock To: FreeBSD Hackers cc: freebsd-fs@FreeBSD.ORG Subject: NFS bypass op and the utok layer Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Were these even considered when the FreeBSD vnode stacking implementation was done? The NFS default op is the one returning the NOT SUPPORTED error. A bypass op would allow you to stack on top of an out-of-kernel layer which could then be layered on a utok layer to cross the boundary again. I guess the fs memory allocation architecture is not compatible with this. Debugging in userland would sure be cool, when you're satisfied take away the transport layers and you're back in the kernel. Regards, Mike Hancock From owner-freebsd-hackers Wed Nov 13 06:50:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA20028 for hackers-outgoing; Wed, 13 Nov 1996 06:50:16 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA20009 for ; Wed, 13 Nov 1996 06:50:11 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA23190; Wed, 13 Nov 1996 08:48:55 -0600 From: Joe Greco Message-Id: <199611131448.IAA23190@brasil.moneng.mei.com> Subject: Re: Programming technique for non-forking servers? To: stesin@gu.net (Andrew Stesin) Date: Wed, 13 Nov 1996 08:48:55 -0600 (CST) Cc: hackers@freebsd.org, squid-users@nlanr.net In-Reply-To: from "Andrew Stesin" at Nov 13, 96 12:32:33 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hello people, > > can anyone point me to some book, or URL(s), where the > programming technique for writing non-forking network server > daemons is described in details? with caveats, non-obvious > places... > > I mean those like Squid, Harvest cached, probably Gated > (there is also a non-forking WWW server somewhere, but > I forgot it's name, for a pity). AFAIK they are written > around a huge select(), and are using asynchronous I/O. > Yes, there are sources, but I'd really like to read > some general theory on the subject. > > Thanks in advanse! I don't know about a book, etc., but many programs work on this paradigm, including inetd, the X11 Xserver, INN, various MUD and IRC type programs, etc. The idea is that you have a set of existing connections, and a socket on which to accept new connections. In a while(1) loop, you do a select() on all of the FD's above. Then you iterate through the select return data, looking for FD's marked for read. If the "new connections" FD is marked for read, you accept() a new conn and add it to your list of existing conn's. If an "existing connection" FD is marked for read, you read from it, possibly buffering the data in some sort of "input buffer", and when you receive a complete message, you dispatch it to a handler of some sort. Presumably the handler is very quick and returns "instantly", if not, you are holding off the servicing of other connections. In that case, it gets trickier. If, for example, you are writing gobs of data from a file to the client, that may take a while over a 9600 baud IP link. You modify your select() loop to have both a read and a write FD mask, and your "handler" then becomes a mechanism to simply open the file. Your "write handler" then reads data from the file and writes it to the socket as space allows. In the case of a "complex" server, i.e. something like an Xserver or MUD, but probably not a Web server, you probably need to use state machine concepts. This is not "difficult", the only real problem is mastering the concept of state machines. In all cases, the main principle behind a single server process is that YOU MUST NOT BLOCK (or take an unusually large amount of time to do something). That is the nutshell version of a select() based server process. If you have specific questions, I may be able to fill in some details. ... JG From owner-freebsd-hackers Wed Nov 13 07:04:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA21204 for hackers-outgoing; Wed, 13 Nov 1996 07:04:14 -0800 (PST) Received: from fog.xinside.com (fog.xinside.com [199.164.187.39]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA21147 for ; Wed, 13 Nov 1996 07:04:02 -0800 (PST) Received: (from smap@localhost) by fog.xinside.com (8.7.6/8.7.3) id IAA13127; Wed, 13 Nov 1996 08:04:00 -0700 (MST) X-Authentication-Warning: fog.xinside.com: smap set sender to using -f Received: from xeno.xinside.com(199.164.187.221) by fog.xinside.com via smap (V1.3) id sma013125; Wed Nov 13 08:03:45 1996 Received: (from roell@localhost) by xeno.xinside.com (8.7.5/8.6.12) id IAA09278; Wed, 13 Nov 1996 08:03:45 -0700 (MST) Date: Wed, 13 Nov 1996 08:03:45 -0700 (MST) Message-Id: <199611131503.IAA09278@xeno.xinside.com> From: Thomas Roell To: Bruce Evans Cc: hackers@freebsd.org, jkh@time.cdrom.com Subject: Re: Is our ASYNC I/O support for ttys broken? In-Reply-To: <199611130816.TAA28631@godzilla.zeta.org.au> References: <199611130816.TAA28631@godzilla.zeta.org.au> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In your message of 13 November 1996 you write: > >Thomas Roell over at X Inside just sent me this little snippet, > >complaining that ASYNC I/O was broken in FreeBSD where it worked with > >Linux and SVR4. Any comments? > > The status hasn't changed since he complained a year or so ago. > SIGIO for ASYNC tty i/o is only sent to the process group of the tty, > and process group stuff is limited by it being POSIX conformant > with few extensions - the process group can not be changed using > F_SETOWN (although F_SETOWN takes you outside of POSIX) unless the > corresponding change using tcsetpgrp() would work. SIGIO for ASYNC > socket i/o works better because the process or process group of the > socket, and this is unrelated to the POSIX process group. Would it be possible to change that behaviour in the future ? > > fd = open("/dev/ttyd0", O_RDONLY | O_NONBLOCK); > > > > fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | FASYNC); > > fcntl(fd, F_SETOWN, getpid()); > > The second fcntl is guaranteed to fail, since `fd' isn't a controlling > terminal. To make fd a controlling terminal, something like the following > must be done: > > fork() > wait in parent, continue as follows in child: > setsid(); /* become a session leader with no ctty */ > open as above > first fcntl as above > ioctl(fd, TIOCSCTTY, NULL); /* make fd the ctty */ > second fcntl as above Tried that already. Doesn't work. Problem is that I really don't want to spawn subprocesses for io-stuff. On the other hand asynchronous input is really mandatory if you have a heavily loaded box and run CDE and/or OpenGL/PEX apps. - Thomas -- Denver Office THOMAS ROELL /\ Das Reh springt hoch, +1(303)298-7478 X INSIDE INC / \/\ das Reh springt weit, 1801 Broadway, Suite 1710 / \ \/\ was soll es tun, Denver, CO 80202 roell@xinside.com / Oelch! \ \ es hat ja Zeit. From owner-freebsd-hackers Wed Nov 13 07:04:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA21198 for hackers-outgoing; Wed, 13 Nov 1996 07:04:13 -0800 (PST) Received: from whale.gu.kiev.ua ([194.93.190.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA21138 for ; Wed, 13 Nov 1996 07:04:00 -0800 (PST) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [194.93.190.3]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id RAA35586; Wed, 13 Nov 1996 17:03:41 +0200 Date: Wed, 13 Nov 1996 17:03:40 +0200 (EET) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: Michael Hancock cc: FreeBSD Hackers Subject: Re: Programming technique for non-forking servers? In-Reply-To: Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, On Wed, 13 Nov 1996, Michael Hancock wrote: > [cc:Trimmed] > > Is forking on FreeBSD all that bad? Of course, no! But I have an impression that there's easier to implement locking of shared memory and file resources inside a single-process server than with some kind of IPC. There is SysV IPC around, but it has it's limitations. Using mmap() as a shared memory pool? isn't so clear and transparent for me (at least now), and generally isn't documented; so the question remains opened, that's why I'm asking about where a Fine Manual resides which should be read. Content-based locking of memory areas is a question, too. I remember there was recently a set of patches to FreeBSD kernel by Ron M. Sarnoff (?), adding ability to do content-based memory locks at kernel level, thus helpful for forking server; but what was their further faith? A project I'm planning is supposedly close to special kind of a database server, which supports transactions and multiple client connections at a time. But my education isn't yet sufficient for getting a clear concept of How Should This Be Done. So pointers to a good tutorial on _practical_ transaction processing are welcome. Non-forking server came to mind just because I think that I can "reinvent the wheel" of concurrency control inside a single process with a better success. Now I'm waiting for Stevens' book to come (everyone recommend it, despite of it's comparative oldness - 1992), and have also found a pointer to some books from Prentice-Hall: "Performance of Concurrency Control Mechanisms in Centralized Data", 1/e by Vijay Kumar, University of Missouri, Kansas City. Published September, 1995 by Prentice Hall ESM ISBN 0-13-065442-6 Any opinions on this one? They also have a serie of books on programming multithreaded applications. > On Wed, 13 Nov 1996, Andrew Stesin wrote: > > > I mean those like Squid, Harvest cached, probably Gated > > (there is also a non-forking WWW server somewhere, but > > I forgot it's name, for a pity). > > Roxen, previously Spinner. Thanks! > Regards, > > > Mike Hancock > -- Best, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Wed Nov 13 07:13:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA21997 for hackers-outgoing; Wed, 13 Nov 1996 07:13:15 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA21966 for ; Wed, 13 Nov 1996 07:13:01 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id JAA23232; Wed, 13 Nov 1996 09:11:19 -0600 From: Joe Greco Message-Id: <199611131511.JAA23232@brasil.moneng.mei.com> Subject: Re: Programming technique for non-forking servers? To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 13 Nov 1996 09:11:19 -0600 (CST) Cc: stesin@gu.net, hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Nov 13, 96 11:05:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > [cc:Trimmed] > > Is forking on FreeBSD all that bad? If it results in additional large servers and IPC to coordinate information, yes. Not all applications are like that, but some are. ... JG From owner-freebsd-hackers Wed Nov 13 08:35:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27258 for hackers-outgoing; Wed, 13 Nov 1996 08:35:17 -0800 (PST) Received: from mullet.ntd.co.uk ([194.207.104.122]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA27248 for ; Wed, 13 Nov 1996 08:35:08 -0800 (PST) Received: from c493.toyota.co.uk (tgb-isd.demon.co.uk [194.222.88.26]) by mullet.ntd.co.uk (8.6.11/8.6.9) with SMTP id QAA26127 for ; Wed, 13 Nov 1996 16:39:45 GMT Date: Wed, 13 Nov 1996 16:39:45 GMT Message-Id: <199611131639.QAA26127@mullet.ntd.co.uk> X-Sender: aledm@mailhost.pavilion.co.uk (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: Aled Morris Subject: job vacancy (in UK) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My employer - Toyota (GB) Ltd. - is looking to hire a network/system administrator to work in a team managing our Intranet (and future Internet connection). The network connects six offices (using leased lines and Cisco routers) and 250 dealers (using ISDN and Ascend Pipeline 50). Services currently provided are SMTP email (sendmail and MMDF), WWW (Apache server) and Telnet-5250 access to corporate servers (AS/400). Experience with FreeBSD system administration (network config, SCSI etc.), shell and awk scripting is essential as is familiarity with TCP/IP networking (subnetting, routing, DNS, packet filtering etc.) Additional experience of Cisco, Ascend, Ethernet cabling, C programming, HTML etc. would be useful as this is a "hands on" responsive role in a rapidly changing environment. Toyota offers a competitive salary and benefits package, and a company car (depending on age). The position will be based in Redhill (close to Gatwick Airport, 20 miles due South of London). If you are interested please email me or call me 9AM-9PM GMT on 0973 207987 to discuss the position. Apologies to regular readers of -hackers for the advertising, but I hope we will be able to feedback into the project our experiences of using FreeBSD in a "live" environment! Aled Morris Network Controller, Information Systems Department Toyota (GB) Ltd., The Quadrangle, Redhill, Surrey RH1 1PX -- telephone +44 973 207987 O- From owner-freebsd-hackers Wed Nov 13 08:50:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27791 for hackers-outgoing; Wed, 13 Nov 1996 08:50:52 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA27780 for ; Wed, 13 Nov 1996 08:50:42 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA29233; Wed, 13 Nov 1996 11:50:07 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 13 Nov 1996 11:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id IAA15655; Wed, 13 Nov 1996 08:48:59 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id IAA17637; Wed, 13 Nov 1996 08:50:28 -0500 (EST) Date: Wed, 13 Nov 1996 08:50:28 -0500 (EST) From: Thomas David Rivers Message-Id: <199611131350.IAA17637@lakes.water.net> To: michaelh@cet.co.jp, ponds!ponds!rivers Subject: Re: Even more info on daily panics... Cc: ponds!FreeBSD.ORG!Hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > IMHO, it's not good to speculate. You need to confirm with absolute > certainty that the patch is what actually fixed it. > > You might want to do either of the following: > > 1) Remove the patch and see if what happens. > > 2) Put in print statements and see if the relevent section of code ever > gets executed. See other #ifdef DIAGNOSTICS for examples of how to do > this. I think vrele() had one. > > > Regards, > > > Mike Hancock Yes! What an excellent idea! It simply never occurred to me (dooh.) I'll put a printf() in the vfs_subr.c source - so that if we would have walked off the end of the chain (or back around), we'll get something. The other vrele() diagnostic hasn't been tripped; so we must not be getting a negative usecount... - Dave Rivers - From owner-freebsd-hackers Wed Nov 13 09:06:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA28522 for hackers-outgoing; Wed, 13 Nov 1996 09:06:02 -0800 (PST) Received: from nimbus.superior.net (root@nimbus.superior.net [206.153.96.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA28516 for ; Wed, 13 Nov 1996 09:05:57 -0800 (PST) Received: (from exidor@localhost) by nimbus.superior.net (8.7.6/8.7.5) id MAA10785; Wed, 13 Nov 1996 12:05:50 -0500 (EST) Message-Id: <199611131705.MAA10785@nimbus.superior.net> Date: Wed, 13 Nov 1996 12:05:50 -0500 From: exidor@superior.net (Christopher Masto) To: hackers@freebsd.org Subject: Re: Programming technique for non-forking servers? References: X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 In-Reply-To: ; from Andrew Stesin on Nov 13, 1996 17:03:40 +0200 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Andrew Stesin writes: > > Is forking on FreeBSD all that bad? > > Of course, no! > > But I have an impression that there's easier > to implement locking of shared memory and file > resources inside a single-process server than > with some kind of IPC. There is SysV IPC around, > but it has it's limitations. Using mmap() as a shared > memory pool? isn't so clear and transparent for me (at least > now), and generally isn't documented; so the question > remains opened, that's why I'm asking about > where a Fine Manual resides which should be read. This reminds me of a related thing that's been nagging me since I first started writing Unix programs about 5 years ago. Occasionally (more often recently) I'm working on something that screams for a couple of cooperating processes.. coming from the Amiga world, this seems very natural, and on the Amiga it was very simple. One process opens up a "message port", and another process sends messages to it. The closest thing I have seen is creating a socket in the Unix domain.. but this doesn't seem very popular, so I get the feeling it isn't often the right answer. I suppose part of the problem is that I've learned mostly from man pages, so I haven't read any of the canonical books on Unix or network programming. Of course, this is probably not the most appropriate place in which to whine about this. And while I'm at it.. I miss ARexx. I keep wishing for something like a Perl that runs as a daemon and provides unified scripting services to other programs. -- Christopher Masto . . . . Superior Net Support: support@superior.net chris@masto.com . . . . . Masto Consulting: info@masto.com On Wisdom, Congressional: That's the most unheard-of thing I ever heard of. - Senator Joseph McCarthy, talking about a witness's testimony From owner-freebsd-hackers Wed Nov 13 09:34:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA29992 for hackers-outgoing; Wed, 13 Nov 1996 09:34:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA29986 for ; Wed, 13 Nov 1996 09:34:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA22406; Wed, 13 Nov 1996 10:22:25 -0700 From: Terry Lambert Message-Id: <199611131722.KAA22406@phaeton.artisoft.com> Subject: Re: Even more info on daily panics... To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 13 Nov 1996 10:22:25 -0700 (MST) Cc: ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Nov 13, 96 01:52:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > IMHO, it's not good to speculate. You need to confirm with absolute > certainty that the patch is what actually fixed it. I agree. Your theory about the compiler bug and vrele() may be remote, but it's still a possibility. > You might want to do either of the following: > > 1) Remove the patch and see if what happens. This would be a good plan. > 2) Put in print statements and see if the relevent section of code ever > gets executed. See other #ifdef DIAGNOSTICS for examples of how to do > this. I think vrele() had one. I'd suggest an if/printf for the old boundry condition; I'd prefer taking the fix out to get the original panics, with no other unrelated changes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 13 09:35:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00215 for hackers-outgoing; Wed, 13 Nov 1996 09:35:48 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA00206 for ; Wed, 13 Nov 1996 09:35:41 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id EAA11083; Thu, 14 Nov 1996 04:34:53 +1100 Date: Thu, 14 Nov 1996 04:34:53 +1100 From: Bruce Evans Message-Id: <199611131734.EAA11083@godzilla.zeta.org.au> To: bde@zeta.org.au, roell@crab.xinside.com Subject: Re: Is our ASYNC I/O support for ttys broken? Cc: hackers@freebsd.org, jkh@time.cdrom.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> The status hasn't changed since he complained a year or so ago. >> SIGIO for ASYNC tty i/o is only sent to the process group of the tty, >> and process group stuff is limited by it being POSIX conformant >> with few extensions - the process group can not be changed using >Would it be possible to change that behaviour in the future ? Of course. >> > fd = open("/dev/ttyd0", O_RDONLY | O_NONBLOCK); >> > >> > fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | FASYNC); >> > fcntl(fd, F_SETOWN, getpid()); >> >> The second fcntl is guaranteed to fail, since `fd' isn't a controlling >> terminal. To make fd a controlling terminal, something like the following >> must be done: >> >> fork() >> wait in parent, continue as follows in child: >> setsid(); /* become a session leader with no ctty */ >> open as above >> first fcntl as above >> ioctl(fd, TIOCSCTTY, NULL); /* make fd the ctty */ >> second fcntl as above > >Tried that already. Doesn't work. It works with getpid() replaced by `-getpgrp()'. >Problem is that I really don't want to spawn subprocesses for >io-stuff. On the other hand asynchronous input is really mandatory if >you have a heavily loaded box and run CDE and/or OpenGL/PEX apps. Is this for the X server? It's already in the background and doesn't have a controlling terminal (at least for XFree :-) so no additional processes are required for handling one mouse. Bruce From owner-freebsd-hackers Wed Nov 13 09:36:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00333 for hackers-outgoing; Wed, 13 Nov 1996 09:36:44 -0800 (PST) Received: from Guard.PolyNet.Lviv.UA (Guard.PolyNet.Lviv.UA [194.44.138.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA00305 for ; Wed, 13 Nov 1996 09:36:23 -0800 (PST) Received: (from smap@localhost) by Guard.PolyNet.Lviv.UA (8.6.12/8.6.12) id TAA28075; Wed, 13 Nov 1996 19:35:14 +0200 Received: from netsurfer.lp.lviv.ua(192.168.0.3) by Guard.PolyNet.Lviv.UA via smap (V2.0beta) id xma028069; Wed, 13 Nov 96 19:34:55 +0200 Received: (from smap@localhost) by NetSurfer.lp.lviv.ua (8.6.12/8.6.12) id TAA08520; Wed, 13 Nov 1996 19:32:40 +0200 Received: from nova.lp.lviv.ua(192.168.0.6) by NetSurfer.lp.lviv.ua via smap (V2.0beta) id xma008518; Wed, 13 Nov 96 19:32:11 +0200 Message-ID: <328A061B.167E@polynet.lviv.ua> Date: Wed, 13 Nov 1996 19:32:11 +0200 From: Slavik Terletsky Organization: State University "Lvivska Polytechnicka" X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.2 alpha) MIME-Version: 1.0 To: FreeBSD Hackers mailing list CC: Andrew.Gordon@net-tel.co.uk Subject: Q: How to read hardware port ? *HELP* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, need a real HELP! my program: 1) opens /dev/io with O_RDONLY 2) tries to read by inbv(0x443) looks good, but doesn't work, and no error is shown. BTW this is for watchdog feature, which works in dos Thenk you. -- # Slavik Terletsky # University "Lvivska Poytechnica" # # Network Administrator # mailto:ts@polynet.lviv.ua # From owner-freebsd-hackers Wed Nov 13 09:44:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00874 for hackers-outgoing; Wed, 13 Nov 1996 09:44:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA00864 for ; Wed, 13 Nov 1996 09:44:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA22431; Wed, 13 Nov 1996 10:32:19 -0700 From: Terry Lambert Message-Id: <199611131732.KAA22431@phaeton.artisoft.com> Subject: Re: Even more info on daily panics... To: dg@root.com Date: Wed, 13 Nov 1996 10:32:19 -0700 (MST) Cc: michaelh@cet.co.jp, ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.org In-Reply-To: <199611130504.VAA07192@root.com> from "David Greenman" at Nov 12, 96 09:04:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I would also like to hear an explaination of how it is possible, after the > patch to vrele to prevent it from going negative, for a vnode with a non-zero > v_usecount can be on the freelist in the first place. Please check my previous mail... There is a race condition caused by the fact that the vnode reclamation is "smeared" across the VFS/FS boundry layer. It is not obvious unless you consider interfaces to represent access points for automatons instead of simply functional abstractions of object complexity (ie: it is an artifact of layering errors). Another way of stating this is to think of execution contexts as moving from place to place, rather than sleeping and waking up. It's very important to view things like this in any case for SMP, where a context should be considered as an anonymous, schedulable resource to apply to outstanding work-to-do. The only difference here is that there is only one schedulable resource, and we currently do not have to worry about reentrancy. The problem with a "smeared" task is that you can "reenter" without crossing the interface boundry... so protecting against recossing the boundry does not necessarily protect against the race condition. This really needs a whiteboard; I explain better with pictures, and "ascii art" just won't cut it for drawing a cyclic graph. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 13 10:04:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA02406 for hackers-outgoing; Wed, 13 Nov 1996 10:04:31 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA02396 for ; Wed, 13 Nov 1996 10:04:26 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA23482; Wed, 13 Nov 1996 12:03:22 -0600 From: Joe Greco Message-Id: <199611131803.MAA23482@brasil.moneng.mei.com> Subject: Re: Programming technique for non-forking servers? To: exidor@superior.net (Christopher Masto) Date: Wed, 13 Nov 1996 12:03:22 -0600 (CST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199611131705.MAA10785@nimbus.superior.net> from "Christopher Masto" at Nov 13, 96 12:05:50 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This reminds me of a related thing that's been nagging me since I > first started writing Unix programs about 5 years ago. Occasionally > (more often recently) I'm working on something that screams for a > couple of cooperating processes.. coming from the Amiga world, this > seems very natural, and on the Amiga it was very simple. One process > opens up a "message port", and another process sends messages to it. > The closest thing I have seen is creating a socket in the Unix > domain.. but this doesn't seem very popular, so I get the feeling it > isn't often the right answer. As far as I can tell... you're wrong. :-) UNIX is fundamentally different from crud like DOS... interprocess communication is a core part of the system and is actively encouraged. Build your own tools from shell commands. Write your own C code that opens dozens of sockets. That should be relatively similar to the Amiga world, as I understand it, although I have never owned one. I think what puts off most relative newcomers is the complexity of the BSD socket paradigm. This is NOT intended to prevent or discourage you from using it! It is simply due to the incredible flexibility inherent in a network-aware interprocess communication layer. Where else can you whip out a dozen lines of C code that connects to a process in Japan and starts talking to it? If you find it somewhat more complex than you would prefer, write library functions to simplify the "grunt work". You will not be able to cover every scenario, but you can cover the common ones where you just want to open a connection to someplace. Even though I have been doing this stuff for a long time now, I still use a set of library routines I wrote a long time ago, because in 90% of the cases, I just want to do something simple. There are, of course, other forms of IPC available as well. IPC is _great_. It is _often_ the right answer. ... JG From owner-freebsd-hackers Wed Nov 13 10:05:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA02520 for hackers-outgoing; Wed, 13 Nov 1996 10:05:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA02495; Wed, 13 Nov 1996 10:05:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA22484; Wed, 13 Nov 1996 10:54:58 -0700 From: Terry Lambert Message-Id: <199611131754.KAA22484@phaeton.artisoft.com> Subject: Re: NFS bypass op and the utok layer To: michaelh@cet.co.jp (Michael Hancock) Date: Wed, 13 Nov 1996 10:54:58 -0700 (MST) Cc: Hackers@freebsd.org, freebsd-fs@freebsd.org In-Reply-To: from "Michael Hancock" at Nov 13, 96 11:49:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Boy, people keep asking questions for which my work is the answer... this is more than a little cool. 8-). > Were these even considered when the FreeBSD vnode stacking implementation > was done? > > The NFS default op is the one returning the NOT SUPPORTED error. A bypass > op would allow you to stack on top of an out-of-kernel layer which could > then be layered on a utok layer to cross the boundary again. > > I guess the fs memory allocation architecture is not compatible with this. You have hit the nail on the head. There are many places where the FS is expected to allocate something which it will never deallocate, or deallocate something which it did not allocate. Examples include: o The vfs_syscalls.c generated namei cn_pnbuf o The NFS generated namei cn_pnbuf o The vnode In addition, there are many places where the VOP's are not abstracted by status return (ie: they are call-down instead of veto interfaces). Examples include: o VOP_LOCK o VOP_ADVLOCK o VFS_MOUNT o NFS export list porcessing o root mount processing o remount processing o mount point covering o namei() o CREATE op in EXISTS case with no intention of overrwrite in the case of collision Without a clear abstraction, it's impossible to build a utok/ktou layer (I would prefer a ktou to a bypass op; it's more general, and doesn't require an NFS loopback). Particularly problematic are the NFS LEASE VOP's, which are interfaced by a serious kludge because they are call-down instead of veto, and therefore can not be zero-overhead registration based. If my changes for fcntl() to support server-side NFS locking (as the subsystem called by rpc.lockd) are ever integrated, this will add another, identical kludge for FHTOVP for an NFS LKM. > Debugging in userland would sure be cool, when you're satisfied take away > the transport layers and you're back in the kernel. This was discussed in detail in the Heidemann paper, actually... and yes, it's the way I'd like to do FS debuging as well. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 13 10:08:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA02880 for hackers-outgoing; Wed, 13 Nov 1996 10:08:59 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA02865 for ; Wed, 13 Nov 1996 10:08:52 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id MAA23621 for ; Wed, 13 Nov 1996 12:08:51 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id MAA18449 for ; Wed, 13 Nov 1996 12:08:50 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id MAA15951 for hackers@freebsd.org; Wed, 13 Nov 1996 12:08:49 -0600 (CST) From: Karl Denninger Message-Id: <199611131808.MAA15951@Jupiter.Mcs.Net> Subject: Setting maximum RAM consumption by a process To: hackers@freebsd.org Date: Wed, 13 Nov 1996 12:08:48 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks, I know how to do this for BSDI (maximum segment size) but not for FreeBSD, and the same parameters don't appear to work. Basically, our news server is now reaching a WSS of 100MB+, and we need to increase it (because we're getting malloc failures and death of the process :-) The system has lots of RAM, so that's not a problem. Anyone got the magic words for the config file? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Wed Nov 13 10:16:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03442 for hackers-outgoing; Wed, 13 Nov 1996 10:16:19 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA03422 for ; Wed, 13 Nov 1996 10:16:02 -0800 (PST) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id KAA14170; Wed, 13 Nov 1996 10:13:41 -0800 (PST) Message-Id: <199611131813.KAA14170@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: dg@root.com, michaelh@cet.co.jp, ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.org Subject: Re: Even more info on daily panics... In-reply-to: Your message of "Wed, 13 Nov 1996 10:32:19 MST." <199611131732.KAA22431@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 10:13:41 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Terry Lambert : > This really needs a whiteboard; I explain better with pictures, and > "ascii art" just won't cut it for drawing a cyclic graph. 8-(. > So get on the mbone and use FreeBSD's lounge white board 8) Cheers, Amancio From owner-freebsd-hackers Wed Nov 13 10:38:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04850 for hackers-outgoing; Wed, 13 Nov 1996 10:38:03 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA04843 for ; Wed, 13 Nov 1996 10:37:51 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id NAA00686; Wed, 13 Nov 1996 13:37:44 -0500 (EST) From: John Dyson Message-Id: <199611131837.NAA00686@dyson.iquest.net> Subject: Re: Setting maximum RAM consumption by a process To: karl@Mcs.Net (Karl Denninger) Date: Wed, 13 Nov 1996 13:37:39 -0500 (EST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199611131808.MAA15951@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 13, 96 12:08:48 pm Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hi folks, > > I know how to do this for BSDI (maximum segment size) but not for FreeBSD, > and the same parameters don't appear to work. > > Basically, our news server is now reaching a WSS of 100MB+, and we need to > increase it (because we're getting malloc failures and death of the process > :-) > > The system has lots of RAM, so that's not a problem. > > Anyone got the magic words for the config file? > You can set it dynamically with ulimit (up it to 128M.) Any further, you can set the config variables DFLDSIZ and MAXDSIZ to practically anything you want. So, for 192MB options "MAXDSIZ=201326592" options "DFLDSIZ=201326592" John From owner-freebsd-hackers Wed Nov 13 11:04:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06877 for hackers-outgoing; Wed, 13 Nov 1996 11:04:22 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA06869 for ; Wed, 13 Nov 1996 11:04:16 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA23600; Wed, 13 Nov 1996 13:02:50 -0600 From: Joe Greco Message-Id: <199611131902.NAA23600@brasil.moneng.mei.com> Subject: Re: Setting maximum RAM consumption by a process To: karl@mcs.net (Karl Denninger) Date: Wed, 13 Nov 1996 13:02:50 -0600 (CST) Cc: hackers@FreeBSD.org In-Reply-To: <199611131808.MAA15951@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 13, 96 12:08:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Hi folks, > > I know how to do this for BSDI (maximum segment size) but not for FreeBSD, > and the same parameters don't appear to work. > > Basically, our news server is now reaching a WSS of 100MB+, and we need to > increase it (because we're getting malloc failures and death of the process > :-) > > The system has lots of RAM, so that's not a problem. > > Anyone got the magic words for the config file? Sorry to be causing your news server such grief, Karl :-) metropolis# more /sys/i386/conf/NEWS* [...] maxusers 256 #options "MAXDSIZ=(256UL*1024*1024)" options "MAXDSIZ=268435456UL" #options "DFLDSIZ=(192UL*1024*1024)" options "DFLDSIZ=201326592UL" options "MAXMEM=262720" #real memory = 67698688 (16528 pages) #+192MB = 256MB Happy newsfeeding, ... JG From owner-freebsd-hackers Wed Nov 13 11:27:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA08319 for hackers-outgoing; Wed, 13 Nov 1996 11:27:23 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA08309; Wed, 13 Nov 1996 11:27:20 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id NAA27437; Wed, 13 Nov 1996 13:27:18 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA05415; Wed, 13 Nov 1996 13:27:17 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id NAA17877; Wed, 13 Nov 1996 13:27:16 -0600 (CST) From: Karl Denninger Message-Id: <199611131927.NAA17877@Jupiter.Mcs.Net> Subject: Re: Setting maximum RAM consumption by a process To: dyson@FreeBSD.ORG Date: Wed, 13 Nov 1996 13:27:16 -0600 (CST) Cc: karl@Mcs.Net, hackers@FreeBSD.ORG In-Reply-To: <199611131837.NAA00686@dyson.iquest.net> from "John Dyson" at Nov 13, 96 01:37:39 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > > Hi folks, > > > > I know how to do this for BSDI (maximum segment size) but not for FreeBSD, > > and the same parameters don't appear to work. > > > > Basically, our news server is now reaching a WSS of 100MB+, and we need to > > increase it (because we're getting malloc failures and death of the process > > :-) > > > > The system has lots of RAM, so that's not a problem. > > > > Anyone got the magic words for the config file? > > > You can set it dynamically with ulimit (up it to 128M.) Any further, > you can set the config variables DFLDSIZ and MAXDSIZ to practically > anything you want. So, for 192MB > > options "MAXDSIZ=201326592" > options "DFLDSIZ=201326592" > > John Thanks.... we already had the "prestart" thing doing the set to 128MB, but now I need to get beyond that :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Wed Nov 13 11:49:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09771 for hackers-outgoing; Wed, 13 Nov 1996 11:49:56 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA09756 for ; Wed, 13 Nov 1996 11:49:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA22676; Wed, 13 Nov 1996 12:38:09 -0700 From: Terry Lambert Message-Id: <199611131938.MAA22676@phaeton.artisoft.com> Subject: Re: Programming technique for non-forking servers? To: stesin@gu.net (Andrew Stesin) Date: Wed, 13 Nov 1996 12:38:09 -0700 (MST) Cc: hackers@freebsd.org, squid-users@nlanr.net In-Reply-To: from "Andrew Stesin" at Nov 13, 96 12:32:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > can anyone point me to some book, or URL(s), where the > programming technique for writing non-forking network server > daemons is described in details? with caveats, non-obvious > places... The Stevens books cover it... > Yes, there are sources, but I'd really like to read > some general theory on the subject. The general theory is that you change a blocking call into a non-blocking call + a context switch. In other words, it's state-machine based event driven multithreading. ,------> wait for packet | | | v | select() o-----------------------. | | socket A | socket B | v v | f(context A) f(context B) | \ / | \ / | \ / | \ / | \ / | v | o packet processing function f() | | | v | o any additional processing | | `------------------------' In addition, the packet may be a connect() request from a remote client; if so, you need to: 1) accept the connection to bind it to a local socket 2) add the socket to the list of fd's that the select is listening to 3) continue processing so the main loop looks like: /* * init */ create connect_socket for incoming connections post listen() on socket connect_socket init default fd_set default_read_mask to contain connect_socket set max_fd to connect_socket + 1 initialize context_list to NULL /* * main loop */ while( 1) { copy default_read_mask to real_read_mask select( max_fd, real_read_mask) /* * if we got here, a socket event has occurred; * real_read_mask will now contain the fd's * (sockets) which you must do processing on. */ /* check for incoming connections, first thing*/ if( FD_ISSET( connect_socket, &real_read_mask)) { /* clear so we don't hit it in processing loop*/ FD_CLR( connect_socket, &real_read_mask) /* generate default context for new connection*/ ctxp = new_context(); add_context( ctxp, context_list); ctxp->state = 0; ctxp->fd = accept( connect_socket) /* accept events on this context*/ FD_SET(ctxp->fd, &default_read_mask) } /* process all contexts which aren't incoming connections*/ for( ctxp = context_list; ctxp = ctxp->next) { if( FD_ISSET( ctxp->fd, &real_read_mask)) { handle_event( ctxp); } } } Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 13 11:50:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09851 for hackers-outgoing; Wed, 13 Nov 1996 11:50:54 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA09835 for ; Wed, 13 Nov 1996 11:50:45 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09533; Wed, 13 Nov 1996 14:50:12 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 13 Nov 1996 14:50 EST Received: (from rivers@localhost) by ponds.water.net (8.7.5/8.7.3) id MAA19571; Wed, 13 Nov 1996 12:25:30 -0500 (EST) Date: Wed, 13 Nov 1996 12:25:30 -0500 (EST) From: Thomas David Rivers Message-Id: <199611131725.MAA19571@ponds.water.net> To: wpaul@skynet.ctr.columbia.edu, ponds!whistle.com!julian Subject: Re: library needed to port s/w to Freebsd (tsearch,lsearch,bsearch) Cc: ponds!freebsd.org!hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bill Paul writes: > > Of all the gin joints in all the towns in all the world, Julian Elischer > had to walk into mine and say: > > > I have a package that needs the 'search' library from sysVR2 > > (and later I presume) > > it looks for "search.h" > > "search" used to allow one to build and search a tree of arbitrary items > > > > I found paul Vixie's AVL tree routines in the archive, > > and maybe I was thinking of them but I remmeber > > the docs saying "This is a drop in replacement..." > > and that's not true for the AVL stuff. > > > > does anyone know of the replacement library? > > I remember there WAS one, but I've been scanning the archives > > and haven't found it yet. > > > > julian > > Hm. The Berkeley DB hash method has what it calls an 'hsearch > compatibility interface' which is supposed to be for compatibility > with System V, though it doesn't specify any particular version > of System V. If you look in the source tree for the DB package and > check the hash directory, you'll see there's a search.h header there, > which for some reason doesn't seem to get installed. I don't know if > this is what you're after though since you didn't really say what > functions this library provides. There's only a small handfull of them > in this particular search.h header so it may not be what you're after. > Might not hurt to check it out though. > > -Bill > I _knew_ I had squirrelled these away somewhere... I finally found them. At some time, someone in the past (could be Paul Vixie?) had a POSIX library that brought POSIX functions to a non-posix system... Unfortunately, I don't know exactly when I grabbed them, or who provided them, or from where it came... However, this library does contain the tsearch, lsearch and bsearch family of functions, as implemented by Eric S. Raymond. The sources for these has the text "Totally public domain" prominently placed at the top; so it seems we could add these to FreeBSD. I suggest we grab those and make them available in 2.1.6/2.2, since they are (apparently) in the POSIX standard. To that end, I've appended the following uuencoded compressed tar file with the relavent routines. As an added bonus, these came with man pages! - Dave Rivers - ------------- uuencode of search.tar.Z --------------------- begin 644 search.tar.Z M'YV08N:4"2-G#!H7,\8`6,BPH<.'$"-*G$BQ8L48,&#-F M3IHW;D0H<#&EJY,@38HH"#BP(!H07%J`$)/&#<$\(`02-`@B3.0W+D"90I2:;L%0)B1.,Q;.J0*0."AV3#+M#XV`L%RFJT!I-R0:%" M!>')AU&@""X',7$5*4"L*9.'!8CE:(0_CRXFC$#K;LJPL6Y73YDW9JX/+SX] M3PKK8]ZT@4,PA5X78N3\KE,WS9GP;X7'Q@Y[Y?=;8W2H]UQ\\]6'`@@I$,A7 M5T04,<404B0!!15)/.'$7DEX=9M!"J0Q1V6+-?989(51QE0==#1&VQETE2%' M&&RD8=Y;9C#5!@A+N`%C)>(%@!G]CQ(@7E2Z$N`1UJX+I!ATGTI$J M"'?6\6-C1X7AQABT&;L8;976<08:"39F:*&'\AJB$-Y]]B6"Q98))6WBE=$& M70FVN2UMW0D$`GKO&AI&9V5X"X(3XI58;*%"MM%G<_2FN^ZP)VI[KKWXZCN$ M?++Z6Z]CZ\Z;WL*Q$D2K&[;BJJL;ULFYYF$F@L`F&YZ]=<>3A]%Q1ZIRG*$L MNW,H`*6[XPZ+:KT&TSSMJ1EC*2@(A/KI\5T<)WH4"%AJR:4"SJ8Y%XW->3;' MO\Y:5T8<=>"(JG68@7#&IG,U=S/'YC%5V8FBDFJJ&Y/6:T8:N,9!U\Y$!D))>\"$(M8PD-4PL[E'.*\P(%)(`Y>U2!!M]$H`0@"'ET"2$:"-0' M`ID1C1&,UO/*L(4J7C&+6^SB%V/0A1TDX(W/85VTRL2H$%!HJ*DC*`02=#0LPX6A-:.]O46P8))S(%4I6L3*.+P5YED`(%R'*HM4SN2Y\3 M21D0**)-VY+_@C>&^2!W-C'P:UY[NUSQDO.HGG6!&3XSH7T]@0H6BE^ARE>W MG2VL/<3;3*%ZIC-W+>RU%@N?)/$5&30`B@UO812]Z)`'.)!/6&5K@;%:P%\Z MV)2#)O-.@J3%8`4E,9E(3&,C`!MO.R`QBT!-INUO:BDJ*1YCBE'?;^][XSK>^ MA_("%2@`!'$,0HH`13\C20`81 MTK@^]?Y2\LKXOLHV6GSG?U4JOJ%7X M.NB;RQRB`WD$)8`X04L!"B)T>!`\++4LOI6+D09Z6);DD&0`%+YJKU9X-`4FQT$`*@ M9TA*Q8&U`0(KZ$M6]LV(8`H&G(@1#0YH9N2&T*&!'QUASSUA1/L8B2.(F4*(E; MT161%A9C419GD19KT1:E\CDW9Q=X<1^A\1>!H0!P:!AH=4"HI!@Y$AY)84KY M!0)U``=WPEZ,1AJF@1HTQ!I']$-*=!1#5$0%HA\N`(RO(8RU84K&Z`+PDXS` M$6>!M(J4`5+4R%$BR(6!U%'ADG=L``?DH2,[A0)PU!Y"E7SW82#2*'NDATK4 M)1YP("'LR!J'9(X+8ES*!R$2$HVL(0(A]1QLX(I;&)`LM8T&"1UX!V/A.([F M@1[XR![4D8[ZN([(R!KNJ&1P)"#S>(P'HC,1^8'Z&$P2$AH5%MN`B=R0B>_DRQYLB>!1FR5DP074RA:^76JDT8)\@:C MLB76\22Y!F6O`C51AR[%LV#'YAF\PAJ)=VLF1&6T,9:+=QG6@BU+-F!V^1O@ MXH2R0SL+,S=UDR"_9VR$2772R"_AJ)?'(RU1$R94HTS#$G:<-SP8LR58HC,! MLWKTH@"M-YBB-"B%HIEB4C*O@27YTVMAV9=MHBQM&0919CY\N9J_\7P1LS<` M$SJT09='!GV5PC'2ERO4)S*4L3!&(29*DR!S<(MP,"E[D2'7$4]`:%-_TAQE M`#JB4P8ID)39DCM99SXKHU8N`S,RXV20DR"R8S/FPF3JXC-]`C3&%3BL:333 M5RO3N93:!0)I4R:^MC"M=S?HPC5>@V&VXP8M4*#S9YFZ9:!0Y_UTBT@6G1` MIYO681F@T03[0E5,8)FOJ6M,R9^6XU[PI1J>0U^*62CXA6$(VF3L`I?U`F#& M*4H%=F`)]AD+MF8?UF9O5F$75CQLLC0V6L<,Z7WB3`EPC&Z*674 MUYMWAF6NM65PTF5PJ@!AYF=D-AMG=D?>82AJ"F)N-F%M6C9U5F57EF>[MF?C MY&>`UC?I1VBG*J:)1J7#. M497(NE#A.E,/>Q(2*TW4.).5%%7@VK";U`76P1D?>TD,*Z[5 MV@4G:[$BN[+351PB2I)^E)&EES@JR$LZ\S\<2+.K!`+,PTKW=QUF0"/$DG\R M\E(@>[$.JUS`\S8'!:U71&M65:T@8`(F\(0,&80+FTE-RX+'MU5\%QTS.Y/6 MP8T88*\((G0K6UZ+E,%+NQVI1A:G3V!3!E<`?8 M.:GFHVA)*@15<`2J405LD;!*QD!_=CS[-"]IJ8&UN:J.? M9RQ0$V4H$AZG\R3J0B65F+[JN[[LV[[N.Q4B^FSO*VUV:&TJD6TEL85W8J<'9I MMW9M)P5O%W?G5W?4<7??R)#B2(5^EWRXBX$$2(V$1QV&AWKX]9>4RR-A`WD7 M.(!B,G>4UWQ8ZGD$%GO]\8X`QY&G%T=/*2UC()KLHJ4Z!7HVJS+C-\B108Z[ MY7N\FB!<.'R@=X\BF5K*!X9QE%NGLIPO!GG6YX("F($FH\;A(1=6&!+A638< M,W?KT@9C``=YL'ST5Q*6^WYR<8#R$GXJP)%6UWX[L!@(R`,PQLK&_,O>-WXL M:(+(-Y(BZ'\I^(5:*Z!<`GSA,H.Y=PIG!1K7!T`-V3% M3%A%D'9:3"!8S72&$S!K!`)&@'9$8!UG#5]2``*$%01#P"$>0G^H1P53O8E6 M#7EKG1YT@9M>[2CG42IT]F'ERMARH#5LD5MH-1#I05A$C1I40"`RW=F>?6^D M%H<)\=E!@=$=C;\AH;_>1@,Q4`,A_;_C-H@P8`.OC1'?5@,J3=I2T=)+`8FZ M_=O`71&72#2!318@8!9HH18L6.K MA2-K@!B*@7)IL'7H-Q<#MR*T&#PQ5C/M-1JE<1JI\1L$.XQ,](S^.(TKI0+5 M?8UHNQW2\<77D9`<94Q.,<;JZ)'2>(]P!(+\R!LQ](\)"59G6)#9Z-\(6>'% M,>`.;.`5B>#V")(+/I(-#HT/CM_-`4="E"[FC8WY'1T7GM\:#HD3>$M3N`65AG,B1?VX>$@X.,*4APFAC3[>%3M=9(8 MHB%\S9(A0@6F9%,M*>%LP>4ADN+;#:@31`89ZC+>K:#&!",RPM-A(][DW2:G MPA@$1RD9K-[U*E_4X6,SDG`AS'`]XG`E''$39R0I7)0K?"(FAV%$0"5+DC@K MEIQLLZ?9%Q[BIU:6$9UN5IUP<)UI8#X&]@9KP)HE8UHX.3_IZT*N636J0SA:PZ")8RPV%3:-TR9B&DI4)YZKJ=T^I\<_Q*;FX^9O52QL^+_3=FT0@8X7IO7)7I_% MVLY.WY8OB*2IZ]"K&[-AW9;,8B.:T:/%\_.\*RUL>?:5\P1PP\2H.NE'!@>? M[LZ74<19=RJF;ND!FO3U,F1W"0)2(.,*$*"RLS.6866S\KW9(9\0]J1Y!HD* MD*5X[N@_&J15I0`F;RMA8V<:\WGELQFDI._2N.$*,!N059:^-Q\,9B@Z7\S& MANK?(6!+OOH$MC+*6DI9LC.3WYM:J0#.>1C$GSB,XE^%XL"[M3#DJ_LQAJ$6 M/!W[;BBT".;7#;O/7Y.'8;EVPJ*JB>?6\8(;!/;Z8??9DAY>225(8#IET*=K MF1YL>;UY"J-GOJ'C;W2-/JI%I-[4P+-V\.D[_3_8Q4PZ5,4H50JP5]RU_788 M[%66TVY9XC-@0.$SOM1(H/L1EH'.H;<[I_/ZDX]Q=2:D`1:*.>"A(Z'X4 M$&]Y#LN7!E@?B'%]-.PWR+[QUS?.'8WH("IJ`^*I^@'DYAWU`WTEL.4)0=S% ME%9'(1MYC8*.Z(PL)003WFPH=J%B``JI`IBB)H8:X7^1I9U90*(!Y-C`&K`9 M-Z)/"835(0(+3GI+@M+H\3D%#C7](%'UXQ8Z[WQ$BS1H(P1"Y4`!0<`-0`9: MHBTL`YX[5$;&%OG!#[4PJ)_YBQ-!CG28#A3%3II+2PH"1\X-T$':0#&*4WJP M#(?O,_REQK!5I@/U<$RBXC"P$_E2ZFZ2I3,1:ZE1:1>;HCW4$\O8%GD0`=(, M$\B8JIV[2V3"J4Y$&0:2K504+4%Y<`)2V`7-8`(G![L[@=08S0`?>S*RX%AN&#]8-W**B\)Q)"1L*T=QQPB^X.CP#.S2!\2X4Z4*],>\\ MPXU)'%DJDGP\J!=C]@Y[JH-Y"ADBDJ-(H&P$$6%Y3:KOS;K_!AFD%%0\2S4Q M#_89+C4M/M_%R%5&9TQ5LC(%*])/FO(P:TI5Q1D38R.HQ!2XB#2/($R*'L4& MQ$Q@*C.CRGR4JD+C_MC47'13L&X:8AELIF3&XI_I4H(F6PP+WPF.T/Q/4B,`DDVRG.@?E)+J@BI M3>))N@E#/!&):2M2OV@2^3Q3,%$`$24A_0^*LE;(R8"L)[&$0VJ4^K&1Q@>- MA"?/I)`PN:_R!2)),"E997`-^*Q#D@;6"@S8*T5E/]$L/S*T4(#1F@,]A:)$ MK8I%M3;)U3(!8Z*_97>>!C@R?]('EDR>'`6$[EUU"14RGDQYIR<%,4RMKS?INEO+"62 M4)2UY;)N^(#ME7XB0%V4E(&CW)62#Q+`D!S9A`%5,KB."R*Y/A`+U`- MCHP68E5:7.%QJC'%@K4\$S"V"&.+)DP`U!%[W!:D"-DZ#V_1+;\%P5`)X3(L MB,OXB)*X[KN4`:=579H+A.21U$6Z1)?98%U@I!_10CS+NT22\*(GQPL`*2_] M\KPPDF3Y')9E*V1SENZK9"L,8ADB2_W% M!5D9K$Q>)#"&K-R-K]\U5#I5K.$+0(H`^DTCQ6ORW>!D(N#/RYDY#G+FEF!2 MT8&0ST3PS2%5*[A:IP)+BP_]C;U`<7"Q`ML`$!Q1L#'O&(RFE M!\AB'7:GF=MULV9$5BNY]Q8^)W+HG5S"":*JK?CV,D.-,E]MP%==`;'@!-`. M\M)SJ',.#L4-4R;.7)*4&'B!\=P_^$,OIA*6R(3>CG"\B_!)!S[F^"P7SM,P ME#D8*`3QUI?148G%#D.U6$Y])D89J'Y3`6J.AP,$"&]@F]B!6"&4T]BB6^IN.Q$A.$0:!YH[-X](GOQ/2.QTO$%LRS,NC0YB`& M;*<'265`=#290!P!RY!=&CD8!G0U*L*R!#0]:&,`H13D#3PV4($J($`#;29EMMRP@W8`;D-E%:$7B;`Z.EN+2S43"K M0P7$8@;[8#;BSU4NGS3HB(21,'06!]%E'**Q<10%\D@#W,_J+(R14W(.5'T88@!CN&V(S"&.-CF\:1)(84EEBC MF$!>)_M$,3?@PJB8%5,[28#MN)VG9A['(VXX6-_P71(5;%?*0`)S:$%AK96! M!)'Z30%.#[4.*N"(TH&!&4GH#RW1;UY,K&TX^*"/H%H<(4AAHWHFB+%D3MY@ MHH0\@&3P%![*9RJ"C7@:PZB&VD6.MG"F@!/@`=18<>H((BZU^3`9=5E62AW!5: M-YPGBQ/?3`>),U5R5RU*25SND-QVL M*RCWZ(F0<_UN:A\!0'YDNZZ5N+-7F M4U!KX,+AA)33P?J1#ULKF:BYA2,7M1")X"S5/O>.*H.>DIM0*"V7_4A4$/7"UJHZ/ MJ[KAM*I;ZJI9Z@A>C#P85NG`6`5!MS72U0I%RE;[2$F%+BJ@(\U6-"8FY*IA MS;)U5HW$5,.Z@>8#704)=E7&X57'RE)&`A_@`]>A`P$]=:.U^C*-&3LHMBUZE65 MF"`)RUJO`Z&%K-=,TC[;PII[_&L8!&?K5<>^5?BZ76=ML&T^1,"R@I[KHU1Z M++?]M#UTM=)8GV)@1^J-=:UQA`FX6&?K:`_LC?T!/>B]PA/.VEZ;$--3*LV! MP$[;R)I[I("Q?:9NX+M=KS_#!O#M>M6L`!>YSMMF.VF'2J6%K+F'",!6N#;A MJM.H^'5S3)5$E"PD<6LM/)FKUTS?,HU>Z4?\K1]ACQG7N7+ZK5;K)]>3&6)A8 M2$H"BXVZM576_MRJ&Q)8K'GU0,#6V++<*]1>>T2,":Q%]^(N6EGK98E`>(5K M>5#%E@1FZU[3&4*[L%%P-)%/&',ZY.Z.Y1(QZ,6@;JR/>A`2FD'S,57I;'/P M<6.5\;H!LYI[C,!:#;VU\!0:CE0(9S$O57U-8C5G#@A[26ZO@P/[N8V6W5): M!/LEB=S4G;'K5J\^VG?K1XB#ZE4^PQ)I.EZ5:5A=+JEUOID0^D(BZ]!%4:;N M%2R!UBD`7Z(K?"TNI+UFZ@WQ"@1A"8E^+K,SJ+IW"LV?YJL"GB_[=0K<5XR: MP\;V?7D)P&V_/L"\DE_E:V\M+?I]GUMB_?[>`&QLW^_329F)XU8*%NS[,;0O M_FUKZ=#[KD\V<&E#0MD$F7RGNP7+Q9M]F\\5D+S=M"SU'NQ'&R#/YG5@D,SS MWD%5F4P819(DO7T$]5)@*(?+FH_K-7BP-]55!E1(&53LFPV_0]>BW%3"6GQ5 M+V.]#CZ..'0R:/LK$7#BO;]%3O5:A\*J`#R+3W64<4BA(9"&1B=`3RX]PV@X M#:OA-#@/Z^$]S(?[L!_^PX`X$`OB04R( M"[$A/L2(.!$KXD7,B!NQ(W[$D#@22^))3(DKL26^Q)@X$VOB3S;$ ` end From owner-freebsd-hackers Wed Nov 13 12:02:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA10598 for hackers-outgoing; Wed, 13 Nov 1996 12:02:09 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA10584 for ; Wed, 13 Nov 1996 12:02:02 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id VAA16552 for hackers@FreeBSD.org; Wed, 13 Nov 1996 21:00:59 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.2/8.8.2) with SMTP id VAA00500 for ; Wed, 13 Nov 1996 21:00:08 +0100 (MET) Date: Wed, 13 Nov 1996 21:00:08 +0100 (MET) From: Andreas Klemm To: hackers@FreeBSD.org Subject: how to make screen snapshots of FreeBSD floppy installation ? Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Does somebody have an idea how to make color snapshots of the system installation ? -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Wed Nov 13 12:08:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11172 for hackers-outgoing; Wed, 13 Nov 1996 12:08:23 -0800 (PST) Received: from horst.bfd.com (horst.bfd.com [204.160.242.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11157 for ; Wed, 13 Nov 1996 12:08:12 -0800 (PST) Received: from harlie (bastion.bfd.com [204.160.242.2]) by horst.bfd.com (8.7.6/8.7.3) with SMTP id MAA14051; Wed, 13 Nov 1996 12:06:11 -0800 (PST) Date: Wed, 13 Nov 1996 12:06:11 -0800 (PST) From: "Eric J. Schwertfeger" X-Sender: ejs@harlie To: Joe Greco cc: Christopher Masto , hackers@FreeBSD.org Subject: Re: Programming technique for non-forking servers? In-Reply-To: <199611131803.MAA23482@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 13 Nov 1996, Joe Greco wrote: > > (more often recently) I'm working on something that screams for a > > couple of cooperating processes.. coming from the Amiga world, this > > seems very natural, and on the Amiga it was very simple. One process > > opens up a "message port", and another process sends messages to it. > > The closest thing I have seen is creating a socket in the Unix > > domain.. but this doesn't seem very popular, so I get the feeling it > > isn't often the right answer. > > As far as I can tell... you're wrong. :-) > > UNIX is fundamentally different from crud like DOS... interprocess > communication is a core part of the system and is actively encouraged. As was (is?) the Amiga. I think SYSV IPC is closer to the Amiga's IPC than sockets. Basically, you created named (or unnamed, if the program would be the only thing using it) ports, then send structures to the port. Since the Amiga didn't protect memory at all, it was quite efficient, as the recipient could free the port, reply, or modify the packet and reply. You got a pointer to a block of memory, rather than a stream (more like UDP than TCP). You could probably emulate this with UDP, and some kind of way of registering a name to a port, and lookup. This is assuming you don't just allocate a port number. The best part of it all was that this was built into everything. All window events were sent to a program by sending a message to the port, you could even do async IO by setting it up so that you got notified of the event by a message sent to your port. And all processes (as opposed to tasks) had their own port. Had to, as the equivelent of signals was done through this port. > Where else can you whip out a dozen lines of C code that connects to a > process in Japan and starts talking to it? No arguments there. > IPC is _great_. It is _often_ the right answer. Exactly, which is why I still occasionally pine for an OS built around it :-) What I actually think Amiga programmers are missing is the shared addressing space, so that two tasks/processes could easily handle the same data structures, and seeing each other's modifications. While this isn't hard, there don't seem to be any handy tutorials on doing it in a unix-like environment, whereas it was hard not to figure it out on the Amiga. I think a handy thread-safe library based on either mmap/sockets or SYSV IPC/SHM would be a wonderful gift to the world at large. And yes, I'll do it if no one beats me to it. Of course, it'll take me until next year to find enough free time just to figure out the scope of what I want (feel free to email me if you want to bias me :-). Darn, and I just got rid of my Amiga RKM's this year. From owner-freebsd-hackers Wed Nov 13 12:29:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13534 for hackers-outgoing; Wed, 13 Nov 1996 12:29:51 -0800 (PST) Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA13511 for ; Wed, 13 Nov 1996 12:29:42 -0800 (PST) From: carson@lehman.com Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id PAA18646; Wed, 13 Nov 1996 15:28:53 -0500 Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3) id tmp018639; Wed Nov 13 15:28:50 1996 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA16191; Wed, 13 Nov 96 15:28:48 EST Received: from dragon.lehman.com by kublai.lehman.com (4.1/Lehman Bros. V1.6) id AA28386; Wed, 13 Nov 96 15:28:39 EST Received: by dragon.lehman.com (SMI-8.6/Lehman Bros. V1.5) id PAA18081; Wed, 13 Nov 1996 15:28:39 -0500 Date: Wed, 13 Nov 1996 15:28:39 -0500 Message-Id: <199611132028.PAA18081@dragon.lehman.com> To: Terry Lambert Cc: stesin@gu.net (Andrew Stesin), hackers@freebsd.org, squid-users@nlanr.net, basch@lehman.com Subject: Re: Programming technique for non-forking servers? In-Reply-To: <199611131938.MAA22676@phaeton.artisoft.com> References: <199611131938.MAA22676@phaeton.artisoft.com> Reply-To: carson@lehman.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Unfortunately, your code fragment doesn't handle async connect properly. Error handling for async connect is non-trivial to write portably. Here are the possible statuses and select() returns: Connect Status Select Return -------------- ------------- inprogress nothing success write _and_, possibly, read (if data was written from the far side before select returned) failure read (and usually write as well, but some OS's seem to be broken) So, the question is, how do you tell if connect actually failed, and what the errno was? Good question... Here are your options: 1) getsockopt(fd, SOL_SOCKET, SO_ERROR, (void*)&err, &len) Nice, but some systems (HP?) don't support SO_ERROR 2) read(fd, buf, 0) Will either succeed or fail and set errno to the connect failure cause. Unless the system doesn't support 0-byte reads... or it doesn't return connect's error in errno... 3) getpeername() Works everywhere, but looses the connect error... Oh, and don't forget that sometimes connect() will return immediately, even if the socket is non-blocking, so you have to check for all possible states (success, non-blocking, or error). And be carefull, connect() can return different values for non-blocking on different OS's (EINPROGRESS, EWOULDBLOCK, etc.) -- Carson Gaspar -- carson@cs.columbia.edu carson@lehman.com http://www.cs.columbia.edu/~carson/home.html From owner-freebsd-hackers Wed Nov 13 12:30:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13740 for hackers-outgoing; Wed, 13 Nov 1996 12:30:42 -0800 (PST) Received: from hot.ee.lbl.gov (hot.ee.lbl.gov [131.243.1.42]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA13728 for ; Wed, 13 Nov 1996 12:30:37 -0800 (PST) Received: by hot.ee.lbl.gov (8.7.5/1.43r) id MAA15216; Wed, 13 Nov 1996 12:29:35 -0800 (PST) Message-Id: <199611132029.MAA15216@hot.ee.lbl.gov> To: Andrew Stesin Cc: hackers@freebsd.org, squid-users@nlanr.net Subject: Re: Programming technique for non-forking servers? In-reply-to: Your message of Wed, 13 Nov 1996 12:32:33 PST. Date: Wed, 13 Nov 1996 12:29:35 PST From: Jef Poskanzer Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I mean those like Squid, Harvest cached, probably Gated >(there is also a non-forking WWW server somewhere, but >I forgot it's name, for a pity). http://www.acme.com/software/thttpd/ I'm about to release a new version, too. --- Jef From owner-freebsd-hackers Wed Nov 13 12:53:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA15254 for hackers-outgoing; Wed, 13 Nov 1996 12:53:27 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA15248 for ; Wed, 13 Nov 1996 12:53:24 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id MAA07639; Wed, 13 Nov 1996 12:51:34 -0800 (PST) To: "Eric J. Schwertfeger" cc: Joe Greco , Christopher Masto , hackers@FreeBSD.org Subject: Re: Programming technique for non-forking servers? In-reply-to: Your message of "Wed, 13 Nov 1996 12:06:11 PST." Date: Wed, 13 Nov 1996 12:51:34 -0800 Message-ID: <7637.847918294@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > What I actually think Amiga programmers are missing is the shared > addressing space, so that two tasks/processes could easily handle the same > data structures, and seeing each other's modifications. While this isn't Which was the Amiga's greatest feature and it's greatest flaw. It made IPC and "shared library" calls fast as heck, but it also made it more than easily possible for an errant process to take down the whole machine and start the Guru to meditating. :-) Nothing comes for free. > find enough free time just to figure out the scope of what I want (feel > free to email me if you want to bias me :-). Darn, and I just got rid of > my Amiga RKM's this year. I still have a set, gathering dust. :) I gave my A2500 away a couple of years ago when I realized that I no longer had the time to even power it on. Jordan From owner-freebsd-hackers Wed Nov 13 13:05:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16156 for hackers-outgoing; Wed, 13 Nov 1996 13:05:50 -0800 (PST) Received: from fog.xinside.com (fog.xinside.com [199.164.187.39]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA16137 for ; Wed, 13 Nov 1996 13:05:39 -0800 (PST) Received: (from smap@localhost) by fog.xinside.com (8.7.6/8.7.3) id OAA13761; Wed, 13 Nov 1996 14:05:35 -0700 (MST) X-Authentication-Warning: fog.xinside.com: smap set sender to using -f Received: from xeno.xinside.com(199.164.187.221) by fog.xinside.com via smap (V1.3) id sma013759; Wed Nov 13 14:05:14 1996 Received: (from roell@localhost) by xeno.xinside.com (8.7.5/8.6.12) id OAA18130; Wed, 13 Nov 1996 14:05:14 -0700 (MST) Date: Wed, 13 Nov 1996 14:05:14 -0700 (MST) Message-Id: <199611132105.OAA18130@xeno.xinside.com> From: Thomas Roell To: Bruce Evans Cc: roell@crab.xinside.com, hackers@freebsd.org, jkh@time.cdrom.com Subject: Re: Is our ASYNC I/O support for ttys broken? In-Reply-To: <199611131734.EAA11083@godzilla.zeta.org.au> References: <199611131734.EAA11083@godzilla.zeta.org.au> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In your message of 14 November 1996 you write: > >Problem is that I really don't want to spawn subprocesses for > >io-stuff. On the other hand asynchronous input is really mandatory if > >you have a heavily loaded box and run CDE and/or OpenGL/PEX apps. > > Is this for the X server? It's already in the background and doesn't > have a controlling terminal (at least for XFree :-) so no additional > processes are required for handling one mouse. If the ioctl's would work as descrribed there would be no problem, but as I mentioned already, they don't. - Thomas -- Denver Office THOMAS ROELL /\ Das Reh springt hoch, +1(303)298-7478 X INSIDE INC / \/\ das Reh springt weit, 1801 Broadway, Suite 1710 / \ \/\ was soll es tun, Denver, CO 80202 roell@xinside.com / Oelch! \ \ es hat ja Zeit. From owner-freebsd-hackers Wed Nov 13 13:06:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16243 for hackers-outgoing; Wed, 13 Nov 1996 13:06:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA16219 for ; Wed, 13 Nov 1996 13:06:29 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA22868; Wed, 13 Nov 1996 13:54:55 -0700 From: Terry Lambert Message-Id: <199611132054.NAA22868@phaeton.artisoft.com> Subject: Re: Programming technique for non-forking servers? To: carson@lehman.com Date: Wed, 13 Nov 1996 13:54:54 -0700 (MST) Cc: terry@lambert.org, stesin@gu.net, hackers@freebsd.org, squid-users@nlanr.net, basch@lehman.com In-Reply-To: <199611132028.PAA18081@dragon.lehman.com> from "carson@lehman.com" at Nov 13, 96 03:28:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 3) getpeername() > > Works everywhere, but looses the connect error... > > Oh, and don't forget that sometimes connect() will return immediately, even > if the socket is non-blocking, so you have to check for all possible states > (success, non-blocking, or error). And be carefull, connect() can return > different values for non-blocking on different OS's (EINPROGRESS, > EWOULDBLOCK, etc.) If you are running a server, then the event *must* be that the data *is* available. Therefore you should *always* use blocking sockets. I think the async connect is not an issue, since as a server, all connections are *inbound*, not outbound. You use "accept", not "connect". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 13 13:11:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16686 for hackers-outgoing; Wed, 13 Nov 1996 13:11:48 -0800 (PST) Received: from ravenock.cybercity.dk (disn60.cybercity.dk [194.16.57.60]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA16676 for ; Wed, 13 Nov 1996 13:11:34 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.2/8.7.3) id WAA09449; Wed, 13 Nov 1996 22:12:29 +0100 (MET) Message-Id: <199611132112.WAA09449@ravenock.cybercity.dk> Subject: Re: how to make screen snapshots of FreeBSD floppy installation ? To: andreas@klemm.gtn.com (Andreas Klemm) Date: Wed, 13 Nov 1996 22:12:28 +0100 (MET) From: "Soren Schmidt" Cc: hackers@FreeBSD.org In-Reply-To: from "Andreas Klemm" at Nov 13, 96 09:00:08 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Andreas Klemm who wrote: > > Does somebody have an idea how to make color snapshots of the > system installation ? If its when the system is up and running, you can make a little program that snarfs the video memory, and then convert the attributes to the given colorprinters language. I once had a screen print function on my TODO list for syscons, but well... If its under a genuine installation, hmm, that takes some "interesting" code hacks, or a color camera :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 13 13:17:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16961 for hackers-outgoing; Wed, 13 Nov 1996 13:17:40 -0800 (PST) Received: from helmholtz.salk.edu (helmholtz.salk.edu [198.202.70.34]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA16955 for ; Wed, 13 Nov 1996 13:17:34 -0800 (PST) Received: from pauling.salk.edu (pauling [198.202.70.108]) by helmholtz.salk.edu (8.7.5/8.7.3) with SMTP id NAA29577 for ; Wed, 13 Nov 1996 13:17:02 -0800 (PST) Date: Wed, 13 Nov 1996 13:16:48 -0800 (PST) From: Tom Bartol To: hackers@freebsd.org Subject: 100BT cards for FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, I'm looking for an opinion on which 100/10BT card works best on FreeBSD. Does anyone care to give me a recommendation? Thanx, Tom From owner-freebsd-hackers Wed Nov 13 13:28:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17415 for hackers-outgoing; Wed, 13 Nov 1996 13:28:05 -0800 (PST) Received: from lehman.Lehman.COM (lehman.Lehman.COM [192.147.66.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA17393 for ; Wed, 13 Nov 1996 13:27:50 -0800 (PST) From: carson@lehman.com Received: (from smap@localhost) by lehman.Lehman.COM (8.6.12/8.6.12) id QAA22532; Wed, 13 Nov 1996 16:27:24 -0500 Received: from relay.mail.lehman.com(192.9.140.112) by lehman via smap (V1.3) id tmp022515; Wed Nov 13 16:27:21 1996 Received: from kublai.lehman.com by relay.lehman.com (4.1/LB-0.6) id AA21429; Wed, 13 Nov 96 16:27:17 EST Received: from dragon.lehman.com by kublai.lehman.com (4.1/Lehman Bros. V1.6) id AA01572; Wed, 13 Nov 96 16:27:14 EST Received: by dragon.lehman.com (SMI-8.6/Lehman Bros. V1.5) id QAA18882; Wed, 13 Nov 1996 16:27:13 -0500 Date: Wed, 13 Nov 1996 16:27:13 -0500 Message-Id: <199611132127.QAA18882@dragon.lehman.com> To: Terry Lambert Cc: stesin@gu.net, hackers@freebsd.org, squid-users@nlanr.net, basch@lehman.com Subject: Re: Programming technique for non-forking servers? In-Reply-To: <199611132054.NAA22868@phaeton.artisoft.com> References: <199611132028.PAA18081@dragon.lehman.com> <199611132054.NAA22868@phaeton.artisoft.com> Reply-To: carson@lehman.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Terry" == Terry Lambert writes: Terry> I think the async connect is not an issue, since as a server, all Terry> connections are *inbound*, not outbound. You use "accept", not Terry> "connect". True. Unless you're a proxy server (like squid). -- Carson Gaspar -- carson@cs.columbia.edu carson@lehman.com http://www.cs.columbia.edu/~carson/home.html From owner-freebsd-hackers Wed Nov 13 13:59:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19737 for hackers-outgoing; Wed, 13 Nov 1996 13:59:24 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA19716 for ; Wed, 13 Nov 1996 13:59:14 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA24088; Wed, 13 Nov 1996 15:58:10 -0600 From: Joe Greco Message-Id: <199611132158.PAA24088@brasil.moneng.mei.com> Subject: Re: 100BT cards for FreeBSD To: bartol@salk.edu (Tom Bartol) Date: Wed, 13 Nov 1996 15:58:10 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: from "Tom Bartol" at Nov 13, 96 01:16:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi all, > > I'm looking for an opinion on which 100/10BT card works best on FreeBSD. > Does anyone care to give me a recommendation? > > Thanx, I am partial to the SMC PCI EtherPower 10/100 cards. "Work great". ... JG From owner-freebsd-hackers Wed Nov 13 14:21:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21265 for hackers-outgoing; Wed, 13 Nov 1996 14:21:58 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21258 for ; Wed, 13 Nov 1996 14:21:51 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id OAA03035; Wed, 13 Nov 1996 14:21:43 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id JAA16095; Thu, 14 Nov 1996 09:21:26 +1100 From: Julian Assange Message-Id: <199611132221.JAA16095@suburbia.net> Subject: Re: Programming technique for non-forking servers? To: stesin@gu.net (Andrew Stesin) Date: Thu, 14 Nov 1996 09:21:26 +1100 (EST) Cc: michaelh@cet.co.jp, hackers@freebsd.org In-Reply-To: from "Andrew Stesin" at Nov 13, 96 05:03:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Speaking of threads, I noticed that the pthreads version of libc isn't built at all by default. Can we change this behavior, to exercise the code a little and to encourage development? -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Wed Nov 13 14:28:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21701 for hackers-outgoing; Wed, 13 Nov 1996 14:28:51 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21681 for ; Wed, 13 Nov 1996 14:28:28 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id OAA03086; Wed, 13 Nov 1996 14:28:19 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id JAA16234; Thu, 14 Nov 1996 09:27:56 +1100 From: Julian Assange Message-Id: <199611132227.JAA16234@suburbia.net> Subject: Re: Programming technique for non-forking servers? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 14 Nov 1996 09:27:56 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611131448.IAA23190@brasil.moneng.mei.com> from "Joe Greco" at Nov 13, 96 08:48:55 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In the case of a "complex" server, i.e. something like an Xserver or > MUD, but probably not a Web server, you probably need to use state machine > concepts. This is not "difficult", the only real problem is mastering > the concept of state machines. > The problem with user-level state machines or multi-threading is that it doesn't take advantage of multiple cpu's. Kernel level support for threading may address this. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Wed Nov 13 14:30:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21853 for hackers-outgoing; Wed, 13 Nov 1996 14:30:43 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21815 for ; Wed, 13 Nov 1996 14:30:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA23015; Wed, 13 Nov 1996 15:18:46 -0700 From: Terry Lambert Message-Id: <199611132218.PAA23015@phaeton.artisoft.com> Subject: Re: Programming technique for non-forking servers? To: carson@lehman.com Date: Wed, 13 Nov 1996 15:18:46 -0700 (MST) Cc: terry@lambert.org, stesin@gu.net, hackers@freebsd.org, squid-users@nlanr.net, basch@lehman.com In-Reply-To: <199611132127.QAA18882@dragon.lehman.com> from "carson@lehman.com" at Nov 13, 96 04:27:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >>>>> "Terry" == Terry Lambert writes: > > Terry> I think the async connect is not an issue, since as a server, all > Terry> connections are *inbound*, not outbound. You use "accept", not > Terry> "connect". > > True. Unless you're a proxy server (like squid). You mean "an http client, like squid". 8-P. He said "server", specifically. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 13 15:21:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24503 for hackers-outgoing; Wed, 13 Nov 1996 15:21:46 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA24498 for ; Wed, 13 Nov 1996 15:21:43 -0800 (PST) Received: from localhost (root@localhost) by aries.bb.cc.wa.us (8.7.5/8.6.9) with SMTP id PAA06230 for ; Wed, 13 Nov 1996 15:16:21 -0800 (PST) Date: Wed, 13 Nov 1996 15:16:20 -0800 (PST) From: Chris Coleman X-Sender: root@aries To: hackers@freebsd.org Subject: sio buffer overflows Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I keep getting the message on the console: sio1: 88 more interupt-level buffer overflows (total 45678) It happens when ever someone dials up and uses ppp. Any suggestions as to how to fix it would be appreciated. when i do an netstat -i ppp0 shows up with alot of Ierrs, Usually 60% of the total Ipkts. I think these are related. :-( Chris Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor Death is life's way of telling you you're fired. From owner-freebsd-hackers Wed Nov 13 15:44:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26028 for hackers-outgoing; Wed, 13 Nov 1996 15:44:26 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA26006; Wed, 13 Nov 1996 15:44:16 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id PAA08342; Wed, 13 Nov 1996 15:44:22 -0800 (PST) To: announce@freebsd.org cc: hackers@freebsd.org Subject: FreeBSD 2.2-ALPHA is now available. Date: Wed, 13 Nov 1996 15:44:22 -0800 Message-ID: <8340.847928662@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: ftp://ftp.freebsd.org/pub/FreeBSD/2.2-ALPHA The ALPHA period for 2.2 will be approximately 3 weeks, starting today and running through December 5th. Please test the heck out of this release and report any problems to us, full instructions for which are in the README.TXT file - please read it if you haven't yet done so at any point in the last 3 years :-). After the testing period is over, we hope to be rolling FreeBSD 2.2-RELEASE no later than December 10th (us needing about a week to finish integrating any bug fixes or necessary changes). Shipping should commence to CDROM customers by January of 1997, barring any unforseen delays in the CD replication process. Thanks! Your 2.2 release engineers, Jordan & Poul-Henning 2.2-ALPHA release notes follow: RELEASE NOTES FreeBSD Release 2.2-ALPHA This is an ALPHA release of FreeBSD 2.2-RELEASE and is aimed primarily at release testers. Some parts of the documentation may not be updated yet and should be reported if and when seen. Naturally, any installation failures or crashes should also be reported ASAP by sending mail to bugs@freebsd.org or using the send-pr command (those preferring a WEB based interface can also see http://www.freebsd.org/send-pr.html). 0. What's new since 2.1.5-RELEASE ------------------------------------ Support for the SDL RISCom N2pci sync serial card. Support for Cyclades Cyclom-Y (multi-port async serial) PCI adaptors as well as multiple controllers and the 32-Y (if you are currently using the Cyclades serial adapter, you should re-make your /dev entries and remove the old ones). Updated support for ethernet adaptors which use the DEC DC21X4X chipset. Support for HP PC Lan+ cards (model numbers: 27247B and 27252A) The 3COM 3c590 / 3c595 drivers have improved considerably. You need only change your kernel settings *once* now, on initial startup from the floppy. They will be preserved on the subsequently installed kernel. Update to gcc 2.7.2.1 & add support for weak symbols. Many things moved/brought into /usr/src/contrib, updating and cleaning up the source tree accordingly. Support for compiled-in shared library ld paths. Update sgmlfmt to `instant'. Protection against the widely reported SYN attack. 2. Technical overview --------------------- FreeBSD is a freely available, full source 4.4 BSD Lite based release for Intel i386/i486/Pentium (or compatible) based PC's. It is based primarily on software from U.C. Berkeley's CSRG group, with some enhancements from NetBSD, 386BSD, and the Free Software Foundation. Since our release of FreeBSD 2.0 almost 2 years ago, the performance, feature set and stability of FreeBSD has improved dramatically. The largest change is a revamped VM system with a merged VM/file buffer cache that not only increases performance but reduces FreeBSD's memory footprint, making a 5MB configuration a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial-on-demand PPP, an improved SCSI subsystem, early ISDN support, support for FDDI and Fast Ethernet (100Mbit) adapters, improved support for the Adaptec 2940 (WIDE and narrow) and 3940 SCSI adaptors along with many hundreds of bug fixes. We've taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this (constantly evolving) process is especially welcome! In addition to the base distributions, FreeBSD offers a ported software collection with over 600 commonly sought-after programs. The list of ports ranges from http (WWW) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 6MB of storage, all ports being expressed as "deltas" to their original sources. This makes it much easier for us to update ports and greatly reduces the disk space demands made by the ports collection. To compile a port, you simply change to the directory of the program you wish to install, type make and let the system do the rest. The full original distribution for each port you build is retrieved dynamically off of CDROM or a local ftp site, so you need only enough disk space to build the ports you want. (Almost) every port is also provided as a pre-compiled "package" which can be installed with a simple command (pkg_add). See also the new Packages option in the Configuration menu for an especially convenient interface to the package collection. A number of additional documents which you may find helpful in the process of installing and using FreeBSD may now also be found in the /usr/share/doc directory. You may view the manuals with any HTML capable browser by saying: To read the handbook: file:/usr/share/doc/handbook/handbook.html To read the FAQ: file:/usr/share/doc/FAQ/FAQ.html You can also visit the master (and most frequently updated) copies at http://www.freebsd.org. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. There is an add-on package to the core distribution, for use only in the United States, that contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely (from outside the U.S.) exportable distribution of DES for our non-U.S. users also exists at ftp://ftp.internat.freebsd.org/pub/FreeBSD. If password security for FreeBSD is all you need and you have no requirement for copying encrypted passwords from different hosts (Suns, DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require! We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. If you're outside (or even inside) the U.S., give it a try! This snapshot also includes support for mixed password files - either DES or MD5 passwords will be accepted, making it easier to transition from one scheme to the other. 3. Supported Configurations --------------------------- FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus based PC's, ranging from 386sx to Pentium class machines (though the 386sx is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controller, network and serial cards is also provided. What follows is a list of all disk controllers and ethernet cards currently known to work with FreeBSD. Other configurations may also work, but we have simply not received any confirmation of this. 3.1. Disk Controllers --------------------- WD1003 (any generic MFM/RLL) WD1007 (any generic IDE/ESDI) IDE ATA Adaptec 1510 series ISA SCSI controllers (not for bootable devices) Adaptec 152x series ISA SCSI controllers Adaptec 154x series ISA SCSI controllers Adaptec 174x series EISA SCSI controller in standard and enhanced mode. Adaptec 274X/284X/2940/3940 (Narrow/Wide/Twin) series ISA/EISA/PCI SCSI controllers. Adaptec AIC-6260 and AIC-6360 based boards, which includes Adaptec AIC7850 on-board SCSI controllers. the AHA-152x and SoundBlaster SCSI cards. ** Note: You cannot boot from the SoundBlaster cards as they have no on-board BIOS, such being necessary for mapping the boot device into the system BIOS I/O vectors. They're perfectly usable for external tapes, CDROMs, etc, however. The same goes for any other AIC-6x60 based card without a boot ROM. Some systems DO have a boot ROM, which is generally indicated by some sort of message when the system is first powered up or reset, and in such cases you *will* also be able to boot from them. Check your system/board documentation for more details. [Note that Buslogic was formerly known as "Bustec"] Buslogic 545S & 545c Buslogic 445S/445c VLB SCSI controller Buslogic 742A, 747S, 747c EISA SCSI controller. Buslogic 946c PCI SCSI controller Buslogic 956c PCI SCSI controller NCR 53C810 and 53C825 PCI SCSI controller. NCR5380/NCR53400 ("ProAudio Spectrum") SCSI controller. DTC 3290 EISA SCSI controller in 1542 emulation mode. UltraStor 14F, 24F and 34F SCSI controllers. Seagate ST01/02 SCSI controllers. Future Domain 8xx/950 series SCSI controllers. WD7000 SCSI controller. With all supported SCSI controllers, full support is provided for SCSI-I & SCSI-II peripherals, including Disks, tape drives (including DAT) and CD ROM drives. The following CD-ROM type systems are supported at this time: (cd) SCSI interface (also includes ProAudio Spectrum and SoundBlaster SCSI) (mcd) Mitsumi proprietary interface (all models) (matcd) Matsushita/Panasonic (Creative SoundBlaster) proprietary interface (562/563 models) (scd) Sony proprietary interface (all models) (wcd) ATAPI IDE interface (experimental and should be considered ALPHA quality!). 3.2. Ethernet cards ------------------- Allied-Telesis AT1700 and RE2000 cards SMC Elite 16 WD8013 ethernet interface, and most other WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT based clones. SMC Elite Ultra is also supported. DEC EtherWORKS III NICs (DE203, DE204, and DE205) DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc) DEC FDDI (DEFPA/DEFEA) NICs Fujitsu MB86960A/MB86965A HP PC Lan+ cards (model numbers: 27247B and 27252A) Intel EtherExpress (not recommended due to driver instability) Intel EtherExpress Pro/100B PCI Fast Ethernet Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, and NE2100 ethernet interface. 3Com 3C501 cards 3Com 3C503 Etherlink II 3Com 3c505 Etherlink/+ 3Com 3C507 Etherlink 16/TP 3Com 3C509, 3C579, 3C589 (PCMCIA), 3C590 & 3C595 (PCI) Etherlink III Toshiba ethernet cards PCMCIA ethernet cards from IBM and National Semiconductor are also supported. Note that NO token ring cards are supported at this time as we're still waiting for someone to donate a driver for one of them. Any takers? 3.3. Misc --------- AST 4 port serial card using shared IRQ. ARNET 8 port serial card using shared IRQ. ARNET (now Digiboard) Sync 570/i high-speed serial. BOCA ATIO66 6 port serial card using shared IRQ. Cyclades Cyclom-y Serial Board. STB 4 port card using shared IRQ. SDL Communications Riscom/8 Serial Board. SDL Communications RISCom/N2 and N2pci high-speed sync serial boards. Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound and Roland MPU-401 sound cards. FreeBSD currently does NOT support IBM's microchannel (MCA) bus. 4. Obtaining FreeBSD -------------------- You may obtain FreeBSD in a variety of ways: 4.1. FTP/Mail You can ftp FreeBSD and any or all of its optional packages from `ftp.freebsd.org' - the official FreeBSD release site. For other locations that mirror the FreeBSD software see the file MIRROR.SITES. Please ftp the distribution from the site closest (in networking terms) to you. Additional mirror sites are always welcome! Contact admin@freebsd.org for more details if you'd like to become an official mirror site. If you do not have access to the internet and electronic mail is your only recourse, then you may still fetch the files by sending mail to `ftpmail@decwrl.dec.com' - putting the keyword "help" in your message to get more information on how to fetch files using this mechanism. Please do note, however, that this will end up sending many *tens of megabytes* through the mail and should only be employed as an absolute LAST resort! 4.2. CDROM FreeBSD 2.1.6-RELEASE and 2.2-RELEASE CDs may be ordered on CDROM from: Walnut Creek CDROM 4041 Pike Lane, Suite D Concord CA 94520 1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax) Or via the internet from orders@cdrom.com or http://www.cdrom.com. Their current catalog can be obtained via ftp from: ftp://ftp.cdrom.com/cdrom/catalog. Cost per -RELEASE CD is $39.95 or $24.95 with a FreeBSD subscription. FreeBSD 3.0-SNAP CDs are $29.95 or $14.95 with a FreeBSD-SNAP subscription (-RELEASE and -SNAP subscriptions are entirely seperate). With a subscription, you will automatically receive updates as they are released. Your credit card will be billed when each disk is shipped and you may cancel your subscription at any time without further obligation. Shipping (per order not per disc) is $5 in the US, Canada or Mexico and $9.00 overseas. They accept Visa, Mastercard, Discover, American Express or checks in U.S. Dollars and ship COD within the United States. California residents please add 8.25% sales tax. Should you be dissatisfied for any reason, the CD comes with an unconditional return policy. Reporting problems, making suggestions, submitting code ------------------------------------------------------- Your suggestions, bug reports and contributions of code are always valued - please do not hesitate to report any problems you may find (preferably with a fix attached, if you can!). The preferred method to submit bug reports from a machine with internet mail connectivity is to use the send-pr command or use the CGI script at http://www.freebsd.org/send-pr.html. Bug reports will be dutifully filed by our faithful bugfiler program and you can be sure that we'll do our best to respond to all reported bugs as soon as possible. Bugs filed in this way are also visible on our WEB site in the support section and are therefore valuable both as bug reports and as "signposts" for other users concerning potential problems to watch out for. If, for some reason, you are unable to use the send-pr command to submit a bug report, you can try to send it to: bugs@FreeBSD.org Otherwise, for any questions or suggestions, please send mail to: questions@FreeBSD.org Additionally, being a volunteer effort, we are always happy to have extra hands willing to help - there are already far more desired enhancements than we'll ever be able to manage by ourselves! To contact us on technical matters, or with offers of help, please send mail to: hackers@FreeBSD.org Please note that these mailing lists can experience *significant* amounts of traffic and if you have slow or expensive mail access and are only interested in keeping up with significant FreeBSD events, you may find it preferable to subscribe instead to: announce@FreeBSD.org All but the freebsd-bugs groups can be freely joined by anyone wishing to do so. Send mail to MajorDomo@FreeBSD.org and include the keyword `help' on a line by itself somewhere in the body of the message. This will give you more information on joining the various lists, accessing archives, etc. There are a number of mailing lists targeted at special interest groups not mentioned here, so send mail to majordomo and ask about them! 6. Acknowledgements ------------------- FreeBSD represents the cumulative work of many dozens, if not hundreds, of individuals from around the world who have worked very hard to bring you this release. It would be very difficult, if not impossible, to enumerate everyone who's contributed to FreeBSD, but nonetheless we shall try (in alphabetical order, of course). If you've contributed something substantive to us and your name is not mentioned here, please be assured that its omission is entirely accidental. Please contact hackers@FreeBSD.org for any desired updates to the lists that follow: The Computer Systems Research Group (CSRG), U.C. Berkeley. Bill Jolitz, for his initial work with 386BSD. The FreeBSD Core Team (in alphabetical order by last name): Satoshi Asami Andrey A. Chernov John Dyson Bruce Evans Justin Gibbs David Greenman Jordan K. Hubbard Poul-Henning Kamp Rich Murphey Gary Palmer Søren Schmidt Peter Wemm Garrett A. Wollman Jörg Wunsch The FreeBSD Development Team, excluding core team members (in alphabetical order by last name): Torsten Blum Gary Clark II Adam David Peter Dufault Frank Durda IV Julian Elischer Sean Eric Fagan Stefan Esser Bill Fenner John Fieber Lars Fredriksen Thomas Gellekum Thomas Graichen Rod Grimes James FitzGibbon John Hay Jeffrey Hsu Ugen J.S. Antsilevich Gary Jennejohn Andreas Klemm Warner Losh L Jonas Olsson Eric L. Hernes Scott Mace Atsushi Murai Mark Murray Alex Nash Masafumi NAKANE David E. O'Brien Andras Olah Steve Passe Bill Paul Joshua Peck Macdonald John Polstra Steve Price Mike Pritchard Doug Rabson James Raynard Geoff Rehmet Martin Renters Paul Richards Ollivier Robert Chuck Robey Dima Ruban Wolfram Schneider Andreas Schulz Karl Strickland Michael Smith Paul Traina Guido van Rooij Steven Wallace Nate Williams Jean-Marc Zucconi Additional FreeBSD helpers and beta testers: Coranth Gryphon Dave Rivers Kaleb S. Keithley Terry Lambert David Dawes Don Lewis Special mention to: Walnut Creek CDROM, without whose help (and continuing support) this release would never have been possible. Dermot McDonnell for his donation of a Toshiba XM3401B CDROM drive. Chuck Robey for his donation of a floppy tape streamer for testing. Larry Altneu and Wilko Bulte for providing us with Wangtek and Archive QIC-02 tape drives for testing and driver hacking. CalWeb Internet Services for the loan of a P6/200 machine for speedy package building. Everyone at Montana State University for their initial support. And to the many thousands of FreeBSD users and testers all over the world, without whom this release simply would not have been possible. We sincerely hope you enjoy this release of FreeBSD! The FreeBSD Core Team $Id: relnotes.hlp,v 1.17.2.1 1996/11/13 11:49:42 jkh Exp $ From owner-freebsd-hackers Wed Nov 13 16:32:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA28471 for hackers-outgoing; Wed, 13 Nov 1996 16:32:23 -0800 (PST) Received: from tyger.inna.net (root@tyger.inna.net [206.151.66.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA28368 for ; Wed, 13 Nov 1996 16:31:35 -0800 (PST) Received: from tyger.inna.net (jamie@tyger.inna.net [206.151.66.1]) by tyger.inna.net (8.7.3/8.7.3) with SMTP id TAA05935; Wed, 13 Nov 1996 19:34:06 -0500 (EST) Date: Wed, 13 Nov 1996 19:34:06 -0500 (EST) From: Jamie Bowden To: Tom Bartol cc: hackers@FreeBSD.org Subject: Re: 100BT cards for FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 13 Nov 1996, Tom Bartol wrote: I find the SMC 10/100 pci cards work without flaw, and extremely well. > > > Hi all, > > I'm looking for an opinion on which 100/10BT card works best on FreeBSD. > Does anyone care to give me a recommendation? > > Thanx, > > Tom > > > Jamie Bowden Network Administrator, TBI Ltd. From owner-freebsd-hackers Wed Nov 13 18:54:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA06872 for hackers-outgoing; Wed, 13 Nov 1996 18:54:39 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA06805 for ; Wed, 13 Nov 1996 18:53:20 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id CAA18346; Thu, 14 Nov 1996 02:52:53 GMT Date: Thu, 14 Nov 1996 11:52:53 +0900 (JST) From: Michael Hancock To: Andrew Stesin cc: FreeBSD Hackers Subject: Re: Programming technique for non-forking servers? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 13 Nov 1996, Andrew Stesin wrote: > But I have an impression that there's easier > to implement locking of shared memory and file > resources inside a single-process server than > with some kind of IPC. There is SysV IPC around, > but it has it's limitations. Using mmap() as a shared > memory pool? isn't so clear and transparent for me (at least > now), and generally isn't documented; so the question > remains opened, that's why I'm asking about > where a Fine Manual resides which should be read. I read about "4.4BSD" semaphores in the Frontiers book, they were described like this: value = mset(sem, WantMeToBlock); mclear(sem); msleep(sem); mwakeup(sem); You would use mmap to create a shared memory region and use the flag HASSEMAPHORE. mset and mclear would be implemented as lib functions because Intel does have an atomic test and set. A check could be done on the sem without making a system call. These guys don't exist. I wonder where Vahalia got his information from. Regards, Mike From owner-freebsd-hackers Wed Nov 13 18:57:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA07057 for hackers-outgoing; Wed, 13 Nov 1996 18:57:56 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA07051 for ; Wed, 13 Nov 1996 18:57:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id SAA09566; Wed, 13 Nov 1996 18:55:53 -0800 (PST) Message-Id: <199611140255.SAA09566@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: michaelh@cet.co.jp, ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.org Subject: Re: Even more info on daily panics... In-reply-to: Your message of "Wed, 13 Nov 1996 10:32:19 MST." <199611131732.KAA22431@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 13 Nov 1996 18:55:53 -0800 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> I would also like to hear an explaination of how it is possible, after the >> patch to vrele to prevent it from going negative, for a vnode with a non-zero >> v_usecount can be on the freelist in the first place. > >Please check my previous mail... > >There is a race condition caused by the fact that the vnode reclamation >is "smeared" across the VFS/FS boundry layer. It is not obvious unless >you consider interfaces to represent access points for automatons >instead of simply functional abstractions of object complexity (ie: it >is an artifact of layering errors). Terry, the problem has nothing to do with functional abstractions, automatons, layering errors, execution contexts, interface boundries, race conditions, or little green men from Alpha Centauri. Vnodes on the free list are not allowed to have non-zero v_usecount's. Vnodes can not be used without first gaining a reference (v_usecount++). Vnodes are removed from the freelist when this happens. I noticed last night that there is a v_usecount++ in the vnode_pager that could cause the problem that David is reporting if an object allocation was attempted for a vnode without first gaining a reference to it. We've had bugs like this before, so it should come as no surprise. David, please apply the attached patch and see if your system trips over it. Thanks. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project Index: vnode_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v retrieving revision 1.65 diff -c -r1.65 vnode_pager.c *** vnode_pager.c 1996/10/17 02:49:35 1.65 --- vnode_pager.c 1996/11/13 05:56:50 *************** *** 148,153 **** --- 148,155 ---- else object->flags = 0; + if (vp->v_usecount == 0) + panic("vnode_pager_alloc: no vnode reference"); /* * Hold a reference to the vnode and initialize object data. */ From owner-freebsd-hackers Wed Nov 13 20:02:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10418 for hackers-outgoing; Wed, 13 Nov 1996 20:02:08 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA10403 for ; Wed, 13 Nov 1996 20:01:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA23432; Wed, 13 Nov 1996 20:49:56 -0700 From: Terry Lambert Message-Id: <199611140349.UAA23432@phaeton.artisoft.com> Subject: Re: Even more info on daily panics... To: dg@root.com Date: Wed, 13 Nov 1996 20:49:56 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.org In-Reply-To: <199611140255.SAA09566@root.com> from "David Greenman" at Nov 13, 96 06:55:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Terry, the problem has nothing to do with functional abstractions, > automatons, layering errors, execution contexts, interface boundries, > race conditions, or little green men from Alpha Centauri. > Vnodes on the free list are not allowed to have non-zero v_usecount's. That's not what the code says. The code inserts them on list wrap. > Vnodes can not be used without first gaining a reference (v_usecount++). > Vnodes are removed from the freelist when this happens. I noticed last > night that there is a v_usecount++ in the vnode_pager that could cause > the problem that David is reporting if an object allocation was attempted > for a vnode without first gaining a reference to it. We've had bugs like > this before, so it should come as no surprise. > David, please apply the attached patch and see if your system trips > over it. Thanks. This is a "horse out of the barn" 'fix'. It will cause a panic, but the stack trace will *still* not include the cause of the panic in the call list. The problem is clearly a bogus list insertion. Equally as clearly, a bogus list insertion in possible in the current code because of the lock race potentially causing a list wrap during the allocation to extend sleeping through a valid vrele. This is possible because the lock is not a lock on list access, it is a lock across interface access... the lock is held in vclean above the VOP layer and in valloc below the VOP layer. The *correct* soloution is to panic the bogus list insertion at the time of the insertion attempt (in vrele) so that the stack reflects who is responsible for the bogus insertion. With an obviously bad parameter, it is apparent where the parameter orginated... from the insertion/list expansion race. It is a bogus layering abstraction that permits such code to be written in the first place. If the abstraction were correct, the race window would not exist. Bluntly: a panic occurs, therefore the code which is the distal cause of the panic is erroneous. Under no circumstances, short of real hardware failure, should it be possible to panic the system. If you look at the BSD4.4-Lite2 code, you will see they cleaned this up (using a fix just as kludgy as my one liner) by using kern_lock.c functions instead of smearing the lock state. Their error is in keeping the calldown interface, which leaves a potential for a deadly embrace deadlock across the interface boundry (at least after you factor in the cache unification -- the BSD4.4-Lite2 code can't itself suffer from this deadlock because it lacks the necessary concurrency). Going to a veto interface would fix this problem by unwinding the EWOULDBLOCK state by returning up the stack instead of panic'ing. Put in a retry loop, and your not as elegant as a computation of transitive closure, but at least you don't panic or lock up the damn machine when you hit a preventable resource conflict. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Nov 13 20:42:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA12807 for hackers-outgoing; Wed, 13 Nov 1996 20:42:13 -0800 (PST) Received: from ccs.sogang.ac.kr (ccs.sogang.ac.kr [163.239.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA12797 for ; Wed, 13 Nov 1996 20:42:10 -0800 (PST) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.8.2/Sogang) id NAA10477; Thu, 14 Nov 1996 13:36:59 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA05620; Thu, 14 Nov 96 13:40:25 KST From: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Message-Id: <9611140440.AA05620@cslsun10.sogang.ac.kr> Subject: data segment To: freebsd-hackers@FreeBSD.ORG Date: Thu, 14 Nov 1996 13:40:24 +0900 (KST) Cc: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hello there. i major in computer science in sogang Univ. Korea. and i enjor to know about FreeBSD kernel source's memory management but i don't know below 1. if process reference his virtual memory, how to distinguish the text segment and data sehment. i don't how to know please send me a good messages. From owner-freebsd-hackers Wed Nov 13 21:00:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA13441 for hackers-outgoing; Wed, 13 Nov 1996 21:00:15 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA13431 for ; Wed, 13 Nov 1996 21:00:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id UAA09784; Wed, 13 Nov 1996 20:58:13 -0800 (PST) Message-Id: <199611140458.UAA09784@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: michaelh@cet.co.jp, ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.org Subject: Re: Even more info on daily panics... In-reply-to: Your message of "Wed, 13 Nov 1996 20:49:56 MST." <199611140349.UAA23432@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 13 Nov 1996 20:58:13 -0800 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Terry, the problem has nothing to do with functional abstractions, >> automatons, layering errors, execution contexts, interface boundries, >> race conditions, or little green men from Alpha Centauri. > >> Vnodes on the free list are not allowed to have non-zero v_usecount's. > >That's not what the code says. > >The code inserts them on list wrap. What "list wrap"? What are you talking about? >The problem is clearly a bogus list insertion. No, it isn't. >Equally as clearly, a bogus list insertion in possible in the current >code because of the lock race potentially causing a list wrap during >the allocation to extend sleeping through a valid vrele. What "lock race potential"? The only one I know about is fixed by the mutexes I added to the various filesystems 1.5 years ago. ...and it doesn't matter anyway. >This is possible because the lock is not a lock on list access, it is >a lock across interface access... the lock is held in vclean above >the VOP layer and in valloc below the VOP layer. Look, Terry, none of this matters!!! The panic is caused by a vnode on the freelist having a non-zero v_usecount. That *can't* happen when vnode references are gained via vget and released via vrele. It can *only* (other than memory corruption of course) happen if vnode_pager_alloc() is passed a vnode without a reference (v_usecount == 0). If that is the case, then we have a simple reference count problem and the traceback will point to it. >The *correct* soloution is to panic the bogus list insertion at the >time of the insertion attempt (in vrele) so that the stack reflects >who is responsible for the bogus insertion. With an obviously bad >parameter, it is apparent where the parameter orginated... from the >insertion/list expansion race. We already do that. Look at the code. >It is a bogus layering abstraction that permits such code to be >written in the first place. If the abstraction were correct, the >race window would not exist. Fine. IT DOESN'T MATTER!!! I don't like spelling errors in comments, either. Someday we'll fix it, and when that day happens, we'll have a whole new set of vnode reference count bugs to deal with. Look, I encourage comments when they are constructive and work toward a fix. David's machine is crashing and he's looking for a fix. We're right on the heals of a release and I don't have the time nor the energy to get caught up in Terry's grand VFS design model. For what's it's worth, I agree with you that the current model of vnode reference/release is wrong, and we'll likely change it at some point. Doing so is very difficult, however, and arguing about it now doesn't stop David's machine from panicing. These are long-term design goals that span over the next few years and are not germane to finding and fixing this problem. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Wed Nov 13 21:12:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA13904 for hackers-outgoing; Wed, 13 Nov 1996 21:12:29 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA13890; Wed, 13 Nov 1996 21:12:24 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id VAA21121; Wed, 13 Nov 1996 21:12:00 -0800 (PST) From: "Rodney W. Grimes" Message-Id: <199611140512.VAA21121@GndRsh.aac.dev.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: <8340.847928662@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 13, 96 03:44:22 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 13 Nov 1996 21:11:58 -0800 (PST) Cc: announce@freebsd.org, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ... > DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc) I know of _no_ current production DC21140 card that will work with the if_de.c driver. SMC has discontiued the SMC9332DST, and makeing the SMC9332BDT work requires hacking the driver. This is also true of the D-Link DFE-500TX, Kingston KNE100TX, and the Compex board. Basically all of the vendors are converting to the new PHY interface, and the driver just doesn't seem to cope with this fact without hacking it up. :-( :-(. > > BOCA ATIO66 6 port serial card using shared IRQ. BOCA BB2016 16 port serial card using shared IRQ (Has neen supported for ages) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-hackers Wed Nov 13 21:23:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA14316 for hackers-outgoing; Wed, 13 Nov 1996 21:23:06 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA14310 for ; Wed, 13 Nov 1996 21:22:52 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id AAA02018; Thu, 14 Nov 1996 00:20:36 -0500 (EST) From: "John S. Dyson" Message-Id: <199611140520.AAA02018@dyson.iquest.net> Subject: Re: data segment To: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Date: Thu, 14 Nov 1996 00:20:36 -0500 (EST) Cc: freebsd-hackers@FreeBSD.org, cskim@cslsun10.sogang.ac.kr In-Reply-To: <9611140440.AA05620@cslsun10.sogang.ac.kr> from "Kim Chang Seob" at Nov 14, 96 01:40:24 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > hello there. > i major in computer science in sogang Univ. Korea. > and i enjor to know about FreeBSD kernel source's memory management > but i don't know below > 1. if process reference his virtual memory, > how to distinguish the text segment and data sehment. > i don't how to know > FreeBSD (internally) distinguishes between .text, .data, .bss by mechanisms that are not named ".text" handler, ".data" handler, and ".bss" handler :-). It does so by the attributes of the segments. Take a look at the code in /sys/kern/imgact_aout.c for how the segments are set-up. I understand that it can be confusing, but the names ".text", ".data", and ".bss" are historical, and mostly imply certain segment attributes. Internally, FreeBSD can handle almost any reasonable arbitrary mapping of a file into memory, and then run it. FreeBSD has the appropriate mechanisms for copy on write also. When .data is mapped into memory, there is a special flag set that says that pages in that segment should copied if modified. The copied page is placed into the process address space, and the system leaves the original page in .data unmodified. Actually, the .text segment is mapped copy on write also, but there is no write access allowed normally. This allows debuggers to set breakpoints in the process image without destroying the file that contains the executable. John dyson@freebsd.org From owner-freebsd-hackers Wed Nov 13 21:46:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA15784 for hackers-outgoing; Wed, 13 Nov 1996 21:46:52 -0800 (PST) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA15779 for ; Wed, 13 Nov 1996 21:46:48 -0800 (PST) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id VAA09618 for ; Wed, 13 Nov 1996 21:48:00 -0800 Date: Wed, 13 Nov 1996 21:47:59 -0800 (PST) From: Veggy Vinny To: hackers@FreeBSD.ORG Subject: Info needed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We have two machines at Gaianet. earth and mars and we're experiencing the following but don't know what they mean exactly, can anyone help? Scrolling off earth's screen: earth routed[57]: punt RTM_LOSING without gateway When mars comes up, it identifies all the hardware, does the ifconfig for ed1 and lo0, does the gateway and all that stuff. It then says starting routing daemons: routed. This is where it hangs indefinitely until I hit ctrl-c. Then it does clearing /tmp, recording kernel -c changes, and then does the daemons. Vince GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin From owner-freebsd-hackers Wed Nov 13 22:52:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA18618 for hackers-outgoing; Wed, 13 Nov 1996 22:52:38 -0800 (PST) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA18612 for ; Wed, 13 Nov 1996 22:52:35 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.2/8.7.3) id RAA07940; Thu, 14 Nov 1996 17:52:08 +1100 (EST) From: David Dawes Message-Id: <199611140652.RAA07940@rf900.physics.usyd.edu.au> Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: <199611140512.VAA21121@GndRsh.aac.dev.com> from "Rodney W. Grimes" at "Nov 13, 96 09:11:58 pm" To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Thu, 14 Nov 1996 17:52:07 +1100 (EST) Cc: jkh@time.cdrom.com, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc) > >I know of _no_ current production DC21140 card that will work with >the if_de.c driver. SMC has discontiued the SMC9332DST, and makeing >the SMC9332BDT work requires hacking the driver. This is also true >of the D-Link DFE-500TX, Kingston KNE100TX, and the Compex board. I have a Digital DE500-AA here which the driver reports uses the DC21140A. It works fine with 2.2 (but not with 2.1.5). The only question I have about it is, is it supposed to auto-detect full duplex 100Mb/s connections? It reports: de0 rev 32 int a irq 10 on pci0:8 de0: DE500-AA DC21140A [10-100Mb/s] pass 2.0 de0: address 00:00:f8:01:e7:8f de0: link up: enabling 100baseTX port regadless of whether the other end is full or half duplex. The output error rate seems higher when the other end is full duplex (BTW, the other end is a 100TX card in a Cisco Catalyst 3000 switch). David From owner-freebsd-hackers Wed Nov 13 23:06:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA19511 for hackers-outgoing; Wed, 13 Nov 1996 23:06:32 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA19487 for ; Wed, 13 Nov 1996 23:06:25 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id SAA03327; Thu, 14 Nov 1996 18:04:30 +1100 Date: Thu, 14 Nov 1996 18:04:30 +1100 From: Bruce Evans Message-Id: <199611140704.SAA03327@godzilla.zeta.org.au> To: bde@zeta.org.au, roell@crab.xinside.com Subject: Re: Is our ASYNC I/O support for ttys broken? Cc: hackers@FreeBSD.org, jkh@time.cdrom.com Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >If the ioctl's would work as descrribed there would be no problem, but >as I mentioned already, they don't. Actually, they do: ERRORS Fcntl() will fail if: ... In addition, if fd refers to a descriptor open on a terminal device (as opposed to a descriptor open on a socket), a cmd of F_SETOWN can fail for the same reasons as in tcsetpgrp(3), and a cmd of F_GETOWN for the rea- sons as stated in tcgetpgrp(3). Bruce From owner-freebsd-hackers Thu Nov 14 00:05:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA22312 for hackers-outgoing; Thu, 14 Nov 1996 00:05:54 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.40]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA22287; Thu, 14 Nov 1996 00:05:06 -0800 (PST) Received: from altos.rnd.runnet.ru (altos.rnd.runnet.ru [195.208.248.253]) by altos.rnd.runnet.ru (8.7.5/8.7.3) with SMTP id LAA26555; Thu, 14 Nov 1996 11:03:12 +0300 (MSK) Message-ID: <328AD23F.41C67EA6@run.net> Date: Thu, 14 Nov 1996 08:03:11 +0000 From: Maxim Bolotin Organization: Rostov State University Computer Center X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: alex@yahoo.com CC: hardware@freebsd.org, hackers@freebsd.org, max@rnd.runnet.ru Subject: Re: FreeBSD as Terminal Server References: <199611140356.TAA06704@honker.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alexander Winske wrote: > > Howdy, > I'm looking to set up a largish terminal server on > a FreeBSD box. (I want to log console output and allow > console sessions with approx. 75-100 hosts). > > Can anyone out there recommend a flavor of multiport > serial card that will allow me to have that many ports? > I would think that they wouldn't have to be doing more than > 2400 baud each, if that makes any difference... > > tia, > Alex I think you can use DigiBoard PC/16i or PC/16e. It has 16 ports with speed up to 115K. The model PC/16e is cheeper than other 'cause it has only 64K buffer , other has 128K-512K. The driver for 2.1.5, stable is work weel, Now I port it for 2.2, I send it to author (Serge A. Babkin ) He said me he'll send it to Bruce Evans. New version work very well. I'm using PC/16e with 4 leased lines ( 28K ), 6 terminals (9600K) and printer (9600K). All It work under 2.2-SNAP-141096. Max. -- Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 From owner-freebsd-hackers Thu Nov 14 00:06:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA22384 for hackers-outgoing; Thu, 14 Nov 1996 00:06:20 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA22368 for ; Thu, 14 Nov 1996 00:06:17 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id AAA21397; Thu, 14 Nov 1996 00:05:19 -0800 (PST) From: "Rodney W. Grimes" Message-Id: <199611140805.AAA21397@GndRsh.aac.dev.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: <199611140652.RAA07940@rf900.physics.usyd.edu.au> from David Dawes at "Nov 14, 96 05:52:07 pm" To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Thu, 14 Nov 1996 00:05:19 -0800 (PST) Cc: jkh@time.cdrom.com, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc) > > > >I know of _no_ current production DC21140 card that will work with > >the if_de.c driver. SMC has discontiued the SMC9332DST, and makeing > >the SMC9332BDT work requires hacking the driver. This is also true > >of the D-Link DFE-500TX, Kingston KNE100TX, and the Compex board. > > I have a Digital DE500-AA here which the driver reports uses the DC21140A. > It works fine with 2.2 (but not with 2.1.5). The only question I have > about it is, is it supposed to auto-detect full duplex 100Mb/s connections? > It reports: > > de0 rev 32 int a irq 10 on pci0:8 > de0: DE500-AA DC21140A [10-100Mb/s] pass 2.0 > de0: address 00:00:f8:01:e7:8f > de0: link up: enabling 100baseTX port > > regadless of whether the other end is full or half duplex. The output > error rate seems higher when the other end is full duplex (BTW, the > other end is a 100TX card in a Cisco Catalyst 3000 switch). >From a discussion I just had with David the if_de.c driver does not correctly do full duplex, turn off full duplix on your Catalyst port and things should be much happier. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-hackers Thu Nov 14 00:18:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA23011 for hackers-outgoing; Thu, 14 Nov 1996 00:18:06 -0800 (PST) Received: from melb.werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA23005 for ; Thu, 14 Nov 1996 00:18:01 -0800 (PST) Received: (from uucp@localhost) by melb.werple.net.au (8.7.6/8.7.3/2) with UUCP id RAA09226; Thu, 14 Nov 1996 17:48:20 +1100 (EST) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id JAA18214; Thu, 14 Nov 1996 09:31:32 +1100 (EST) From: John Birrell Message-Id: <199611132231.JAA18214@freebsd1.cimlogic.com.au> Subject: Re: Programming technique for non-forking servers? To: stesin@gu.net (Andrew Stesin) Date: Thu, 14 Nov 1996 09:31:31 +1100 (EST) Cc: michaelh@cet.co.jp, hackers@freebsd.org In-Reply-To: from Andrew Stesin at "Nov 13, 96 05:03:40 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Andrew Stesin wrote: > But I have an impression that there's easier > to implement locking of shared memory and file > resources inside a single-process server than > with some kind of IPC. Sounds like a perfect application for POSIX threads. The initial thread accepts incoming connections, then creates a worker thread for each connection. We do our shared memory servers that way, however, we still use SysV shared memory. Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Thu Nov 14 00:56:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA24931 for hackers-outgoing; Thu, 14 Nov 1996 00:56:38 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA24926 for ; Thu, 14 Nov 1996 00:56:33 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id DAA24960 for ; Thu, 14 Nov 1996 03:56:35 -0500 (EST) Date: Thu, 14 Nov 1996 03:56:34 -0500 (EST) From: "Marc G. Fournier" Reply-To: "Marc G. Fournier" To: hackers@freebsd.org Subject: Sockets question... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... I'm getting what I think is an odd result trying to send data from one machine to another machine over a TCP socket. I've gone through the "Unix Network Programming" book several times, trying to see if I can figure what I screwed up, but can't see anything. Basically, the server opens up a binary file and sends the data to the client. The client is connecting to the server no problem, but I'm don't seem to be able to send >79 bytes across the socket, which to me seems *very* inefficent, and "the book" is using examples of 512bytes, so I figure its something I'm doing wrong. I've tried setting MAXBYTES at 1024, 256, 128, and 80...and 80 seems to be the only value that I can get the complete image across the socket. Ack...okay, before I sent this off, I tested one more...512... 512 and 80 both give me the results I want... So, did I miss something in the book that deals with this? One of the things that the book does mention is a potential 4k limit, but I would have assumed that if 512 worked, anything below it would as well...:( I'm going to re-read the pertinent section of the book to see if it is something I missed, but if not...can anyone tell me *why* this doesn't work as I would have expected? Thanks... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Thu Nov 14 01:23:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA25805 for hackers-outgoing; Thu, 14 Nov 1996 01:23:07 -0800 (PST) Received: from nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA25798 for ; Thu, 14 Nov 1996 01:23:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id BAA05530 for ; Thu, 14 Nov 1996 01:22:59 -0800 (PST) Date: Thu, 14 Nov 1996 01:22:59 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: FreeBSD Hackers Subject: gated problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... I'm working on creating a terminal server and plan on supporting both dynamic ip addresses plus connecting remote networks... I am trying to get gated to run so that I don't have to worry about people messing with my local routing tables... so far it runs run but as soon as it gets an interface up event it dumps core... I've built gated with debugging symbols and try to run gdb on it... but it doesn't seem to include the data from the actual program... i.e. any data that I try to access returns not able to access memory... it seems to be more of a problem with a special handling of the ppp/sl devices as if I ifconfig ppp0 192.168.0.30 192.168.3.1 up it will dump core as with sl0... but if I do something like ifconfig ed0 alias 192.168.3.1 netmask 255.255.255.0, the route gets properly propagated to my other host and gated doesn't dump core... I've tried to build the latest gated (3.6Alpha2) but I currently have no idea how to complete the build... any ideas would be greatly apriciated... thanks for you help.. ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Thu Nov 14 01:23:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA25819 for hackers-outgoing; Thu, 14 Nov 1996 01:23:11 -0800 (PST) Received: from melb.werple.net.au (melb.werple.net.au [203.9.190.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA25803 for ; Thu, 14 Nov 1996 01:23:04 -0800 (PST) Received: (from uucp@localhost) by melb.werple.net.au (8.7.6/8.7.3/2) with UUCP id SAA09843; Thu, 14 Nov 1996 18:05:36 +1100 (EST) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.7.5/8.7.3) id SAA04355; Thu, 14 Nov 1996 18:04:49 +1100 (EST) From: John Birrell Message-Id: <199611140704.SAA04355@freebsd1.cimlogic.com.au> Subject: Re: Programming technique for non-forking servers? To: proff@suburbia.net (Julian Assange) Date: Thu, 14 Nov 1996 18:04:48 +1100 (EST) Cc: stesin@gu.net, michaelh@cet.co.jp, hackers@FreeBSD.org In-Reply-To: <199611132221.JAA16095@suburbia.net> from Julian Assange at "Nov 14, 96 09:21:26 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Julian Assange wrote: > Speaking of threads, I noticed that the pthreads version of libc isn't > built at all by default. Can we change this behavior, to exercise the > code a little and to encourage development? > I'm working on a version that shares as much of libc as possible, leaving the thread specific stuff in libpthread (rather than building a separate library that duplicates stuff that could be shared). I still haven't come up with a working version that is acceptable to FreeBSD.org. Even if I succeed, you won't see anything until 2.2 is safely out the door. And I'm over due in writing that paper for the FSF conference. Sigh. Regards, -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 6900 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137 From owner-freebsd-hackers Thu Nov 14 02:48:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA29832 for hackers-outgoing; Thu, 14 Nov 1996 02:48:07 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA29827 for ; Thu, 14 Nov 1996 02:48:03 -0800 (PST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id CAA13413 for ; Thu, 14 Nov 1996 02:47:47 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id VAA22350 for hackers@freebsd.org; Thu, 14 Nov 1996 21:47:10 +1100 From: Julian Assange Message-Id: <199611141047.VAA22350@suburbia.net> Subject: status of ports To: hackers@freebsd.org Date: Thu, 14 Nov 1996 21:47:07 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've uploaded several ports to incoming and sent the appropriate pr's over the last few months, yet haven't seen inclusion in current /usr/ports. Is someone actually monitoring incoming? -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Thu Nov 14 03:07:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00897 for hackers-outgoing; Thu, 14 Nov 1996 03:07:41 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA00892 for ; Thu, 14 Nov 1996 03:07:37 -0800 (PST) Received: from truk.brandinnovators.com (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 25283 on Thu, 14 Nov 1996 11:44:15 +0100; id LAA25283 efrom: hans@truk.brandinnovators.com; eto: hackers@freebsd.org Received: by truk.brandinnovators.com (8.6.12/BI96070101) for id KAA15729; Thu, 14 Nov 1996 10:05:08 +0100 Message-Id: <199611140905.KAA15729@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: Re: Is our ASYNC I/O support for ttys broken? To: hackers@freebsd.org Date: Thu, 14 Nov 1996 10:05:07 +0100 (MET) In-Reply-To: <199611132105.OAA18130@xeno.xinside.com> from "Thomas Roell" at Nov 13, 96 02:05:14 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Thomas Roell wrote: > If the ioctl's would work as descrribed there would be no problem, but > as I mentioned already, they don't. Second that. According to "The Design and Implementation etc." SIGIO is sent to the process group controlling the terminal (pg.206). Nowhere does it say that the terminal should be a control tty (pg. 109). The manual pages (signal(2) and fcntl(2)) lead you to believe that SIGIOs can be generated for others than the control tty of a process. Anyway, the fact that SIGIO can only be sent in response to I/O on a process's control tty makes them pretty useless for anything but rlogin style programs. So either the manual pages would have to change or the implementation. I vote for the implementation ;-) Regards, Hans -- H. Zuidam E-Mail: hans@brandinnovators.com Brand Innovators B.V. P-Mail: P.O. Box 1377 de Pinckart 54 5602 BJ Eindhoven, The Netherlands 5674 CC Nuenen Tel. +31 40 2631134, Fax. +31 40 2831138 From owner-freebsd-hackers Thu Nov 14 04:24:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05063 for hackers-outgoing; Thu, 14 Nov 1996 04:24:25 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA05052 for ; Thu, 14 Nov 1996 04:24:22 -0800 (PST) Received: from sol1.gud.siemens.co.at (root@[10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id NAA00862 for ; Thu, 14 Nov 1996 13:23:06 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0vO0pX-00021gC; Thu, 14 Nov 96 13:23 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA205274152; Thu, 14 Nov 1996 13:22:32 +0100 From: "Hr.Ladavac" Message-Id: <199611141222.AA205274152@ws2301.gud.siemens.co.at> Subject: Re: Programming technique for non-forking servers? To: exidor@superior.net (Christopher Masto) Date: Thu, 14 Nov 1996 13:22:32 +0100 (MEZ) Cc: hackers@freebsd.org In-Reply-To: <199611131705.MAA10785@nimbus.superior.net> from "Christopher Masto" at Nov 13, 96 12:05:50 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk E-mail message from Christopher Masto contained: > Andrew Stesin writes: > > > Is forking on FreeBSD all that bad? > > > > Of course, no! > > > > But I have an impression that there's easier > > to implement locking of shared memory and file > > resources inside a single-process server than > > with some kind of IPC. There is SysV IPC around, > > but it has it's limitations. Using mmap() as a shared > > memory pool? isn't so clear and transparent for me (at least > > now), and generally isn't documented; so the question > > remains opened, that's why I'm asking about > > where a Fine Manual resides which should be read. > > This reminds me of a related thing that's been nagging me since I > first started writing Unix programs about 5 years ago. Occasionally > (more often recently) I'm working on something that screams for a > couple of cooperating processes.. coming from the Amiga world, this > seems very natural, and on the Amiga it was very simple. One process > opens up a "message port", and another process sends messages to it. > The closest thing I have seen is creating a socket in the Unix > domain.. but this doesn't seem very popular, so I get the feeling it > isn't often the right answer. > > I suppose part of the problem is that I've learned mostly from man > pages, so I haven't read any of the canonical books on Unix or network > programming. > > Of course, this is probably not the most appropriate place in which to > whine about this. It's okay, I'd say. Because, what you've used to call processes on an Amiga we call threads, i.e. threads of execution within single memory space. BTW, POSIX threads are implemented in -current and probably 2.2, and there is a port for 2.1 (called pthread or something like that). Yes, threaded programming vastly simplifies the task of building a non- forking non-blocking server. Try to find some info on pthreads. Essentially, you can attach a listener thread to every opened fd, and then decide whether you wish to employ worker threads or do the work on the listener thread. Naturally, threads are pre-emptively scheduled in FreeBSD implementation. You can take a look at: ftp://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-035.ps.Z for "An Introduction to Programming with Threads" ftp://opcom.sun.ca/pub/doc/solaris/pthreads_comparison.ps.Z "pthreads and Solaris Threads: A Comparison of Two User Level Thread APIs" > > And while I'm at it.. I miss ARexx. I keep wishing for something like > a Perl that runs as a daemon and provides unified scripting services to > other programs. > -- > Christopher Masto . . . . Superior Net Support: support@superior.net > chris@masto.com . . . . . Masto Consulting: info@masto.com > > On Wisdom, Congressional: > That's the most unheard-of thing I ever heard of. > - Senator Joseph McCarthy, talking about a witness's testimony > From owner-freebsd-hackers Thu Nov 14 05:44:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA09552 for hackers-outgoing; Thu, 14 Nov 1996 05:44:16 -0800 (PST) Received: from squirrel.tgsoft.com (sdts3-54.znet.com [207.167.65.54]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA09547 for ; Thu, 14 Nov 1996 05:44:11 -0800 (PST) Received: (from thompson@localhost) by squirrel.tgsoft.com (8.7.5/8.6.12) id UAA09340; Wed, 13 Nov 1996 20:59:16 -0800 (PST) Date: Wed, 13 Nov 1996 20:59:16 -0800 (PST) Message-Id: <199611140459.UAA09340@squirrel.tgsoft.com> From: mark thompson To: bde@zeta.org.au CC: hackers@freefall.freebsd.org In-reply-to: message from Bruce Evans on Wed, 13 Nov 1996 19:16:18 +1100 Subject: Re: Is our ASYNC I/O support for ttys broken? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Bruce Evans Date: Wed, 13 Nov 1996 19:16:18 +1100 >Thomas Roell over at X Inside just sent me this little snippet, >complaining that ASYNC I/O was broken in FreeBSD where it worked with >Linux and SVR4. Any comments? The status hasn't changed since he complained a year or so ago. SIGIO for ASYNC tty i/o is only sent to the process group of the tty, So, how do i do ASYNC I/O from a random tty, short of having to select(2) on it? This seems like a problem to me... -mark From owner-freebsd-hackers Thu Nov 14 06:26:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA11690 for hackers-outgoing; Thu, 14 Nov 1996 06:26:15 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA11668; Thu, 14 Nov 1996 06:26:07 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id GAA05368; Thu, 14 Nov 1996 06:26:07 -0800 (PST) To: "Rodney W. Grimes" cc: announce@freebsd.org, hackers@freebsd.org Subject: Re: FreeBSD 2.2-ALPHA is now available. In-reply-to: Your message of "Wed, 13 Nov 1996 21:11:58 PST." <199611140512.VAA21121@GndRsh.aac.dev.com> Date: Thu, 14 Nov 1996 06:26:07 -0800 Message-ID: <5365.847981567@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > BOCA BB2016 16 port serial card using shared IRQ (Has neen supported > for ages) Thanks, added. Jordan From owner-freebsd-hackers Thu Nov 14 06:35:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA12186 for hackers-outgoing; Thu, 14 Nov 1996 06:35:39 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA12171 for ; Thu, 14 Nov 1996 06:35:15 -0800 (PST) Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA22965; Thu, 14 Nov 1996 09:22:19 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA17044; Thu, 14 Nov 1996 09:22:32 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id KAA17858; Thu, 14 Nov 1996 10:28:22 GMT Message-Id: <199611141028.KAA17858@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: "Rodney W. Grimes" Cc: jkh@time.cdrom.com (Jordan K. Hubbard), hackers@freebsd.org Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: Your message of "Wed, 13 Nov 1996 21:11:58 PST." <199611140512.VAA21121@GndRsh.aac.dev.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Nov 1996 10:28:22 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In <199611140512.VAA21121@GndRsh.aac.dev.com> , you wrote: > ... > > DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc) > > I know of _no_ current production DC21140 card that will work with > the if_de.c driver. SMC has discontiued the SMC9332DST, and makeing > the SMC9332BDT work requires hacking the driver. This is also true > of the D-Link DFE-500TX, Kingston KNE100TX, and the Compex board. The DE500-AA will work (there's a one line fix needed to correct full-duplex negotiation). > Basically all of the vendors are converting to the new PHY interface, > and the driver just doesn't seem to cope with this fact without hacking > it up. I do have a de driver that does deal with PHY chips. It's just not stable enough for release. The other problem is that FreeBSD is too limited in controlling the device. I have 3 bits (IFF_LINK*) to play with and that's just not enough anymore. I need to select media and control full-duplex and autonegotiation. The BSDI if_media proproal does that well but there's nothing similar for FreeBSD/NetBSD. The driver works with the DE500-XA. DE500-AA, SMC 9332DST, Cogent EM110-TX, SMC 9332BDT, ZNYX ZX342, and most 21040 and 21041 cards (The Compex 21041 card being the exception; I still haven't figured out why it doesn't work). After 2.2-ALPHA finishes copying, I'll install it and make sure my current driver works with it. If you'd like to test it out, send me mail but remember I don't think it's ready for prime-time yet (primarily due to the problem of media selection). -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-hackers Thu Nov 14 06:41:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA12569 for hackers-outgoing; Thu, 14 Nov 1996 06:41:18 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA12560 for ; Thu, 14 Nov 1996 06:40:58 -0800 (PST) Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA24135; Thu, 14 Nov 1996 09:25:41 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA17108; Thu, 14 Nov 1996 09:25:54 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id KAA17892; Thu, 14 Nov 1996 10:31:45 GMT Message-Id: <199611141031.KAA17892@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: David Dawes Cc: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes), jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: Your message of "Thu, 14 Nov 1996 17:52:07 +1100." <199611140652.RAA07940@rf900.physics.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Nov 1996 10:31:45 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In <199611140652.RAA07940@rf900.physics.usyd.edu.au> , you wrote: > >> DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc) > > > >I know of _no_ current production DC21140 card that will work with > >the if_de.c driver. SMC has discontiued the SMC9332DST, and makeing > >the SMC9332BDT work requires hacking the driver. This is also true > >of the D-Link DFE-500TX, Kingston KNE100TX, and the Compex board. > > I have a Digital DE500-AA here which the driver reports uses the DC21140A. > It works fine with 2.2 (but not with 2.1.5). The only question I have > about it is, is it supposed to auto-detect full duplex 100Mb/s connections? > It reports: > > de0 rev 32 int a irq 10 on pci0:8 > de0: DE500-AA DC21140A [10-100Mb/s] pass 2.0 > de0: address 00:00:f8:01:e7:8f > de0: link up: enabling 100baseTX port > > regadless of whether the other end is full or half duplex. The output > error rate seems higher when the other end is full duplex (BTW, the > other end is a 100TX card in a Cisco Catalyst 3000 switch). This patch should fix that problem. *** if_de.c.orig Fri Jul 5 18:47:42 1996 --- if_de.c Thu Nov 14 09:24:39 1996 *************** *** 1276,1282 **** * The link is now up. If was down, say its back up. */ if ((data & (PHYSTS_LINK_UP|PHYSTS_REMOTE_FAULT)) == PHYSTS_LINK_UP) { ! if ((sc->tulip_if.if_flags & IFF_NOAUTONEG) == 0) { tulip_media_t media = tulip_dc21140_phy_readspecific(sc, phy); if (media != sc->tulip_media && media != TULIP_MEDIA_UNKNOWN) { sc->tulip_media = media; --- 1276,1282 ---- * The link is now up. If was down, say its back up. */ if ((data & (PHYSTS_LINK_UP|PHYSTS_REMOTE_FAULT)) == PHYSTS_LINK_UP) { ! if (sc->tulip_if.if_flags & IFF_NOAUTONEG) { tulip_media_t media = tulip_dc21140_phy_readspecific(sc, phy); if (media != sc->tulip_media && media != TULIP_MEDIA_UNKNOWN) { sc->tulip_media = media; -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-hackers Thu Nov 14 07:06:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA13914 for hackers-outgoing; Thu, 14 Nov 1996 07:06:09 -0800 (PST) Received: from irbs.irbs.com (jc@irbs.irbs.com [199.182.75.129]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA13906 for ; Thu, 14 Nov 1996 07:05:56 -0800 (PST) Received: (from jc@localhost) by irbs.irbs.com (8.8.2/8.8.0) id KAA27671; Thu, 14 Nov 1996 10:05:41 -0500 (EST) Message-Id: <199611141505.KAA27671@irbs.irbs.com> Date: Thu, 14 Nov 1996 10:05:40 -0500 From: jc@irbs.com (John Capo) To: gurney_j@resnet.uoregon.edu (John-Mark Gurney) Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: gated problems References: X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 In-Reply-To: ; from John-Mark Gurney on Nov 14, 1996 01:22:59 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 3.5 and 3.6A2 both core when a interface is deleted if RIP is being sent on the deleted interface. I haven't had a problem when interfaces appear, only when they are deleted. I switched to BGP on the serial links and ignored the problem. This patch floated by on the gated list that may solve the core problem. I havn't tried it. When an interface address was deleted the protocols would always be notified with IFC_DELETE. When the interface was up when it went away the protocols should have been notified with IFC_DELETE|IFC_UPDOWN. This fixes core dumps when interfaces (usually PPP or SLIP) came up and went down alot. Index: if.c =================================================================== RCS file: /master/contrib/gated-R3_5Beta_3/src/if.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 if.c *** if.c 1996/10/17 20:14:51 1.1.1.1 --- if.c 1996/10/18 18:58:47 *************** *** 1616,1622 **** if (!BIT_TEST(ifap->ifa_state, IFS_DELETE)) { /* Up - mark it down */ ! ifap->ifa_change = IFC_DELETE; } break; } --- 1616,1627 ---- if (!BIT_TEST(ifap->ifa_state, IFS_DELETE)) { /* Up - mark it down */ ! if (BIT_TEST(ifap->ifa_state, IFS_UP)) { ! BIT_RESET(ifap->ifa_state, IFS_UP); ! ifap->ifa_change = IFC_DELETE|IFC_UPDOWN; ! } else { ! ifap->ifa_change = IFC_DELETE; ! } } break; } A port for 3.6A2 is at ftp://ftp.irbs.com/FreeBSD/ports/gated-3.6a2.tgz John Capo From owner-freebsd-hackers Thu Nov 14 07:20:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA14730 for hackers-outgoing; Thu, 14 Nov 1996 07:20:51 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA14717 for ; Thu, 14 Nov 1996 07:20:40 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA04507; Thu, 14 Nov 1996 10:20:07 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 14 Nov 1996 10:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id IAA10830 for ; Thu, 14 Nov 1996 08:36:03 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id IAA19687 for freebsd-hackers@freefall.cdrom.com; Thu, 14 Nov 1996 08:37:29 -0500 (EST) Date: Thu, 14 Nov 1996 08:37:29 -0500 (EST) From: Thomas David Rivers Message-Id: <199611141337.IAA19687@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: daily panics - the saga continues... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, on some very good advice; I added a printf() to getnewvnode() in vfs_subr.c - to ensure that my good fortune with 5+ days of uptime was actually do to the check of vp->v_usecount. My code in vfs_subr.c now looks like (it's ugly, but I put everything in the left column so I can easily delete it..): if (freevnodes < (numvnodes >> 2) || numvnodes < desiredvnodes || vp == NULL || /* list empty */ vp->v_usecount) /* queue wrapped */ { { if(!(freevnodes < (numvnodes >>2)) && !(numvnodes < desiredvnodes) && !(vp == NULL) && vp->v_usecount) printf("getnewvnode: Allocating new vnode because queue wrapped\n"); } vp = (struct vnode *) malloc((u_long) sizeof *vp, M_VNODE, M_WAITOK); bzero((char *) vp, sizeof *vp); numvnodes++; } else { TAILQ_REMOVE(&vnode_free_list, vp, v_freelist); freevnodes--; I installed that kernel and rebooted... Guess what! At my typical ~3:20 am time, I got a panic, but a different one this time (this is getting stranger and stranger): [The panic does indicate there is a problem in the panic() routine, as the %d should have been replaced with the int... if you check ufs_ihash.c, you'll find this particular panic() call...] Script started on Thu Nov 14 08:25:26 1996 ponds# gdb -k kernel.8 vmcore.8 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 1e4000 current pcb at 1d5484 panic: ufs_ihashget: recursive lock not expected -- pid %d #0 0xf0193ceb in boot () (kgdb) where #0 0xf0193ceb in boot () #1 0xf0112b83 in panic () #2 0xf017bfc1 in ufs_ihashget () #3 0xf017a193 in ffs_vget () #4 0xf017517a in ffs_valloc () #5 0xf0181436 in ufs_makeinode () #6 0xf017edf5 in ufs_create () #7 0xf012cc07 in vn_open () #8 0xf012a43f in open () #9 0xf019c066 in syscall () #10 0xf019152b in Xsyscall () #11 0x33c0 in ?? () #12 0x32cd in ?? () #13 0x327d in ?? () #14 0x31d7 in ?? () #15 0x2f7b in ?? () #16 0x2e76 in ?? () #17 0x3b87 in ?? () #18 0x4854 in ?? () #19 0x474e in ?? () #20 0x467a in ?? () #21 0x1ffe in ?? () #22 0x1e6b in ?? () #23 0x1d21 in ?? () #24 0x16a7 in ?? () #25 0x10d3 in ?? () (kgdb) ponds# Script done on Thu Nov 14 08:26:31 1996 There were no instances of the text from my added printf() in /var/log/messages - so I can only assume this didn't participate in the good fortune I was previously experiencing... I'm *really* stumped now... First, why was I sucessfully running for so long - just luck? Second, one change to the source causes a new/different (although, seemingly related to inode allocation...) panic. I can connect this machine to the internet and provide accounts for anyone who would like to "take a whack" at this problem... As always, I'm open to suggestions/ideas... [I need to order that 4.4BSD book :-) ] - Dave Rivers - From owner-freebsd-hackers Thu Nov 14 09:21:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA19271 for hackers-outgoing; Thu, 14 Nov 1996 09:21:21 -0800 (PST) Received: from phoenix.gov.com (phoenix.gov.com [198.145.144.201]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA19266 for ; Thu, 14 Nov 1996 09:21:18 -0800 (PST) Received: (from todd@localhost) by phoenix.gov.com (8.7.6/8.7.3) id JAA12666; Thu, 14 Nov 1996 09:23:27 GMT Date: Thu, 14 Nov 1996 09:23:27 +0000 () From: Todd To: "Jordan K. Hubbard" cc: "Rodney W. Grimes" , hackers@FreeBSD.org Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: <5365.847981567@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, Jordan K. Hubbard wrote: > > BOCA BB2016 16 port serial card using shared IRQ (Has neen supported > > for ages) > > Thanks, added. > > Jordan > Actually, I've been using just such an adapter with 2.0.5-RELEASE and a kernel config file that someone helped me generate. I saw mention of the board being used by someone on the mailing list archives on www.freebsd.org, and emailed the person for help on doing it myself. I have to admit, though, neither of us have gotten around to testing ports beyond the first 8. Still, the Boca 8-port board (and 4-port for that matter) doesn't have carrier detect lines, so the 16-port board is the only one they make that works with modems. I got the thing because I'm too cheap to get a RisCom or Cyclades or Digi, but at the time I had need of more than 4 ports... From owner-freebsd-hackers Thu Nov 14 09:22:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA19396 for hackers-outgoing; Thu, 14 Nov 1996 09:22:42 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA19379; Thu, 14 Nov 1996 09:22:36 -0800 (PST) Received: (from jkh@localhost) by time.cdrom.com (8.8.2/8.6.9) id JAA06309; Thu, 14 Nov 1996 09:22:44 -0800 (PST) Date: Thu, 14 Nov 1996 09:22:44 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199611141722.JAA06309@time.cdrom.com> To: announce@freebsd.org Subject: David and I will be at COMDEX in Las Vegas from Nov 18 - Nov 22 Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In case any FreeBSD enthusiasts will be attending, David Greenman and I will be staffing "the FreeBSD booth" - a segment of Walnut Creek CDROM's booth which they have provided to us for promotional purposes. We will be there all week answering questions, signing autographs and shooting rubber bands at the Slackware Linux booth staffers. Walnut Creek CDROM's booth will be at the Sands, and should be listed on the Exhibitors map. If you're in the area, please stop by and see us! Jordan From owner-freebsd-hackers Thu Nov 14 09:42:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA20713 for hackers-outgoing; Thu, 14 Nov 1996 09:42:39 -0800 (PST) Received: from hawk.rnd.runnet.ru (hawk.rnd.runnet.ru [195.208.248.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA20574 for ; Thu, 14 Nov 1996 09:40:16 -0800 (PST) Received: (from max@localhost) by hawk.rnd.runnet.ru (8.7.6/8.7.3) id UAA02192 for hackers@freebsd.org; Thu, 14 Nov 1996 20:25:10 +0300 (MSK) Date: Thu, 14 Nov 1996 20:25:10 +0300 (MSK) From: Maxim Bolotin Message-Id: <199611141725.UAA02192@hawk.rnd.runnet.ru> To: hackers@freebsd.org Subject: Digiboard driver. Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! I port digiboard driver from 2.1.5 to 2.2, all bugs fixed. The driver for 2.1.5, stable is work weel, Now I port it for 2.2, I send it to author (Serge A. Babkin ) He said me he'll send it to Bruce Evans. New version work very well. I'm using PC/16e with 4 leased lines ( 28K ), 6 terminals (9600K) and printer (9600K). All It work under 2.2-SNAP-141096. Max. -- Rostov State University Computer Center Rostov-on-Don, +7 (8632) 285794 or 357476 From owner-freebsd-hackers Thu Nov 14 09:44:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA20976 for hackers-outgoing; Thu, 14 Nov 1996 09:44:51 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA20924 for ; Thu, 14 Nov 1996 09:44:32 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id JAA08935; Thu, 14 Nov 1996 09:44:10 -0800 (PST) Message-Id: <199611141744.JAA08935@austin.polstra.com> To: michaelh@cet.co.jp Subject: Re: Programming technique for non-forking servers? Newsgroups: polstra.freebsd.hackers In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Thu, 14 Nov 1996 09:44:10 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > mset and mclear would be implemented as lib functions because Intel does > have an atomic test and set. Yes it does: the "xchg" instruction. Load 1 into a register, then "xchg" the register with the memory location containing the lock. Look at the new value of the register to find out whether the lock was already locked. It even works in a multiprocessor system. According to the Intel book: If a memory operand is involved, the LOCK# signal is asserted for the duration of the exchange, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 14 09:48:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA21243 for hackers-outgoing; Thu, 14 Nov 1996 09:48:00 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA21233 for ; Thu, 14 Nov 1996 09:47:46 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id JAA08966; Thu, 14 Nov 1996 09:47:04 -0800 (PST) Message-Id: <199611141747.JAA08966@austin.polstra.com> To: scrappy@ki.net Subject: Re: Sockets question... Newsgroups: polstra.freebsd.hackers In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Thu, 14 Nov 1996 09:47:04 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Basically, the server opens up a binary file and sends the data > to the client. The client is connecting to the server no problem, but I'm > don't seem to be able to send >79 bytes across the socket What happens? Does it hang? Is data lost? It should work fine. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 14 10:08:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22218 for hackers-outgoing; Thu, 14 Nov 1996 10:08:16 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22156 for ; Thu, 14 Nov 1996 10:07:58 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id MAA15900 for ; Thu, 14 Nov 1996 12:07:44 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id MAA08605 for ; Thu, 14 Nov 1996 12:07:43 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id MAA29039 for hackers@freebsd.org; Thu, 14 Nov 1996 12:07:42 -0600 (CST) From: Karl Denninger Message-Id: <199611141807.MAA29039@Jupiter.Mcs.Net> Subject: Hmmmm... now I'm confused To: hackers@freebsd.org Date: Thu, 14 Nov 1996 12:07:42 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks, Ok, now I don't understand..... I built a new kernel with -current to support more than 128MB with the following options.... options "MAXMEM=262144" # 256 * 1024, 256MB maximum RAM options "MAXDSIZ=201326592" options "DFLDSIZ=201326592" 256MB supported RAM and huge process sizes... Those were the only changes from a working kernel which is running on the same hardware (a Pentium PRO 200 with 128MB of RAM). Then I added more physical memory. I rebooted, and the "de" cards in the box (two 100BaseTX boards) both disappeared! They identify ok during the boot, and claim to be there, but an "ifconfig de0" comes up "no such device"! I removed the extra RAM and went back to 128M, and it STILL happens! With or without the memory in there; it appears that the MAXMEM line up there blows the de cards out of the water! What's going on here, and is there a work-around for this? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Thu Nov 14 10:34:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA24376 for hackers-outgoing; Thu, 14 Nov 1996 10:34:55 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA24357 for ; Thu, 14 Nov 1996 10:34:38 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id NAA01376; Thu, 14 Nov 1996 13:34:27 -0500 (EST) From: John Dyson Message-Id: <199611141834.NAA01376@dyson.iquest.net> Subject: Re: Hmmmm... now I'm confused To: karl@Mcs.Net (Karl Denninger) Date: Thu, 14 Nov 1996 13:34:27 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611141807.MAA29039@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 14, 96 12:07:42 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Hi folks, > > Ok, now I don't understand..... > > I built a new kernel with -current to support more than 128MB with the > following options.... > > options "MAXMEM=262144" # 256 * 1024, 256MB maximum RAM > options "MAXDSIZ=201326592" > options "DFLDSIZ=201326592" > > 256MB supported RAM and huge process sizes... > > Those were the only changes from a working kernel which is running on > the same hardware (a Pentium PRO 200 with 128MB of RAM). Then I added > more physical memory. > > I rebooted, and the "de" cards in the box (two 100BaseTX boards) both > disappeared! > > They identify ok during the boot, and claim to be there, but an "ifconfig > de0" comes up "no such device"! > > I removed the extra RAM and went back to 128M, and it STILL happens! > With or without the memory in there; it appears that the MAXMEM line up > there blows the de cards out of the water! > > What's going on here, and is there a work-around for this? > Did you control the experiment and determine if it is/might be the MAXMEM (phys mem) or the MAX/DFL DSIZ definitions? It sounds to me that it is the (MAX/DFL)DSIZ definitions -- right, or am I dense? :-)... John From owner-freebsd-hackers Thu Nov 14 11:04:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA26503 for hackers-outgoing; Thu, 14 Nov 1996 11:04:39 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA26334; Thu, 14 Nov 1996 11:03:30 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id NAA18282; Thu, 14 Nov 1996 13:01:56 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id NAA20414; Thu, 14 Nov 1996 13:01:41 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id NAA01005; Thu, 14 Nov 1996 13:01:33 -0600 (CST) From: Karl Denninger Message-Id: <199611141901.NAA01005@Jupiter.Mcs.Net> Subject: Re: Hmmmm... now I'm confused To: dyson@freebsd.org Date: Thu, 14 Nov 1996 13:01:33 -0600 (CST) Cc: karl@Mcs.Net, hackers@freebsd.org In-Reply-To: <199611141834.NAA01376@dyson.iquest.net> from "John Dyson" at Nov 14, 96 01:34:27 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Hi folks, > > > > Ok, now I don't understand..... > > > > I built a new kernel with -current to support more than 128MB with the > > following options.... > > > > options "MAXMEM=262144" # 256 * 1024, 256MB maximum RAM > > options "MAXDSIZ=201326592" > > options "DFLDSIZ=201326592" > > > > 256MB supported RAM and huge process sizes... > > > > Those were the only changes from a working kernel which is running on > > the same hardware (a Pentium PRO 200 with 128MB of RAM). Then I added > > more physical memory. > > > > I rebooted, and the "de" cards in the box (two 100BaseTX boards) both > > disappeared! > > > > They identify ok during the boot, and claim to be there, but an "ifconfig > > de0" comes up "no such device"! > > > > I removed the extra RAM and went back to 128M, and it STILL happens! > > With or without the memory in there; it appears that the MAXMEM line up > > there blows the de cards out of the water! > > > > What's going on here, and is there a work-around for this? > > > Did you control the experiment and determine if it is/might be the > MAXMEM (phys mem) or the MAX/DFL DSIZ definitions? It sounds to me > that it is the (MAX/DFL)DSIZ definitions -- right, or am I dense? :-)... > > John I found it. Somewhere in the last few weeks something changed in the "ifconfig" program. I loaded that from the "make world" on the codebase machine, and the problem disappeared. Odd stuff! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Thu Nov 14 11:20:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27544 for hackers-outgoing; Thu, 14 Nov 1996 11:20:09 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA27458 for ; Thu, 14 Nov 1996 11:20:02 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA25758; Thu, 14 Nov 1996 13:19:10 -0600 From: Joe Greco Message-Id: <199611141919.NAA25758@brasil.moneng.mei.com> Subject: Re: Programming technique for non-forking servers? To: proff@suburbia.net (Julian Assange) Date: Thu, 14 Nov 1996 13:19:10 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: <199611132227.JAA16234@suburbia.net> from "Julian Assange" at Nov 14, 96 09:27:56 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > In the case of a "complex" server, i.e. something like an Xserver or > > MUD, but probably not a Web server, you probably need to use state machine > > concepts. This is not "difficult", the only real problem is mastering > > the concept of state machines. > > The problem with user-level state machines or multi-threading is that it > doesn't take advantage of multiple cpu's. Kernel level support for threading > may address this. Since most FreeBSD machines are not yet SMP, the advantage of multiple processors is probably not an issue, so I would most likely not consider threads on a FreeBSD box... Kernel level support for threading (or threads in general, for that matter) may not be particularly portable in any case. I guess I would not consider this viable unless someone told me up front that there was a single platform that was being targeted, and there was a clear advantage to the use of threads in the given context, and the thread support on the platform in question was known to be good. But Andrew only asked for some general theory on the subject. :-) ... JG From owner-freebsd-hackers Thu Nov 14 11:31:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA28444 for hackers-outgoing; Thu, 14 Nov 1996 11:31:21 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA28438 for ; Thu, 14 Nov 1996 11:31:16 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15163(2)>; Thu, 14 Nov 1996 11:30:40 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177557>; Thu, 14 Nov 1996 11:30:36 -0800 X-Mailer: exmh version 1.6.7 5/3/96 To: Julian Assange cc: hackers@freebsd.org Subject: Re: status of ports In-reply-to: Your message of "Thu, 14 Nov 1996 02:47:07 PST." <199611141047.VAA22350@suburbia.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Nov 1996 11:30:21 PST From: Bill Fenner Message-Id: <96Nov14.113036pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611141047.VAA22350@suburbia.net>you write: >I've uploaded several ports to incoming and sent the appropriate pr's >over the last few months, yet haven't seen inclusion in current /usr/ports. You can check on your PR's using http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports . People usually close PR's when they import the port. Wouldn't this question be more appropriately asked on freebsd-ports@freebsd.org? Bill From owner-freebsd-hackers Thu Nov 14 11:40:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA29208 for hackers-outgoing; Thu, 14 Nov 1996 11:40:09 -0800 (PST) Received: from phaeton.artisoft.com ([198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA29139 for ; Thu, 14 Nov 1996 11:40:02 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA24570; Thu, 14 Nov 1996 12:28:04 -0700 From: Terry Lambert Message-Id: <199611141928.MAA24570@phaeton.artisoft.com> Subject: Re: Even more info on daily panics... To: dg@root.com Date: Thu, 14 Nov 1996 12:28:03 -0700 (MST) Cc: terry@lambert.org, michaelh@cet.co.jp, ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.org In-Reply-To: <199611140458.UAA09784@root.com> from "David Greenman" at Nov 13, 96 08:58:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> Vnodes on the free list are not allowed to have non-zero v_usecount's. > > > >That's not what the code says. > > > >The code inserts them on list wrap. > > What "list wrap"? What are you talking about? I've explained this 4 or 5 times now. I'm not going to explain it again. Your feigned incredulity is simply an ill-disguised ad hominum attack to make my statements appear less credible than they are. If you want to attack them, attack them on logical grounds. > >The problem is clearly a bogus list insertion. > > No, it isn't. Let's see... IF Bad data is on the list AND Data gets on the list via insertion THEN Bad data was inserted on the list > >Equally as clearly, a bogus list insertion in possible in the current > >code because of the lock race potentially causing a list wrap during > >the allocation to extend sleeping through a valid vrele. > > What "lock race potential"? The only one I know about is fixed by the > mutexes I added to the various filesystems 1.5 years ago. ...and it doesn't > matter anyway. Then explain the crashes. Explain why the panic stack tracebak didn't lead you to say "oh, just change this line of code in this function in the traceback". > >This is possible because the lock is not a lock on list access, it is > >a lock across interface access... the lock is held in vclean above > >the VOP layer and in valloc below the VOP layer. > > Look, Terry, none of this matters!!! The panic is caused by a vnode on > the freelist having a non-zero v_usecount. That *can't* happen when vnode > references are gained via vget and released via vrele. It can *only* (other > than memory corruption of course) happen if vnode_pager_alloc() is passed a > vnode without a reference (v_usecount == 0). If that is the case, then we > have a simple reference count problem and the traceback will point to it. >From getnewvnode() in vfs_subr.c: if (freevnodes < (numvnodes >> 2) || numvnodes < desiredvnodes || vnode_free_list.tqh_first == NULL) { simple_unlock(&vnode_free_list_slock); ************* ************* vp = (struct vnode *) malloc((u_long) sizeof *vp, M_VNODE, M_WAITOK); ******** ******** bzero((char *) vp, sizeof *vp); numvnodes++; } else { > >The *correct* soloution is to panic the bogus list insertion at the > >time of the insertion attempt (in vrele) so that the stack reflects > >who is responsible for the bogus insertion. With an obviously bad > >parameter, it is apparent where the parameter orginated... from the > >insertion/list expansion race. > > We already do that. Look at the code. That is a reactive panic, and will not identify the cause of the problem (hence your inability to fix the problem for David with a simple and obvious-from-context hack). It is still possible to have a cascade failure hide the real problem. This is what I am claiming is happening. > Someday we'll fix it, and when that day happens, we'll have a whole new set of > vnode reference count bugs to deal with. > Look, I encourage comments when they are constructive and work toward a > fix. David's machine is crashing and he's looking for a fix. We're right on > the heals of a release and I don't have the time nor the energy to get caught > up in Terry's grand VFS design model. If that were all it was, David's problems would not have gone away for 4+ days now with my patch. There are at least three people running the patch over the past 15 months, besides myself, and all of them have reported (to me) that the problem has gone away. Like it or not, I have identified a problem and provided a patch. Maybe what is upsetting you is that I labelled the patch a kludge? > For what's it's worth, I agree with you that the current model of > vnode reference/release is wrong, and we'll likely change it at some > point. Doing so is very difficult, however, and arguing about it now > doesn't stop David's machine from panicing. My patch does. And I'm not arguing about it. I argued in June of 1995, when I first published patches. Now I'm simply explaining why the existing code acts like it does. I've provided a kludge patch to get around the problem, without requiring that you actually fix it to use the patch. In my book, that's bending over backwards: "here's something that will stop the pain, but you really should consider corrective surgery". At worst, I'm editorializing about a problem that has existed as recognized but unaddressed (for no justifiable reason) for two years. This is very different from "demanding" you actually do something about it... I am only raising its visibility. Of course, you *could* do something about it, and take the wind right out of my sails, and force me to look elsewhere for unaddressed problems... but I'm hardly "arguing about it". > These are long-term design goals that span over the next few years > and are not germane to finding and fixing this problem. The "problem" of NULL pointer dereferences causing a core dump could also be "addressed" by mapping page 0. Better to address the actual problem. You have already addressed the FS problems that would result in a nonzero reference count (don't latch bogus data that could cause the black box to malfunction onto the inputs of the black box). The only thing left that could be the cause is a race condition (the black box is internally malfunctioning at a boundry condition). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 14 11:41:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA29433 for hackers-outgoing; Thu, 14 Nov 1996 11:41:47 -0800 (PST) Received: from vinyl.quickweb.com (vinyl.quickweb.com [206.222.77.8]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA29406; Thu, 14 Nov 1996 11:41:36 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id OAA22823; Thu, 14 Nov 1996 14:36:56 -0500 (EST) Date: Thu, 14 Nov 1996 14:36:55 -0500 (EST) From: Mark Mayo To: hackers@freebsd.org cc: current@freebsd.org Subject: userland PPP giving weird load numbers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've had this problem since 2.1x, and it appaears to still happen occasionally in 2.2-ALPHA: mark:{105}/home/mark % w 8:14AM up 46 mins, 3 users, load averages: 0.99, 0.97, 0.88 USER TTY FROM LOGIN@ IDLE WHAT mark p1 :0.0 7:28AM 45 -tcsh (tcsh) mark p2 :0.0 7:28AM - w mark p3 :0.0 7:32AM 37 ppp the ppp process causes the high load (which isn't real, BTW). Top shows it as not doing a thing. As soon as I kill ppp off, the load drops right back down. A friend of mine gets the exact same thing regularily in 2.1.5, and although it rarely happens to me these days, it happens enough to make me curious about what's going on here :-) -mark --------------------------------------------------- | Mark Mayo mark@quickweb.com | | RingZero Comp. vinyl.quickweb.com/mark | --------------------------------------------------- "To iterate is human, to recurse divine." - L. Peter Deutsch From owner-freebsd-hackers Thu Nov 14 11:47:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA29756 for hackers-outgoing; Thu, 14 Nov 1996 11:47:05 -0800 (PST) Received: from quagmire.ki.net (quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA29687 for ; Thu, 14 Nov 1996 11:44:42 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id OAA06692; Thu, 14 Nov 1996 14:44:03 -0500 (EST) Date: Thu, 14 Nov 1996 14:44:03 -0500 (EST) From: "Marc G. Fournier" To: John Polstra cc: hackers@freebsd.org Subject: Re: Sockets question... In-Reply-To: <199611141747.JAA08966@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, John Polstra wrote: > > Basically, the server opens up a binary file and sends the data > > to the client. The client is connecting to the server no problem, but I'm > > don't seem to be able to send >79 bytes across the socket > > What happens? Does it hang? Is data lost? It should work fine. At 1024, data seems to be lost. I send 1023 bytes across, and receive 4...send 1023, receive 907...I send across 100 packets, receive 2... As soon as I go to 512 or 80 byte writes, I can pound at it repeatedly and get the complete image across every time, no errors. Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Thu Nov 14 11:47:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA29803 for hackers-outgoing; Thu, 14 Nov 1996 11:47:48 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA29786 for ; Thu, 14 Nov 1996 11:47:26 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id UAA07781 for ; Thu, 14 Nov 1996 20:45:37 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id UAA18964 for hackers@freebsd.org; Thu, 14 Nov 1996 20:45:03 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id TAA07139; Thu, 14 Nov 1996 19:58:44 +0100 (MET) Message-ID: Date: Thu, 14 Nov 1996 19:58:44 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: status of ports References: <199611141047.VAA22350@suburbia.net> X-Mailer: Mutt 0.50.05 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2686 In-Reply-To: <199611141047.VAA22350@suburbia.net>; from Julian Assange on Nov 14, 1996 21:47:07 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Julian Assange: > Is someone actually monitoring incoming? Did you send a mail or a PR for each one ? Opening a PR for a new port is much better. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996 From owner-freebsd-hackers Thu Nov 14 11:55:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00488 for hackers-outgoing; Thu, 14 Nov 1996 11:55:29 -0800 (PST) Received: from austin.polstra.com ([206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA00482 for ; Thu, 14 Nov 1996 11:55:24 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id LAA09643; Thu, 14 Nov 1996 11:54:48 -0800 (PST) Message-Id: <199611141954.LAA09643@austin.polstra.com> To: "Marc G. Fournier" cc: hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Thu, 14 Nov 1996 14:44:03 EST." References: Date: Thu, 14 Nov 1996 11:54:48 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > At 1024, data seems to be lost. I send 1023 bytes across, and > receive 4...send 1023, receive 907...I send across 100 packets, > receive 2... > > As soon as I go to 512 or 80 byte writes, I can pound at it repeatedly > and get the complete image across every time, no errors. I haven't seen your code, but do you realize that you can't just do a single read? E.g., if you're expecting to receive 1024 bytes, this won't necessarily return all the data: read(s, buf, 1024); If just part of the data has arrived, the read() call will return that, and it will return the number of bytes it actually transferred, which may be less than 1024. To read all 1024 bytes, you'd have to do something like this: char *ptr = buf; int nWant = 1024; int nGot = 0; while (nGot < nWant) { int n = read(s, ptr, nWant - nGot); if (n == -1) /* Error */ else if (n == 0) /* EOF */ else { ptr += n; nGot += n; } } If you don't know how many bytes to expect, and just want to read it all, then make the loop continue until read() returns a number <= 0. In general, a read() on a socket will return as soon as _any_ data is available -- even just 1 byte. Could this be the problem? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 14 11:59:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00798 for hackers-outgoing; Thu, 14 Nov 1996 11:59:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA00784 for ; Thu, 14 Nov 1996 11:59:07 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA24628; Thu, 14 Nov 1996 12:47:16 -0700 From: Terry Lambert Message-Id: <199611141947.MAA24628@phaeton.artisoft.com> Subject: Re: data segment To: toor@dyson.iquest.net (John S. Dyson) Date: Thu, 14 Nov 1996 12:47:15 -0700 (MST) Cc: cskim@cslsun10.sogang.ac.kr, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199611140520.AAA02018@dyson.iquest.net> from "John S. Dyson" at Nov 14, 96 00:20:36 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > FreeBSD (internally) distinguishes between .text, .data, > .bss by mechanisms that are not named ".text" handler, ".data" handler, > and ".bss" handler :-). It does so by the attributes of the segments. > Take a look at the code in /sys/kern/imgact_aout.c for how the segments > are set-up. I understand that it can be confusing, but the names ".text", > ".data", and ".bss" are historical, and mostly imply certain segment > attributes. Any chance we can get some additional mappings defined to coincide with the Microsoft mappings? I've been trying to load (and use) some simple NT drivers, and they want "pageable" (which I wouldn't expect to do anything, initially anyway) and "discradable" for init, etc., etc.. If you need a full list, I can provide it with a day or so lead time. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 14 12:09:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01726 for hackers-outgoing; Thu, 14 Nov 1996 12:09:43 -0800 (PST) Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA01698; Thu, 14 Nov 1996 12:09:27 -0800 (PST) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id MAA27487; Thu, 14 Nov 1996 12:08:15 -0800 Date: Thu, 14 Nov 1996 12:08:15 -0800 From: "Jin Guojun[ITG]" Message-Id: <199611142008.MAA27487@george.lbl.gov> To: fenner@parc.xerox.com, hackers@freebsd.org Subject: Re: what is changed for ARP in 2.2-SNAP Cc: bugs@freebsd.org, questions@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk }In message <199611041928.LAA17022@george.lbl.gov> you write: }>If some one would tell me what is core change for the ARP, so I can make }>corresponding change in the ATM, it will be appriciated. } }Reviewing net/if_ethersubr.c and netinet/if_ether.c, the major change }that I see is that the interface output routine no longer byte-swaps }the ethernet packet type, so that arp has to use htons(ETHERTYPE_ARP) . } } Bill The real problem is not something related to network code. It is releated to the kernel configuration. I noticed the same problem in 2.1 release, and it goes away in 2.1.5-release. However, it comes back in 2.2-9608xx-SNAP and 2.2-961014-SNAP. The problem is the maxusers to be limited to 15. If the maxusers is set to 16 or higher, it breaks NCR and ATM drivers somehow. The symptom is that the driver registers are mis-configured. I don't know why and how, so I need more information about what changed on this part. I do not know if it breaks other drivers so far. So, please let me know what has been changed in system configuration from 2.1 -> 2.1.5 -> 2.2-SNAP which may cause such problem, I may easy to trace down where the problem occurs, and try to make sure it will not happen again. Thanks, -Jin From owner-freebsd-hackers Thu Nov 14 12:31:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA03097 for hackers-outgoing; Thu, 14 Nov 1996 12:31:17 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA02809 for ; Thu, 14 Nov 1996 12:25:22 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id VAA24558; Thu, 14 Nov 1996 21:02:19 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.2/8.8.2) with SMTP id UAA00446; Thu, 14 Nov 1996 20:57:01 +0100 (MET) Date: Thu, 14 Nov 1996 20:57:01 +0100 (MET) From: Andreas Klemm To: "Justin T. Gibbs" cc: "Alexsandro D. F. Correia" , hackers@FreeBSD.org Subject: Re: Problems restoring Backups !!! In-Reply-To: <199611120426.UAA13829@freefall.freebsd.org> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Justin, I tried this patch now: a) options AHC_SCBPAGING_ENABLE options AHC_TAGENABLE timed out in message 0xf4 issued channel A bus reset 4 SCB's aborted SCSISIGI==0xc6 timedout in message in phase SCSISIGI==0xc6 SEQADDR==0x59 Ordered Tag queued sd0(....) timed out .... SCSISIGI==0xc6 SEQADDR==0x5a st0(0:4:0) abort message in message buffer st0(0:4:0) timedout in message in phase ... b) options AHC_TAGENABLE Here trouble, too, although an SCSI BUS Reset is done. But, if you access the tape once more doing a mt status only DDB is called... ... ... timed out in message in phase Bus reset Unit ... st0(0:4:0) Unix attention ... asc:25,0 ... ... Ordered tag sent > Index: i386/scsi/aic7xxx.c > =================================================================== > RCS file: /usr/cvs/src/sys/i386/scsi/aic7xxx.c,v > retrieving revision 1.85 > diff -c -r1.85 aic7xxx.c > *** aic7xxx.c 1996/11/11 05:24:44 1.85 > --- aic7xxx.c 1996/11/12 04:19:04 > *************** > *** 1206,1226 **** > if (xs->error == XS_NOERROR) > xs->error = XS_DRIVER_STUFFUP; > break; > case SCSI_BUSY: > xs->error = XS_BUSY; > sc_print_addr(xs->sc_link); > printf("Target Busy\n"); > - break; > - case SCSI_QUEUE_FULL: > - /* > - * The upper level SCSI code will someday > - * handle this properly. > - */ > - printf("Queue Full\n"); > - /* > - * XXX requeue this unconditionally. > - */ > - STAILQ_INSERT_HEAD(&ahc->waiting_scbs, scb, links); > break; > default: > sc_print_addr(xs->sc_link); > --- 1206,1242 ---- > if (xs->error == XS_NOERROR) > xs->error = XS_DRIVER_STUFFUP; > break; > + case SCSI_QUEUE_FULL: > + if (scb->hscb->control & TAG_ENB) { > + /* > + * The upper level SCSI code in 3.0 > + * handles this properly... > + */ > + struct scsi_link *sc_link; > + > + sc_link = xs->sc_link; > + if (sc_link->active > 2 > + && sc_link->opennings != 0) { > + /* truncate the opennings */ > + sc_link->opennings = 0; > + sc_print_addr(sc_link); > + printf("Tagged openings reduced to " > + "%d\n", sc_link->active); > + } > + /* > + * XXX requeue this unconditionally. > + */ > + STAILQ_INSERT_TAIL(&ahc->waiting_scbs, scb, > + links); > + break; > + } > + /* Else treat as if it is a BUSY condition */ > + scb->hscb->status = SCSI_BUSY; > + /* Fall Through... */ > case SCSI_BUSY: > xs->error = XS_BUSY; > sc_print_addr(xs->sc_link); > printf("Target Busy\n"); > break; > default: > sc_print_addr(xs->sc_link); > andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hackers Thu Nov 14 13:12:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA06097 for hackers-outgoing; Thu, 14 Nov 1996 13:12:30 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA06063 for ; Thu, 14 Nov 1996 13:12:24 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id NAA00566 for ; Thu, 14 Nov 1996 13:12:16 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id QAA09013; Thu, 14 Nov 1996 16:10:36 -0500 (EST) Date: Thu, 14 Nov 1996 16:10:34 -0500 (EST) From: "Marc G. Fournier" To: John Polstra cc: hackers@freebsd.org Subject: Re: Sockets question... In-Reply-To: <199611141954.LAA09643@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, John Polstra wrote: > In general, a read() on a socket will return as soon as _any_ data is > available -- even just 1 byte. > > Could this be the problem? > Ack...that sounds like exactly the problem...I misunderstood the read() call :( Why does 512k work fine though? no data lose at all.... I'm going to code in your suggestion above, but I'm very curious now as to why 512bytes and 80bytes both work cleanly, but 256bytes "loses" data... I think I'm just going to *borrow* the readn/writen functions from the book to avoid making this foolish mistake again :) Thanks... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Thu Nov 14 13:15:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA06355 for hackers-outgoing; Thu, 14 Nov 1996 13:15:36 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA06242 for ; Thu, 14 Nov 1996 13:14:54 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA26018; Thu, 14 Nov 1996 15:13:41 -0600 From: Joe Greco Message-Id: <199611142113.PAA26018@brasil.moneng.mei.com> Subject: Re: Hmmmm... now I'm confused To: karl@mcs.net (Karl Denninger) Date: Thu, 14 Nov 1996 15:13:40 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: <199611141807.MAA29039@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 14, 96 12:07:42 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi folks, > > Ok, now I don't understand..... > > I built a new kernel with -current to support more than 128MB with the > following options.... > > options "MAXMEM=262144" # 256 * 1024, 256MB maximum RAM > options "MAXDSIZ=201326592" > options "DFLDSIZ=201326592" > > 256MB supported RAM and huge process sizes... > > Those were the only changes from a working kernel which is running on > the same hardware (a Pentium PRO 200 with 128MB of RAM). Then I added > more physical memory. > > I rebooted, and the "de" cards in the box (two 100BaseTX boards) both > disappeared! > > They identify ok during the boot, and claim to be there, but an "ifconfig > de0" comes up "no such device"! > > I removed the extra RAM and went back to 128M, and it STILL happens! > With or without the memory in there; it appears that the MAXMEM line up > there blows the de cards out of the water! > > What's going on here, and is there a work-around for this? Karl, I am assuming that you had a MAXMEM=128MB line before, and it worked? I am a little confused. What happens if you back the changes out entirely? I am running MAXMEM=262720, MAXDSIZ=268435456UL, DFLDSIZ=201326592UL with one de0 device on a P5/133 and 2.1.5R(++) with zero problems. I have a 2.2-CURRENT box I could try it on if we can not figure out your problem, and dropping in another 100baseT card would be easy for me too. One difference between what you have and what I have, is the "UL" token at the end of MAXDSIZ/DFLDSIZ. I have no idea if it could cause what you are seeing. Please provide a little more data and I will see if I can duplicate your problem later this evening. Sorry I can't provide more help, there is not enough data yet. ... JG From owner-freebsd-hackers Thu Nov 14 13:16:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA06440 for hackers-outgoing; Thu, 14 Nov 1996 13:16:11 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA06399 for ; Thu, 14 Nov 1996 13:15:59 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id NAA10054; Thu, 14 Nov 1996 13:15:38 -0800 (PST) Message-Id: <199611142115.NAA10054@austin.polstra.com> To: "Marc G. Fournier" cc: hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Thu, 14 Nov 1996 16:10:34 EST." References: Date: Thu, 14 Nov 1996 13:15:38 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Ack...that sounds like exactly the problem...I misunderstood > the read() call :( > > Why does 512k work fine though? no data lose at all.... > > I'm going to code in your suggestion above, but I'm very > curious now as to why 512bytes and 80bytes both work cleanly, but > 256bytes "loses" data... It depends on so many things, all timing related. Tomorrow you might try it again and see it behave entirely differently. Run the server on a machine on the other side of the Internet, and it will behave differently still. You just can't reliably predict what it's going to do. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 14 13:44:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA08460 for hackers-outgoing; Thu, 14 Nov 1996 13:44:16 -0800 (PST) Received: from ec.camitel.com (ec.camitel.com [206.231.123.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA08402; Thu, 14 Nov 1996 13:43:51 -0800 (PST) Received: (from cfortin@localhost) by ec.camitel.com (8.7.5/8.7.3) id QAA22414; Thu, 14 Nov 1996 16:44:51 -0500 (EST) Message-ID: X-Mailer: XFMail 0.4 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199611141722.JAA06309@time.cdrom.com> Date: Thu, 14 Nov 1996 16:38:14 -0500 (EST) Organization: =?us-ascii?Q?=C9lectro-Conception?= From: Christian Fortin To: "Jordan K. Hubbard" Subject: RE: David and I will be at COMDEX in Las Vegas from Nov 18 - Nov Cc: announce@FreeBSD.org, hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I have talk today to a guy at the WordPerfect developement team... I have tell about FreeBSD... They are interest about it ( for WP 7.0 ) avalable at the end of january... They are looking for Linux also... Anyway, they also build a Java version of WP Office :-) You can try it write no w!!! Presently, I run WP 6.0 on X , it work fine with FreeBSD... SCO version with ibc s2 ;-) Good luck guy .... On 14-Nov-96 "Jordan K. Hubbard" wrote: >>In case any FreeBSD enthusiasts will be attending, David Greenman >and I will be staffing "the FreeBSD booth" - a segment of Walnut Creek >CDROM's booth which they have provided to us for promotional purposes. >We will be there all week answering questions, signing autographs >and shooting rubber bands at the Slackware Linux booth staffers. > >Walnut Creek CDROM's booth will be at the Sands, and should be >listed on the Exhibitors map. > >If you're in the area, please stop by and see us! > > Jordan ---------------------------------- E-Mail: Christian Fortin Date: 11/14/96 Heure: 16:38:14 ##################################################--------+ Electro-Conception tel:(418) 872-6641 | 3665 Croisset fax:(418) 872-9198 | Quebec,P.Q. www.ec.camitel.com/ec | Canada ftp.ec.camitel.com | G1P-1L4 | /----|<|----WM--|(--J --------------------------L---WM-----< \----1 --- - From owner-freebsd-hackers Thu Nov 14 14:42:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA12714 for hackers-outgoing; Thu, 14 Nov 1996 14:42:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA12694 for ; Thu, 14 Nov 1996 14:42:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA24870; Thu, 14 Nov 1996 15:28:02 -0700 From: Terry Lambert Message-Id: <199611142228.PAA24870@phaeton.artisoft.com> Subject: Re: Programming technique for non-forking servers? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 14 Nov 1996 15:28:02 -0700 (MST) Cc: proff@suburbia.net, hackers@FreeBSD.org In-Reply-To: <199611141919.NAA25758@brasil.moneng.mei.com> from "Joe Greco" at Nov 14, 96 01:19:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Since most FreeBSD machines are not yet SMP, the advantage of multiple > processors is probably not an issue, so I would most likely not consider > threads on a FreeBSD box... Threading in general has advantages over not threading. *Kernel* threading has advantages in terms of SMP scalability. Whether or not to consider *threading at all* is something that should be done independent of considering *kernel threading in particular*. > Kernel level support for threading (or threads in general, for that matter) > may not be particularly portable in any case. It will be irrelevant, being hidden below a POSIX API, no matter how it is implemented by the underlying system. The POSIX threading uses signals to initiate context switches using a user space threads scheduler. > I guess I would not consider this viable unless someone told me up front > that there was a single platform that was being targeted, and there was > a clear advantage to the use of threads in the given context, and the > thread support on the platform in question was known to be good. The clear advantage is context sharing between multiple threads of execution (which could be processes or threads or whatever) *without* resorting to UNIX IPC, which is (to say the least) arcane. As a side benefit, context switch overhead is reduces between threads in the same thread group (the definition of a process), assuming that you don't implement your threads like SVR4 and Solaris implemented their kernel threads. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 14 14:45:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA12970 for hackers-outgoing; Thu, 14 Nov 1996 14:45:02 -0800 (PST) Received: from nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA12934 for ; Thu, 14 Nov 1996 14:44:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id OAA08726; Thu, 14 Nov 1996 14:44:26 -0800 (PST) Date: Thu, 14 Nov 1996 14:44:25 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: John Capo cc: FreeBSD Hackers Subject: Re: gated problems In-Reply-To: <199611141505.KAA27671@irbs.irbs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, John Capo wrote: > This fixes core dumps when interfaces (usually PPP or SLIP) came up > and went down alot. [patch deleted] thank you very much... this patch also works against 3.6a2... I finished making gated my self just minutes before I recieved your message... from what I have seen so far it does fix it... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Thu Nov 14 14:46:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13037 for hackers-outgoing; Thu, 14 Nov 1996 14:46:01 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA12781 for ; Thu, 14 Nov 1996 14:43:51 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id RAA10291; Thu, 14 Nov 1996 17:43:47 -0500 (EST) Date: Thu, 14 Nov 1996 17:43:46 -0500 (EST) From: "Marc G. Fournier" To: John Polstra cc: hackers@freebsd.org Subject: Re: Sockets question... In-Reply-To: <199611142115.NAA10054@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, John Polstra wrote: > > Ack...that sounds like exactly the problem...I misunderstood > > the read() call :( > > > > Why does 512k work fine though? no data lose at all.... > > > > I'm going to code in your suggestion above, but I'm very > > curious now as to why 512bytes and 80bytes both work cleanly, but > > 256bytes "loses" data... > > It depends on so many things, all timing related. Tomorrow you might > try it again and see it behave entirely differently. Run the server on > a machine on the other side of the Internet, and it will behave > differently still. You just can't reliably predict what it's going to > do. > Okay, makes sense...I'll fix the code tonight, thanks... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Thu Nov 14 14:50:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13615 for hackers-outgoing; Thu, 14 Nov 1996 14:50:30 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA13581 for ; Thu, 14 Nov 1996 14:50:16 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA26418; Thu, 14 Nov 1996 16:48:09 -0600 From: Joe Greco Message-Id: <199611142248.QAA26418@brasil.moneng.mei.com> Subject: Re: Sockets question... To: scrappy@ki.net (Marc G. Fournier) Date: Thu, 14 Nov 1996 16:48:09 -0600 (CST) Cc: jdp@polstra.com, hackers@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at Nov 14, 96 02:44:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > On Thu, 14 Nov 1996, John Polstra wrote: > > > > Basically, the server opens up a binary file and sends the data > > > to the client. The client is connecting to the server no problem, but I'm > > > don't seem to be able to send >79 bytes across the socket > > > > What happens? Does it hang? Is data lost? It should work fine. > > At 1024, data seems to be lost. I send 1023 bytes across, and > receive 4...send 1023, receive 907...I send across 100 packets, receive > 2... > > As soon as I go to 512 or 80 byte writes, I can pound at it > repeatedly and get the complete image across every time, no errors. Are you checking the return value from write() to make sure it actually thinks that N bytes were _written_? ... JG From owner-freebsd-hackers Thu Nov 14 15:11:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA16498 for hackers-outgoing; Thu, 14 Nov 1996 15:11:35 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA16486 for ; Thu, 14 Nov 1996 15:11:29 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA26489; Thu, 14 Nov 1996 17:08:25 -0600 From: Joe Greco Message-Id: <199611142308.RAA26489@brasil.moneng.mei.com> Subject: Re: Programming technique for non-forking servers? To: terry@lambert.org (Terry Lambert) Date: Thu, 14 Nov 1996 17:08:24 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, proff@suburbia.net, hackers@FreeBSD.org In-Reply-To: <199611142228.PAA24870@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 96 03:28:02 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Was wondering when Terry would jump in.. > Threading in general has advantages over not threading. > > *Kernel* threading has advantages in terms of SMP scalability. > > Whether or not to consider *threading at all* is something that should > be done independent of considering *kernel threading in particular*. Threading in general has the distinct advantage of being moderately portable: i.e. you can expect it not to work right somewhere. :-) > > Kernel level support for threading (or threads in general, for that matter) > > may not be particularly portable in any case. > > It will be irrelevant, being hidden below a POSIX API, no matter how > it is implemented by the underlying system. "Oh." Well, what "will" be is irrelevant, because right now, what "is" does not necessarily fit my notion of irrelevancy. I agree that this should be the goal. I disagree that what you are saying exists today - because it does not. > The POSIX threading uses signals to initiate context switches using a > user space threads scheduler. Hmmmm. > > I guess I would not consider this viable unless someone told me up front > > that there was a single platform that was being targeted, and there was > > a clear advantage to the use of threads in the given context, and the > > thread support on the platform in question was known to be good. > > The clear advantage is context sharing between multiple threads of > execution (which could be processes or threads or whatever) *without* > resorting to UNIX IPC, which is (to say the least) arcane. As a side > benefit, context switch overhead is reduces between threads in the same > thread group (the definition of a process), assuming that you don't > implement your threads like SVR4 and Solaris implemented their kernel > threads. Assume I am familiar with the Solaris threads model. The reason that POSIX threads have reduced cxsw overhead is that signals are used? (I honestly do not know). In any case, I usually try to be pessimistic when I write code. That probably means that I will not be writing threaded code for several more years, at least if I plan to use the program under more than one OS. That is simply pessimism on my part about "POSIX threads". ;-) ... JG From owner-freebsd-hackers Thu Nov 14 15:48:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21328 for hackers-outgoing; Thu, 14 Nov 1996 15:48:46 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA21131 for ; Thu, 14 Nov 1996 15:48:04 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id SAA11803; Thu, 14 Nov 1996 18:47:16 -0500 (EST) Date: Thu, 14 Nov 1996 18:47:16 -0500 (EST) From: "Marc G. Fournier" To: Joe Greco cc: jdp@polstra.com, hackers@FreeBSD.org Subject: Re: Sockets question... In-Reply-To: <199611142248.QAA26418@brasil.moneng.mei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, Joe Greco wrote: > > On Thu, 14 Nov 1996, John Polstra wrote: > > > > > > Basically, the server opens up a binary file and sends the data > > > > to the client. The client is connecting to the server no problem, but I'm > > > > don't seem to be able to send >79 bytes across the socket > > > > > > What happens? Does it hang? Is data lost? It should work fine. > > > > At 1024, data seems to be lost. I send 1023 bytes across, and > > receive 4...send 1023, receive 907...I send across 100 packets, receive > > 2... > > > > As soon as I go to 512 or 80 byte writes, I can pound at it > > repeatedly and get the complete image across every time, no errors. > > Are you checking the return value from write() to make sure it actually > thinks that N bytes were _written_? > *sigh* Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Thu Nov 14 16:04:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23222 for hackers-outgoing; Thu, 14 Nov 1996 16:04:46 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23207 for ; Thu, 14 Nov 1996 16:04:36 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id QAA10843; Thu, 14 Nov 1996 16:02:52 -0800 (PST) Message-Id: <199611150002.QAA10843@austin.polstra.com> To: "Marc G. Fournier" cc: Joe Greco , hackers@FreeBSD.org Subject: Re: Sockets question... In-reply-to: Your message of "Thu, 14 Nov 1996 18:47:16 EST." References: Date: Thu, 14 Nov 1996 16:02:52 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Are you checking the return value from write() to make sure it actually > > thinks that N bytes were _written_? > > > *sigh* Well now, wait a minute. As long as you haven't set the socket for non-blocking I/O, the write will always block until it's written the full N bytes that you asked for. In other words, the write will always return either -1 or N. Only if it's set up for non-blocking I/O can it return a short count. Writes are different from reads in this respect. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 14 16:23:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA26394 for hackers-outgoing; Thu, 14 Nov 1996 16:23:46 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA26386 for ; Thu, 14 Nov 1996 16:23:42 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id TAA13074; Thu, 14 Nov 1996 19:22:09 -0500 (EST) Date: Thu, 14 Nov 1996 19:22:08 -0500 (EST) From: "Marc G. Fournier" To: John Polstra cc: Joe Greco , hackers@FreeBSD.org Subject: Re: Sockets question... In-Reply-To: <199611150002.QAA10843@austin.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, John Polstra wrote: > > > Are you checking the return value from write() to make sure it actually > > > thinks that N bytes were _written_? > > > > > *sigh* > > Well now, wait a minute. As long as you haven't set the socket for > non-blocking I/O, the write will always block until it's written the > full N bytes that you asked for. In other words, the write will always > return either -1 or N. Only if it's set up for non-blocking I/O can it > return a short count. Writes are different from reads in this respect. > Oh good, that's what *I* thought...but since I'm totally new to socket programming...I foolishly didn't question :) Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Thu Nov 14 16:36:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA27510 for hackers-outgoing; Thu, 14 Nov 1996 16:36:46 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA27500 for ; Thu, 14 Nov 1996 16:36:40 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id QAA24389; Thu, 14 Nov 1996 16:35:33 -0800 (PST) From: "Rodney W. Grimes" Message-Id: <199611150035.QAA24389@GndRsh.aac.dev.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: from Todd at "Nov 14, 96 09:23:27 am" To: todd@gov.com (Todd) Date: Thu, 14 Nov 1996 16:35:32 -0800 (PST) Cc: jkh@time.cdrom.com, hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > On Thu, 14 Nov 1996, Jordan K. Hubbard wrote: > > > > BOCA BB2016 16 port serial card using shared IRQ (Has neen supported > > > for ages) > > > > Thanks, added. > > > > Jordan > > > Actually, I've been using just such an adapter with 2.0.5-RELEASE and a > kernel config file that someone helped me generate. I saw mention of the > board being used by someone on the mailing list archives on > www.freebsd.org, and emailed the person for help on doing it myself. I > have to admit, though, neither of us have gotten around to testing ports > beyond the first 8. Still, the Boca 8-port board (and 4-port for that > matter) doesn't have carrier detect lines, so the 16-port board is the > only one they make that works with modems. I got the thing because I'm > too cheap to get a RisCom or Cyclades or Digi, but at the time I had need > of more than 4 ports... I have clients with 2 and 3 of these cards in one system running 32 and 48 ports respectifully. It will work for you when you go above your current 4 port utilization. You are correct about the 8 port not having modem control, but I think the (not positive here) the 4 port does. If not I _know_ the 6 port board does. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-hackers Thu Nov 14 17:20:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA29914 for hackers-outgoing; Thu, 14 Nov 1996 17:20:41 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA29905 for ; Thu, 14 Nov 1996 17:20:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA25059; Thu, 14 Nov 1996 18:07:48 -0700 From: Terry Lambert Message-Id: <199611150107.SAA25059@phaeton.artisoft.com> Subject: Re: Programming technique for non-forking servers? To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 14 Nov 1996 18:07:48 -0700 (MST) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, proff@suburbia.net, hackers@FreeBSD.org In-Reply-To: <199611142308.RAA26489@brasil.moneng.mei.com> from "Joe Greco" at Nov 14, 96 05:08:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > It will be irrelevant, being hidden below a POSIX API, no matter how > > it is implemented by the underlying system. > > "Oh." > > Well, what "will" be is irrelevant, because right now, what "is" does not > necessarily fit my notion of irrelevancy. > > I agree that this should be the goal. I disagree that what you are > saying exists today - because it does not. Heh. Since we don't have kernel threading, the pthreads API, which is a POSIX threading API, "hides" the implementation. You don't have to worry about it being incompatible with kernel threading API's, since there aren't any. 8-). > > The clear advantage is context sharing between multiple threads of > > execution (which could be processes or threads or whatever) *without* > > resorting to UNIX IPC, which is (to say the least) arcane. As a side > > benefit, context switch overhead is reduces between threads in the same > > thread group (the definition of a process), assuming that you don't > > implement your threads like SVR4 and Solaris implemented their kernel > > threads. > > Assume I am familiar with the Solaris threads model. The reason that > POSIX threads have reduced cxsw overhead is that signals are used? (I > honestly do not know). Nope. The Solaris/SVR4 kernel threads have higher context switch overhead because the block a kernel context in a blocking system call instead of converting the blocking system call into a non-blocking call and woing a thread context switch. Basically, even though they are called "threads", you will be changing which kernel schedulable entity is running each time you make a blocking call. A user space implementation (like pthreads) exports a blocking call interface to the thread making the call, but converts it into a non-blocking call and a threads context switch inside the same kernel schedulable entity. In other words, the Solaris/SVR4 implementation will give away process quantum which "rightfully" belongs to you when you make a blocking system call, but the pthreads implementation will only give away quantum when all threads are blocked (no more work to do) or when your process has consumed its *entire* quantum and is forcibly context switched. > In any case, I usually try to be pessimistic when I write code. That > probably means that I will not be writing threaded code for several > more years, at least if I plan to use the program under more than one > OS. That is simply pessimism on my part about "POSIX threads". ;-) You might as well have been pessimistic about "POSIX open" several years ago, when it was possible for technically "conforming" implementations to have different behaviour. 8-). If the system has threads, it's a good bet that if you use the POSIX threads interface, no matter what local "extensions" they have for binding user space threads to kernel threads, etc., the interface you will be using will be constant across systems. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 14 17:26:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA00257 for hackers-outgoing; Thu, 14 Nov 1996 17:26:10 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA00252 for ; Thu, 14 Nov 1996 17:26:08 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA25075; Thu, 14 Nov 1996 18:12:13 -0700 From: Terry Lambert Message-Id: <199611150112.SAA25075@phaeton.artisoft.com> Subject: Re: Sockets question... To: jdp@polstra.com (John Polstra) Date: Thu, 14 Nov 1996 18:12:13 -0700 (MST) Cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG In-Reply-To: <199611150002.QAA10843@austin.polstra.com> from "John Polstra" at Nov 14, 96 04:02:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Are you checking the return value from write() to make sure it actually > > > thinks that N bytes were _written_? > > > > > *sigh* > > Well now, wait a minute. As long as you haven't set the socket for > non-blocking I/O, the write will always block until it's written the > full N bytes that you asked for. In other words, the write will always > return either -1 or N. Only if it's set up for non-blocking I/O can it > return a short count. Writes are different from reads in this respect. The problem that is supposedly being addressed by looking at the bytes written is knowing that the data will be available as a unit to the reader. There is no such guarantee. If you don't use non-blocking I/O, the read will block until the buffer is full. Use blocking I/O, and you won't have the problem with the reader returning before it should (or shouldn't). Otherwise the RPC interfaces wouldn't work at all. Instead of making a non-blocking read for which "it's OK if no data is available", use select() and only call a blocking read if the select is true. Any hang problems from fragmentation, etc. that happen after that are a result of you not marchalling your interfaces properly (again, I recommend the RPC code for examples). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Nov 14 17:30:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA00462 for hackers-outgoing; Thu, 14 Nov 1996 17:30:50 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA00456 for ; Thu, 14 Nov 1996 17:30:39 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id RAA11283; Thu, 14 Nov 1996 17:27:44 -0800 (PST) Message-Id: <199611150127.RAA11283@austin.polstra.com> To: Terry Lambert cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG Subject: Re: Sockets question... In-reply-to: Your message of "Thu, 14 Nov 1996 18:12:13 MST." <199611150112.SAA25075@phaeton.artisoft.com> References: <199611150112.SAA25075@phaeton.artisoft.com> Date: Thu, 14 Nov 1996 17:27:43 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If you don't use non-blocking I/O, the read will block until the > buffer is full. Use blocking I/O, and you won't have the problem > with the reader returning before it should (or shouldn't). This is most certainly not guaranteed by the documentation. From read(2): The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file, but in no other case. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 14 17:34:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA00647 for hackers-outgoing; Thu, 14 Nov 1996 17:34:09 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA00625 for ; Thu, 14 Nov 1996 17:34:05 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id RAA09469; Thu, 14 Nov 1996 17:33:06 -0800 (PST) To: Masahiro SEKIGUCHI cc: hackers@freebsd.org Subject: Re: FreeBSD 2.2-ALPHA is now available. In-reply-to: Your message of "Fri, 15 Nov 1996 10:14:21 +0900." <199611150114.KAA21289@sphinx.sysrap.cs.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9466.848021586.1@time.cdrom.com> Date: Thu, 14 Nov 1996 17:33:06 -0800 Message-ID: <9467.848021586@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The bug was in 961014 SNAP, but I didn't notice it until recently. > > Sorry for this inconvenience. Hey, no problem - thanks for noticing and working on it! That's what ALPHA releases are for, after all. :-) Jordan From owner-freebsd-hackers Thu Nov 14 17:40:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA01107 for hackers-outgoing; Thu, 14 Nov 1996 17:40:13 -0800 (PST) Received: from ec.camitel.com (ec.camitel.com [206.231.123.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA01056 for ; Thu, 14 Nov 1996 17:40:06 -0800 (PST) Received: (from cfortin@localhost) by ec.camitel.com (8.7.5/8.7.3) id UAA23137; Thu, 14 Nov 1996 20:40:55 -0500 (EST) Message-ID: X-Mailer: XFMail 0.4 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199611150114.KAA21289@sphinx.sysrap.cs.fujitsu.co.jp> Date: Thu, 14 Nov 1996 20:40:03 -0500 (EST) Organization: =?us-ascii?Q?=C9lectro-Conception?= From: Christian Fortin To: Masahiro SEKIGUCHI Subject: Re: FreeBSD 2.2-ALPHA is now available. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk No news about my GATEWAY Driver, Do you have check about it ? On 15-Nov-96 Masahiro SEKIGUCHI wrote: >>I must say that fe driver (if_fe.c) in 2.2-ALPHA is broken and doesn't >work. I'm now updating the driver, and a patch will be available soon. > >The bug was in 961014 SNAP, but I didn't notice it until recently. > >Sorry for this inconvenience. > > Masahiro Sekiguchi > (Original fe developer) ---------------------------------- E-Mail: Christian Fortin Date: 11/14/96 Heure: 20:40:03 ##################################################--------+ Electro-Conception tel:(418) 872-6641 | 3665 Croisset fax:(418) 872-9198 | Quebec,P.Q. www.ec.camitel.com/ec | Canada ftp.ec.camitel.com | G1P-1L4 | /----|<|----WM--|(--J --------------------------L---WM-----< \----1 --- - From owner-freebsd-hackers Thu Nov 14 17:56:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA02107 for hackers-outgoing; Thu, 14 Nov 1996 17:56:41 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA02100 for ; Thu, 14 Nov 1996 17:56:38 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id TAA08574; Thu, 14 Nov 1996 19:53:22 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id TAA12446; Thu, 14 Nov 1996 19:53:21 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id TAA23161; Thu, 14 Nov 1996 19:53:20 -0600 (CST) From: Karl Denninger Message-Id: <199611150153.TAA23161@Mercury.mcs.net> Subject: Re: Sockets question... To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 14 Nov 1996 19:53:20 -0600 (CST) Cc: scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611142248.QAA26418@brasil.moneng.mei.com> from "Joe Greco" at Nov 14, 96 04:48:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > On Thu, 14 Nov 1996, John Polstra wrote: > > > > > > Basically, the server opens up a binary file and sends the data > > > > to the client. The client is connecting to the server no problem, but I'm > > > > don't seem to be able to send >79 bytes across the socket > > > > > > What happens? Does it hang? Is data lost? It should work fine. > > > > At 1024, data seems to be lost. I send 1023 bytes across, and > > receive 4...send 1023, receive 907...I send across 100 packets, receive > > 2... > > > > As soon as I go to 512 or 80 byte writes, I can pound at it > > repeatedly and get the complete image across every time, no errors. > > Are you checking the return value from write() to make sure it actually > thinks that N bytes were _written_? > > ... JG Uh, hang on a second... Are you saying that the behavior of a *TCP* connection is such that you would expect to see a write(2) call to the socket come back with a short count for any reason other than the remote having closed or some other kind of transport error (ie: host unreachable, etc)? That may well be technically *legal*, but its *NOT* the behavior that a LOT of applications depend on, nor is it behavior I've seen from *ANY* other Unix system at any time in the past five years! Now UDP can (and does) come back with short counts if buffer space is low. And we all know that read()s can return short counts (and frequently do). I'm questioning write(2) behavior to TCP sockets here. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Thu Nov 14 18:12:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA03016 for hackers-outgoing; Thu, 14 Nov 1996 18:12:22 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA03011 for ; Thu, 14 Nov 1996 18:12:21 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id SAA01052 for ; Thu, 14 Nov 1996 18:11:13 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15123(5)>; Thu, 14 Nov 1996 18:09:11 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Thu, 14 Nov 1996 18:08:24 -0800 To: "Marc G. Fournier" cc: John Polstra , hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Thu, 14 Nov 96 11:44:03 PST." Date: Thu, 14 Nov 1996 18:08:23 PST From: Bill Fenner Message-Id: <96Nov14.180824pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message you write : > At 1024, data seems to be lost. I send 1023 bytes across, and >receive 4...send 1023, receive 907...I send across 100 packets, receive >2... TCP is not a record-oriented protocol, and will buffer up (or re-packetize however it wants) any data that you give it. Therefore, you have to be prepared to read whatever size it wants to give you, and your application has to be able to put it back together into what it wants. Your data will all get there, eventually. > As soon as I go to 512 or 80 byte writes, I can pound at it >repeatedly and get the complete image across every time, no errors. Depending on the verison of FreeBSD, 512 bytes could be the TCP MSS, so every time you write 512 bytes TCP realizes it has a whole packet to send and sends it. This could be different depending on the version of FreeBSD and the MTU of the path, among other things. I don't explicitly know why 80 "works", but perhaps there is a threshold of "small" writes that TCP will write immediately. These are not behaviors you can depend on. The MSS could be different depending on who you are talking to, and the "small" is just a guess on my part anyway. What you need to do is write all your data to the network, and not count on it arriving in the same sized chunks as you wrote it. But it will all arrive. Bill From owner-freebsd-hackers Thu Nov 14 18:19:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA03387 for hackers-outgoing; Thu, 14 Nov 1996 18:19:50 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA03382 for ; Thu, 14 Nov 1996 18:19:48 -0800 (PST) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id SAA01064 for ; Thu, 14 Nov 1996 18:19:46 -0800 (PST) Received: from skipper.eng.umd.edu (skipper.eng.umd.edu [129.2.103.24]) by po1.glue.umd.edu (8.8.2/8.7.3) with ESMTP id VAA03854 for ; Thu, 14 Nov 1996 21:18:19 -0500 (EST) Received: from localhost (chuckr@localhost) by skipper.eng.umd.edu (8.7.5/8.7.3) with SMTP id VAA12348 for ; Thu, 14 Nov 1996 21:18:15 -0500 (EST) X-Authentication-Warning: skipper.eng.umd.edu: chuckr owned process doing -bs Date: Thu, 14 Nov 1996 21:18:13 -0500 (EST) From: Chuck Robey X-Sender: chuckr@skipper.eng.umd.edu To: FreeBSD-Hackers Subject: Interesting URL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I found an interesting URL full of some neat C++ graphics and network code. I'm always complaining to friends that C++ doesn't have enough public code out there, so this is a nice surprise I thought I'd share. http://www.viewport.com/ Happy hacking! ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Thu Nov 14 18:50:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05373 for hackers-outgoing; Thu, 14 Nov 1996 18:50:49 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA05363 for ; Thu, 14 Nov 1996 18:50:43 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA05666; Thu, 14 Nov 1996 21:50:11 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 14 Nov 1996 21:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id UAA23634; Thu, 14 Nov 1996 20:46:04 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id UAA20711; Thu, 14 Nov 1996 20:47:35 -0500 (EST) Date: Thu, 14 Nov 1996 20:47:35 -0500 (EST) From: Thomas David Rivers Message-Id: <199611150147.UAA20711@lakes.water.net> To: terry@lambert.org, ponds!root.com!dg Subject: Re: Even more info on daily panics... Cc: ponds!FreeBSD.org!Hackers, ponds!cet.co.jp!michaelh, ponds!ponds!rivers, ponds!lambert.org!terry Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If that were all it was, David's problems would not have gone away for > 4+ days now with my patch. > > There are at least three people running the patch over the past 15 > months, besides myself, and all of them have reported (to me) that the > problem has gone away. > > Like it or not, I have identified a problem and provided a patch. Again, I hate to be a bearer of less-than-good news; but I've got a kernel, with your patch installed, that still gets my panic. I can't explain why it did not get the panic before... (see my other mail.) - Dave Rivers - From owner-freebsd-hackers Thu Nov 14 18:50:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05380 for hackers-outgoing; Thu, 14 Nov 1996 18:50:51 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA05361 for ; Thu, 14 Nov 1996 18:50:42 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA05521; Thu, 14 Nov 1996 21:50:07 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 14 Nov 1996 21:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id UAA23462; Thu, 14 Nov 1996 20:37:41 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id UAA20669; Thu, 14 Nov 1996 20:39:12 -0500 (EST) Date: Thu, 14 Nov 1996 20:39:12 -0500 (EST) From: Thomas David Rivers Message-Id: <199611150139.UAA20669@lakes.water.net> To: terry@lambert.org, ponds!root.com!dg Subject: Re: Even more info on daily panics... Cc: ponds!FreeBSD.org!Hackers, ponds!cet.co.jp!michaelh, ponds!ponds!rivers, ponds!lambert.org!terry Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If you look at the BSD4.4-Lite2 code, you will see they cleaned this > up (using a fix just as kludgy as my one liner) by using kern_lock.c > functions instead of smearing the lock state. Err, umm, I had to be a naysayer - but I've gotten two examples of the one-liner fix that didn't address my particular problem. Granted, I could have messed something up; I'd be happy to retry it all... - Dave Rivers - From owner-freebsd-hackers Thu Nov 14 18:51:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05438 for hackers-outgoing; Thu, 14 Nov 1996 18:51:10 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA05354 for ; Thu, 14 Nov 1996 18:50:23 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id UAA10284; Thu, 14 Nov 1996 20:46:57 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id UAA20993; Thu, 14 Nov 1996 20:46:56 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id UAA13803; Thu, 14 Nov 1996 20:46:56 -0600 (CST) From: Karl Denninger Message-Id: <199611150246.UAA13803@Jupiter.Mcs.Net> Subject: Re: Sockets question... To: jdp@polstra.com (John Polstra) Date: Thu, 14 Nov 1996 20:46:55 -0600 (CST) Cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.org In-Reply-To: <199611150002.QAA10843@austin.polstra.com> from "John Polstra" at Nov 14, 96 04:02:52 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > Are you checking the return value from write() to make sure it actually > > > thinks that N bytes were _written_? > > > > > *sigh* > > Well now, wait a minute. As long as you haven't set the socket for > non-blocking I/O, the write will always block until it's written the > full N bytes that you asked for. In other words, the write will always > return either -1 or N. Only if it's set up for non-blocking I/O can it > return a short count. Writes are different from reads in this respect. > > John Don't bet on it. I'm seeing this behavior from -current too. See my other post regarding this subject. I have an application which sends a query to a back-end server -- and that server can return literally hundreds of KB of data in response. On very long responses, it just STOPS. The writing end thinks it wrote all of the data, netstat -an shows nothing in the socket buffers, the reader is waiting in read() for more data (it never saw the end marker, and in fact never saw more than half of the response!) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Thu Nov 14 19:01:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06264 for hackers-outgoing; Thu, 14 Nov 1996 19:01:31 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA06255 for ; Thu, 14 Nov 1996 19:01:23 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id SAA12064; Thu, 14 Nov 1996 18:58:11 -0800 (PST) Message-Id: <199611150258.SAA12064@austin.polstra.com> To: Karl Denninger cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.org Subject: Re: Sockets question... In-reply-to: Your message of "Thu, 14 Nov 1996 20:46:55 CST." <199611150246.UAA13803@Jupiter.Mcs.Net> References: <199611150246.UAA13803@Jupiter.Mcs.Net> Date: Thu, 14 Nov 1996 18:58:11 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I have an application which sends a query to a back-end server -- and that > server can return literally hundreds of KB of data in response. > > On very long responses, it just STOPS. > > The writing end thinks it wrote all of the data, netstat -an shows nothing > in the socket buffers, the reader is waiting in read() for more data (it > never saw the end marker, and in fact never saw more than half of the > response!) If the socket is not in non-blocking mode, and you do a write(2) of N bytes to it, and the write call returns anything other than -1 or N, then that is a bug. If the sending socket returns N, but not all of the data gets to the receiving socket, then that is either a bug or a network problem. >From write(2): When using non-blocking I/O on objects such as sockets that are subject ^^^^^^^^^^^^ to flow control, write() and writev() may write fewer bytes than request- ed; the return value must be noted, and the remainder of the operation should be retried when possible. OK, it doesn't come right out and say directly that it _won't_ do that when using blocking I/O. But that is the implication. And it is the historical behavior. And it is the behavior that probably 90% of network applications are written to expect. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Thu Nov 14 19:15:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06913 for hackers-outgoing; Thu, 14 Nov 1996 19:15:51 -0800 (PST) Received: from hq.icb.chel.su (hq.icb.chel.su [193.125.10.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA06872; Thu, 14 Nov 1996 19:13:13 -0800 (PST) Received: (babkin@localhost) by hq.icb.chel.su (8.7.5/8.6.5) id IAA01844; Fri, 15 Nov 1996 08:08:29 +0500 (ESK) From: "Serge A. Babkin" Message-Id: <199611150308.IAA01844@hq.icb.chel.su> Subject: Re: FreeBSD as Terminal Server To: max@run.net (Maxim Bolotin) Date: Fri, 15 Nov 1996 08:08:29 +0500 (ESK) Cc: alex@yahoo.com, hardware@FreeBSD.org, hackers@FreeBSD.org, max@rnd.runnet.ru In-Reply-To: <328AD23F.41C67EA6@run.net> from "Maxim Bolotin" at Nov 14, 96 08:03:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Alexander Winske wrote: > > > > Howdy, > > I'm looking to set up a largish terminal server on > > a FreeBSD box. (I want to log console output and allow > > console sessions with approx. 75-100 hosts). > > > > Can anyone out there recommend a flavor of multiport > > serial card that will allow me to have that many ports? > > I would think that they wouldn't have to be doing more than > > 2400 baud each, if that makes any difference... > > > > tia, > > Alex > I think you can use DigiBoard PC/16i or PC/16e. It has 16 ports > with speed up to 115K. The model PC/16e is cheeper than other > 'cause it has only 64K buffer , other has 128K-512K. > The driver for 2.1.5, stable is work weel, Now I port it for > 2.2, I send it to author (Serge A. Babkin ) > He said me he'll send it to Bruce Evans. New version work very well. > I'm using PC/16e with 4 leased lines ( 28K ), 6 terminals (9600K) and > printer (9600K). All It work under 2.2-SNAP-141096. I can say you what Bruce replied to me :-) This driver needs lots of clean up. I hope I'll do it at this weekend. -SB From owner-freebsd-hackers Thu Nov 14 19:18:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA07210 for hackers-outgoing; Thu, 14 Nov 1996 19:18:54 -0800 (PST) Received: from rosemary.fsl.noaa.gov (rosemary.fsl.noaa.gov [137.75.8.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA07175; Thu, 14 Nov 1996 19:18:27 -0800 (PST) Received: from sage.fsl.noaa.gov (sage.fsl.noaa.gov [137.75.253.42]) by rosemary.fsl.noaa.gov (8.7.5/8.6.12) with SMTP id UAA25318; Thu, 14 Nov 1996 20:17:25 -0700 (MST) Message-ID: <328BE0C4.41C67EA6@fsl.noaa.gov> Date: Thu, 14 Nov 1996 20:17:24 -0700 From: Sean Kelly Organization: NOAA Forecast Systems Laboratory X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: Mark Mayo CC: hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: userland PPP giving weird load numbers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Mark Mayo wrote: > the ppp process causes the high load (which isn't real, BTW). Top shows it > as not doing a thing. As soon as I kill ppp off, the load drops right back > down. I see this too all the time, from 2.0.5 all the way to 2.1.5. While /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, it'll drop. It's odd ... it's usually when ppp is idle that it hangs around 1.0. -- Sean Kelly NOAA Forecast Systems Laboratory Boulder Colorado USA From owner-freebsd-hackers Thu Nov 14 19:32:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA08219 for hackers-outgoing; Thu, 14 Nov 1996 19:32:38 -0800 (PST) Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA08172 for ; Thu, 14 Nov 1996 19:32:27 -0800 (PST) Received: from gateway.cybernet.com (gateway.cybernet.com [192.245.33.1]) by gateway.cybernet.com (8.7.6/8.7.3) with SMTP id WAA25265; Thu, 14 Nov 1996 22:37:13 -0500 (EST) Date: Thu, 14 Nov 1996 22:37:13 -0500 (EST) From: "Mark J. Taylor" To: "Rodney W. Grimes" cc: Todd , jkh@time.cdrom.com, hackers@FreeBSD.org Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: <199611150035.QAA24389@GndRsh.aac.dev.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk My BOCA 4-port board is actually an 8 port with only one of the serial controller chips in it. Thus, it controls only 4 ports. I can purchase the chip to populate the empty socket for the other 4 ports, but I'm reluctant to do so, since I'm not really using the board, and it doesn't have all of the modem lines (like CD). It does have all 8 RJ connecters on the back end. Only 4 are usable with the one serial chip on the board, though. I like my FastComm-4 board. It works similar to an AST 4-port. It has all of the lines. -Mark Taylor mtaylor@cybernet.com On Thu, 14 Nov 1996, Rodney W. Grimes wrote: > > > > On Thu, 14 Nov 1996, Jordan K. Hubbard wrote: > > > > > > BOCA BB2016 16 port serial card using shared IRQ (Has neen supported > > > > for ages) > > > > > > Thanks, added. > > > > > > Jordan > > > > > Actually, I've been using just such an adapter with 2.0.5-RELEASE and a > > kernel config file that someone helped me generate. I saw mention of the > > board being used by someone on the mailing list archives on > > www.freebsd.org, and emailed the person for help on doing it myself. I > > have to admit, though, neither of us have gotten around to testing ports > > beyond the first 8. Still, the Boca 8-port board (and 4-port for that > > matter) doesn't have carrier detect lines, so the 16-port board is the > > only one they make that works with modems. I got the thing because I'm > > too cheap to get a RisCom or Cyclades or Digi, but at the time I had need > > of more than 4 ports... > > I have clients with 2 and 3 of these cards in one system running 32 and > 48 ports respectifully. It will work for you when you go above your > current 4 port utilization. > > You are correct about the 8 port not having modem control, but I think > the (not positive here) the 4 port does. If not I _know_ the 6 port > board does. > > > > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation, Inc. Reliable computers for FreeBSD > From owner-freebsd-hackers Thu Nov 14 19:55:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA09432 for hackers-outgoing; Thu, 14 Nov 1996 19:55:40 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA09423 for ; Thu, 14 Nov 1996 19:55:35 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id VAA26930; Thu, 14 Nov 1996 21:53:10 -0600 From: Joe Greco Message-Id: <199611150353.VAA26930@brasil.moneng.mei.com> Subject: Re: Sockets question... To: jdp@polstra.com (John Polstra) Date: Thu, 14 Nov 1996 21:53:09 -0600 (CST) Cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.org In-Reply-To: <199611150002.QAA10843@austin.polstra.com> from "John Polstra" at Nov 14, 96 04:02:52 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Are you checking the return value from write() to make sure it actually > > > thinks that N bytes were _written_? > > > > > *sigh* > > Well now, wait a minute. As long as you haven't set the socket for > non-blocking I/O, the write will always block until it's written the > full N bytes that you asked for. In other words, the write will always > return either -1 or N. Only if it's set up for non-blocking I/O can it > return a short count. Writes are different from reads in this respect. Hi John, I don't recall anybody specifying which was the case... maybe I forgot. Besides, I believe that good coding practice suggests that such things should be checked for unless you are REALLY concerned about performance and can NOT afford the hit of an extra compare and branch... My experience has been that code sometimes gets handed down, and assumptions that were one time true rapidly become false. I do not care to get into a style war about this, however... too much battling going on lately. :-) I'll just say that "that is how I would prefer to do it if it were my code." ... JG From owner-freebsd-hackers Thu Nov 14 20:19:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10402 for hackers-outgoing; Thu, 14 Nov 1996 20:19:01 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA10393 for ; Thu, 14 Nov 1996 20:18:48 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id WAA26986; Thu, 14 Nov 1996 22:14:35 -0600 From: Joe Greco Message-Id: <199611150414.WAA26986@brasil.moneng.mei.com> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Thu, 14 Nov 1996 22:14:34 -0600 (CST) Cc: jdp@polstra.com, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG In-Reply-To: <199611150112.SAA25075@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 96 06:12:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Well now, wait a minute. As long as you haven't set the socket for > > non-blocking I/O, the write will always block until it's written the > > full N bytes that you asked for. In other words, the write will always > > return either -1 or N. Only if it's set up for non-blocking I/O can it > > return a short count. Writes are different from reads in this respect. > > The problem that is supposedly being addressed by looking at the bytes > written is knowing that the data will be available as a unit to the > reader. Wrong, Terry. The problem that is supposedly being addressed (and as the person who wrote the advice, I am telling you indisputably that this is what is being addressed) is that sometimes, people will forget that they are writing to a particular type of socket (such as {,non}blocking) and will inadvertently forget to check to see if all the data was written. In the case of a blocking socket, the penalty is minor, an extra compare and branch, most likely. In the case of a nonblocking socket, the test is mandatory. In the case of an indeterminate socket, the test is also mandatory - precisely BECAUSE you don't know. > There is no such guarantee. > > If you don't use non-blocking I/O, the read will block until the buffer > is full. Use blocking I/O, and you won't have the problem with the > reader returning before it should (or shouldn't). Otherwise the RPC > interfaces wouldn't work at all. I am not too sure that statement is true... but then I am a paranoid programmer, so I always define an xread() function guaranteed to do what I mean. Still, that bothers me... > Instead of making a non-blocking read for which "it's OK if no data > is available", use select() and only call a blocking read if the select > is true. And I think this is what I was looking for... If you have a blocking read, select() returns true on a FD because one byte is available, and you try a read(1000), will it block? I am reasonably certain that it will not - it will return the one byte. Ahhh. Yes. % man 2 read (SunOS version) Upon successful completion, read() and readv() return the number of bytes actually read and placed in the buffer. The Sun Release 4.1 Last change: 21 January 1990 1 READ(2V) SYSTEM CALLS READ(2V) system guarantees to read the number of bytes requested if the descriptor references a normal file which has that many bytes left before the EOF (end of file), but in no other case. Key words, "but in no other case".. > Any hang problems from fragmentation, etc. that happen after that are > a result of you not marchalling your interfaces properly (again, I > recommend the RPC code for examples). ... JG From owner-freebsd-hackers Thu Nov 14 20:33:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA11009 for hackers-outgoing; Thu, 14 Nov 1996 20:33:39 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA11001 for ; Thu, 14 Nov 1996 20:33:33 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id WAA27067; Thu, 14 Nov 1996 22:30:39 -0600 From: Joe Greco Message-Id: <199611150430.WAA27067@brasil.moneng.mei.com> Subject: Re: Sockets question... To: karl@mcs.net (Karl Denninger) Date: Thu, 14 Nov 1996 22:30:39 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611150153.TAA23161@Mercury.mcs.net> from "Karl Denninger" at Nov 14, 96 07:53:20 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Are you checking the return value from write() to make sure it actually > > thinks that N bytes were _written_? > > > > ... JG > > Uh, hang on a second... > > Are you saying that the behavior of a *TCP* connection is such that you > would expect to see a write(2) call to the socket come back with a short > count for any reason other than the remote having closed or some other > kind of transport error (ie: host unreachable, etc)? Yes: a nonblocking socket write will most definitely display this behaviour. This allows a server application written with select() to continue to service other connections. Basically you use code something like this: char *outqueue[9999]; char *outcurrent = NULL; int main() { int my_fd; fd_set fds; while (1) if (outcurrent) FD_SET(my_fd, &fds) select(a, fds, c, NULL) if (FD_ISSET(my_fd, &fds)) { writemore(my_fd); } if (want_to_output_something) { writetofd(my_fd); } } writemore(fd) { int rval; rval = write(fd, outcurrent, strlen(outcurrent)); if (rval != strlen(outcurrent)) { outcurrent += strlen(outcurrent) - rval; } else { outcurrent = pop_entry(outqueue); } } writetofd(fd) { push_entry(outqueue, string); } Or something sorta like that. Hopefully you see the idea... you can keep writing data as space allows. Please excuse the horrid pcode. > That may well be technically *legal*, but its *NOT* the behavior that a LOT > of applications depend on, nor is it behavior I've seen from *ANY* other Unix > system at any time in the past five years! I see it all the time :-) You just generally do not see it on blocking sockets... I take that back. You will see it if you get a signal. Try writing lots of data over a slow link... and receive a signal. Bam. > Now UDP can (and does) come back with short counts if buffer space is low. > And we all know that read()s can return short counts (and frequently do). > > I'm questioning write(2) behavior to TCP sockets here. "Be conservative in what you expect of the system, liberal in what you accept." (An applicable rewrite of an old rule.) ... JG From owner-freebsd-hackers Thu Nov 14 20:38:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA11208 for hackers-outgoing; Thu, 14 Nov 1996 20:38:28 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA11202 for ; Thu, 14 Nov 1996 20:38:19 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id WAA27108; Thu, 14 Nov 1996 22:36:05 -0600 From: Joe Greco Message-Id: <199611150436.WAA27108@brasil.moneng.mei.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Thu, 14 Nov 1996 22:36:04 -0600 (CST) Cc: todd@gov.com, jkh@time.cdrom.com, hackers@FreeBSD.org In-Reply-To: <199611150035.QAA24389@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Nov 14, 96 04:35:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I have clients with 2 and 3 of these cards in one system running 32 and > 48 ports respectifully. It will work for you when you go above your > current 4 port utilization. > > You are correct about the 8 port not having modem control, but I think > the (not positive here) the 4 port does. If not I _know_ the 6 port > board does. 4 port does not, 6 port does. Unless the product offering has changed lately. ... JG From owner-freebsd-hackers Thu Nov 14 20:54:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA12298 for hackers-outgoing; Thu, 14 Nov 1996 20:54:47 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA12293 for ; Thu, 14 Nov 1996 20:54:40 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id UAA12629; Thu, 14 Nov 1996 20:51:54 -0800 (PST) Message-Id: <199611150451.UAA12629@austin.polstra.com> To: Joe Greco cc: scrappy@ki.net, hackers@FreeBSD.org Subject: Re: Sockets question... In-reply-to: Your message of "Thu, 14 Nov 1996 21:53:09 CST." <199611150353.VAA26930@brasil.moneng.mei.com> References: <199611150353.VAA26930@brasil.moneng.mei.com> Date: Thu, 14 Nov 1996 20:51:54 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Well now, wait a minute. As long as you haven't set the socket for > > non-blocking I/O, the write will always block until it's written the > > full N bytes that you asked for. In other words, the write will always > > return either -1 or N. Only if it's set up for non-blocking I/O can it > > return a short count. Writes are different from reads in this respect. ... > I don't recall anybody specifying which was the case... maybe I forgot. > > Besides, I believe that good coding practice suggests that such things > should be checked for unless you are REALLY concerned about performance > and can NOT afford the hit of an extra compare and branch... Oh sure, I agree 100% that you should always check the return value. I'd take your statement a step further and say that you can _never_ not affort the hit of an extra compare and branch. My argument was strictly from the perspective of finding an explanation for the apparent data loss that scrappy was seeing. I was arguing that, if the sending socket was in blocking mode, it would never return a short count and therefore couldn't explain the "lost" data in this case. I didn't mean it to sound as though I was recommending sloppy programming practices. John From owner-freebsd-hackers Thu Nov 14 21:52:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA16737 for hackers-outgoing; Thu, 14 Nov 1996 21:52:01 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA16731 for ; Thu, 14 Nov 1996 21:51:56 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vOH8m-00043c-00; Thu, 14 Nov 1996 22:48:36 -0700 To: Terry Lambert Subject: Re: data segment Cc: toor@dyson.iquest.net (John S. Dyson), cskim@cslsun10.sogang.ac.kr, freebsd-hackers@freebsd.org In-reply-to: Your message of "Thu, 14 Nov 1996 12:47:15 MST." <199611141947.MAA24628@phaeton.artisoft.com> References: <199611141947.MAA24628@phaeton.artisoft.com> Date: Thu, 14 Nov 1996 22:48:36 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611141947.MAA24628@phaeton.artisoft.com> Terry Lambert writes: : Any chance we can get some additional mappings defined to coincide with : the Microsoft mappings? I've been trying to load (and use) some simple : NT drivers, and they want "pageable" (which I wouldn't expect to do : anything, initially anyway) and "discradable" for init, etc., etc.. : : If you need a full list, I can provide it with a day or so lead time. Isn't the Microsoft NT stuff PEI format, which is basically COFF or ECOFF with some mutant headers and minor tweaks? Isn't that different than our current a.out? Or am I confused again. Warner From owner-freebsd-hackers Thu Nov 14 22:56:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA20194 for hackers-outgoing; Thu, 14 Nov 1996 22:56:35 -0800 (PST) Received: from PACBELL.net (cherokee.snfc21.pbi.net [206.13.28.35]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA20187 for ; Thu, 14 Nov 1996 22:56:32 -0800 (PST) Received: from ppp-206-170-120-62.sndg02.pacbell.net (ppp-206-170-120-62.sndg02.pacbell.net [206.170.120.62]) by PACBELL.net (8.7.6/8.7.1) with SMTP id WAA18307 for ; Thu, 14 Nov 1996 22:56:20 -0800 (PST) Received: by ppp-206-170-120-62.sndg02.pacbell.net with Microsoft Mail id <01BBD27F.0E1D4760@ppp-206-170-120-62.sndg02.pacbell.net>; Thu, 14 Nov 1996 22:56:22 -0800 Message-ID: <01BBD27F.0E1D4760@ppp-206-170-120-62.sndg02.pacbell.net> From: Miguel Kimbrough To: "'hackers@FreeBSD.org'" Subject: Wow can I get the simple version Date: Tue, 12 Nov 1996 22:33:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I visited your web site an thought I would attempt the downloading of = FreeBSD but much too my surprise the web site is not far from the = hiddenous that comes with any UNIX command.=20 All I want to know is who do I download the installation, do you have a = single zip file version? Do I have to download each of the directories? Why are some of the = directories blank? Miguel=20 Miguel@pacbell.net From owner-freebsd-hackers Thu Nov 14 22:58:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA20242 for hackers-outgoing; Thu, 14 Nov 1996 22:58:10 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA20236 for ; Thu, 14 Nov 1996 22:58:02 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id WAA10399 for ; Thu, 14 Nov 1996 22:58:10 -0800 (PST) To: hackers@freebsd.org Subject: Cogent EM-960TP, 32bit PCI NIC Date: Thu, 14 Nov 1996 22:58:10 -0800 Message-ID: <10397.848041090@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is anyone using one of these successfully with FreeBSD? If so, please state which version in your reply. I'd like to know for certain whether it should be added to the supported device list - thanks! Jordan From owner-freebsd-hackers Thu Nov 14 23:02:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA20638 for hackers-outgoing; Thu, 14 Nov 1996 23:02:46 -0800 (PST) Received: from casparc.ppp.net (casparc.ppp.net [194.64.12.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA20576; Thu, 14 Nov 1996 23:02:24 -0800 (PST) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0vOIHq-000I9dC; Fri, 15 Nov 96 08:02 MET Received: by ernie.kts.org (Smail3.1.29.1 #5) id m0vOHoc-00001bC; Fri, 15 Nov 96 07:31 MET Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: userland PPP giving weird load numbers To: kelly@fsl.noaa.gov (Sean Kelly) Date: Fri, 15 Nov 1996 07:31:50 +0100 (MET) Cc: mark@quickweb.com, hackers@FreeBSD.org, current@FreeBSD.org In-Reply-To: <328BE0C4.41C67EA6@fsl.noaa.gov> from "Sean Kelly" at Nov 14, 96 08:17:24 pm Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Sean Kelly wrote: > > Mark Mayo wrote: > > > the ppp process causes the high load (which isn't real, BTW). Top shows it > > as not doing a thing. As soon as I kill ppp off, the load drops right back > > down. > > I see this too all the time, from 2.0.5 all the way to 2.1.5. While > /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, > it'll drop. It's odd ... it's usually when ppp is idle that it hangs > around 1.0. I had this phenomenon too - but NOT with ppp. An isdn userland daemon i am working on showed this exact behaviour; when it was running, the system load was constantly 1.0 or very nearby. This all is under 2.1.5 (and 2.1 too). The process wasn't doing anything (or very little). My impression is that there is something wrong in the kernel, not in the applications. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe (A)bort, (R)etry, (I)nstall BSD ? -------------------------------------------------------------------------------- kts.org will move and will be not available from November 20th for 10 days -------------------------------------------------------------------------------- From owner-freebsd-hackers Thu Nov 14 23:56:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA23987 for hackers-outgoing; Thu, 14 Nov 1996 23:56:29 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA23951; Thu, 14 Nov 1996 23:56:20 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id SAA06861; Fri, 15 Nov 1996 18:26:02 +1030 (CST) From: Michael Smith Message-Id: <199611150756.SAA06861@genesis.atrad.adelaide.edu.au> Subject: Re: userland PPP giving weird load numbers In-Reply-To: from Hellmuth Michaelis at "Nov 15, 96 07:31:50 am" To: hm@kts.org Date: Fri, 15 Nov 1996 18:26:01 +1030 (CST) Cc: kelly@fsl.noaa.gov, mark@quickweb.com, hackers@FreeBSD.org, current@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hellmuth Michaelis stands accused of saying: > > > > I see this too all the time, from 2.0.5 all the way to 2.1.5. While > > /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, > > it'll drop. It's odd ... it's usually when ppp is idle that it hangs > > around 1.0. > > I had this phenomenon too - but NOT with ppp. An isdn userland daemon i am > working on showed this exact behaviour; when it was running, the system load > was constantly 1.0 or very nearby. This all is under 2.1.5 (and 2.1 too). > The process wasn't doing anything (or very little). But what _was_ it supposed to be doing? > My impression is that there is something wrong in the kernel, not in the > applications. I'd be inclined to say that there's something wrong in the applications, not in the kernel, actually. There's a chance that you have a driver problem (perhaps a broken select() handler), but the major causes of this sort of thing are applications failing to realise that a 0 return from a read() indicates EOF. Another possible is not checking all the bits enabled for a select(). Why not be a bit intelligent; attach a debugger to the offending process and wait for it to go gaga, then look at it to see what it's doing? > Hellmuth Michaelis -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Fri Nov 15 00:05:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA24880 for hackers-outgoing; Fri, 15 Nov 1996 00:05:23 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA24863 for ; Fri, 15 Nov 1996 00:05:13 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id AAA11220; Fri, 15 Nov 1996 00:05:16 -0800 (PST) To: Miguel Kimbrough cc: "'hackers@FreeBSD.org'" Subject: Re: Wow can I get the simple version In-reply-to: Your message of "Wed, 13 Nov 1996 14:18:54 PST." <01BBD27F.14132860@ppp-206-170-120-62.sndg02.pacbell.net> Date: Fri, 15 Nov 1996 00:05:16 -0800 Message-ID: <11218.848045116@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I visited your web site an thought I would attempt the downloading of = > FreeBSD but much too my surprise the web site is not far from the = > hiddenous that comes with any UNIX command.=20 Please, read the docs! Read the docs! :-) Jordan From owner-freebsd-hackers Fri Nov 15 01:13:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA28873 for hackers-outgoing; Fri, 15 Nov 1996 01:13:52 -0800 (PST) Received: (from hsu@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA28866; Fri, 15 Nov 1996 01:13:48 -0800 (PST) Date: Fri, 15 Nov 1996 01:13:48 -0800 (PST) From: Jeffrey Hsu Message-Id: <199611150913.BAA28866@freefall.freebsd.org> To: jb@cimlogic.com.au Subject: Re: Programming technique for non-forking servers? Cc: hackers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm working on a version that shares as much of libc as possible Here something you should look at: http://java.sun.com/people/pavani/techconf.html From owner-freebsd-hackers Fri Nov 15 02:57:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA04723 for hackers-outgoing; Fri, 15 Nov 1996 02:57:12 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA04677 for ; Fri, 15 Nov 1996 02:56:24 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.2/8.6.9) id VAA12061; Fri, 15 Nov 1996 21:55:03 +1100 (EST) Message-ID: Date: Fri, 15 Nov 1996 21:55:02 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: freebsd-hackers@freebsd.org Subject: User class/capabilities database X-Mailer: Mutt 0.50 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=H42GZzeTnltQoJLf Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --H42GZzeTnltQoJLf There is a reference in both man pages and source files to the user class being a pointer to a "termcap-like" capabilities and attributes database. I assume that support for this is not completed, or has ceased. Is this a FreeBSD-specific project, or is it tied to bsd 4.4lite? I could use this sorts of hook in an accounting system I'm developing, and was wondering to whom I might speak for mor information on the subject. Specifically, I need to know: 1) Is this a FreeBSD specific facility, or is it a bsd one (involving not only FreeBSD developers but the others)? 2) How much work has already been done already in terms of standardising user attributes (and what they are), 3) What existing code supports the facility, and how much freedom exists to expand the concept to cover user/session accounting in general. Regards, David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn --H42GZzeTnltQoJLf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBMotO5q0PLjnMZgUtAQGJewP/cDYmNaItiinaKTA3HpRnBPaXTcwYeR+B 5wcaQ/q8m0aF2tbkkX0RVkJ35zvKw4nmeZHyVc/0MpH0N2UwYDFI80VVOaS/pAuD oR9wYgHns/Js0TYIIm/oDzAkvTYSm2SZgEuAn15eVxYOl8HIYdoflM/X2pek9VH9 aALkbL1jooU= =/OHp -----END PGP SIGNATURE----- --H42GZzeTnltQoJLf-- From owner-freebsd-hackers Fri Nov 15 04:54:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA10766 for hackers-outgoing; Fri, 15 Nov 1996 04:54:55 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA10743; Fri, 15 Nov 1996 04:54:45 -0800 (PST) From: BRETT_GLASS@infoworld.com Received: from ccgate.infoworld.com (ccgate.infoworld.com [192.216.49.101]) by lserver.infoworld.com (8.7.5/8.7.3/GNAC-GW-1.2) with SMTP id EAA27840; Fri, 15 Nov 1996 04:49:28 -0800 (PST) Received: from ccMail by ccgate.infoworld.com (SMTPLINK V2.11) id AA848061945; Thu, 14 Nov 96 23:47:13 PST Date: Thu, 14 Nov 96 23:47:13 PST Message-Id: <9610158480.AA848061945@ccgate.infoworld.com> To: "Serge A. Babkin" , max@run.net Cc: alex@yahoo.com, hardware@freebsd.org, hackers@freebsd.org, max@rnd.runnet.ru Subject: Re: FreeBSD as Terminal Server Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Will the Digi driver work with the X/em? Last time I tried, it didn't. From owner-freebsd-hackers Fri Nov 15 05:43:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA13270 for hackers-outgoing; Fri, 15 Nov 1996 05:43:13 -0800 (PST) Received: from ioda.diatel.upm.es (ioda.diatel.upm.es [138.100.49.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA13244 for ; Fri, 15 Nov 1996 05:42:46 -0800 (PST) Received: by ioda.diatel.upm.es (SMI-8.6/SMI-SVR4) Fri, 15 Nov 1996 14:36:03 +0100 X400-Received: by /PRMD=iris/ADMD=400net/C=es/; Relayed; Fri, 15 Nov 1996 14:35:59 UTC+0100 Date: Fri, 15 Nov 1996 14:35:59 UTC+0100 X400-Originator: jmrueda@diatel.upm.es X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=iris/ADMD=400net/C=es/;961115143559] Content-Identifier: 1225 From: Javier Martin Rueda To: hackers@freebsd.org Message-ID: <1225*/S=jmrueda/OU=diatel/O=upm/PRMD=iris/ADMD=400net/C=es/@MHS> Subject: Announcing revision of beta driver for Intel EtherExpress pro/10 network card MIME-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a copy of an article I've sent to the usenet newsgroup, just in case there is people interested in this stuff who don't read the newsgroup: Hi, again! Since I released this driver a couple of weeks ago, I discovered two things that did not work quite ok, although they happened rarely (at least on my system). I finally got time to review them, and I think they are fixed now. Also, I've added support for FreeBSD 2.2, since I installed the 961014 SNAPSHOT. So, for anyone who wants to use an Intel EtherExpress Pro/10 network card under FreeBSD, feel free to grab the driver from: ftp://ftp.diatel.upm.es/incoming/jmrueda2/if_ex-961115.tar.gz Also, if it works, or if it does not, I would appreciate hearing from you. I saw several people downloaded the previous version, but I have no news from them, so I can only guess there must be no problems. Am I right? From owner-freebsd-hackers Fri Nov 15 06:02:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA14662 for hackers-outgoing; Fri, 15 Nov 1996 06:02:38 -0800 (PST) Received: from casparc.ppp.net (casparc.ppp.net [194.64.12.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA14633; Fri, 15 Nov 1996 06:02:25 -0800 (PST) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0vOOqI-000I9vC; Fri, 15 Nov 96 15:02 MET Received: by ernie.kts.org (Smail3.1.29.1 #5) id m0vOMhn-00001bC; Fri, 15 Nov 96 12:45 MET Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: userland PPP giving weird load numbers To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Fri, 15 Nov 1996 12:45:06 +0100 (MET) Cc: hm@kts.org, kelly@fsl.noaa.gov, mark@quickweb.com, hackers@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199611150756.SAA06861@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Nov 15, 96 06:26:01 pm Organization: Kitchen Table Systems Reply-To: hm@kts.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > I see this too all the time, from 2.0.5 all the way to 2.1.5. While > > > /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, > > > it'll drop. It's odd ... it's usually when ppp is idle that it hangs > > > around 1.0. > > > > I had this phenomenon too - but NOT with ppp. An isdn userland daemon i am > > working on showed this exact behaviour; when it was running, the system load > > was constantly 1.0 or very nearby. This all is under 2.1.5 (and 2.1 too). > > The process wasn't doing anything (or very little). > > But what _was_ it supposed to be doing? Ok, when this happened, the daemon was in a tight read() loop, where the read() timed out every second in the driver. Basically after implementing select() in the driver and using that with a one second timeout made the problem go away. In the whole application several one second timeouts exists at several drivers in the kernel - i'm quite shure there is a problem with something like several timeouts timing out simultaneously causing something. I just ran out of ideas where to search for and what to search for so i stopped looking for the real problem. But i'm able to reproduce it. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe (A)bort, (R)etry, (I)nstall BSD ? -------------------------------------------------------------------------------- kts.org will move and will be not available from November 20th for 10 days -------------------------------------------------------------------------------- From owner-freebsd-hackers Fri Nov 15 06:12:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA15205 for hackers-outgoing; Fri, 15 Nov 1996 06:12:05 -0800 (PST) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA15199 for ; Fri, 15 Nov 1996 06:12:03 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.7.6/8.7.3) with SMTP id JAA18678; Fri, 15 Nov 1996 09:11:59 -0500 (EST) Date: Fri, 15 Nov 1996 09:11:58 -0500 (EST) From: John Fieber To: Chuck Robey cc: FreeBSD-Hackers Subject: Re: Interesting URL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Nov 1996, Chuck Robey wrote: > I found an interesting URL full of some neat C++ graphics and network > code. I'm always complaining to friends that C++ doesn't have enough > public code out there, so this is a nice surprise I thought I'd share. Speaking of C++, there is a showstopper problem in 2.2-ALPHA with respect to STL. The fix appears to be simple and a patch has been submitted via send-pr. I have neither space nor time at this final hour to check it out personally or I would commit it myself, but it would *really* be a shame to ship 2.2 with an inoperable STL because of 3 missed files in the stdc++ library... -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================ From owner-freebsd-hackers Fri Nov 15 07:07:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA18894 for hackers-outgoing; Fri, 15 Nov 1996 07:07:02 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA18881 for ; Fri, 15 Nov 1996 07:06:44 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id QAA21287 for ; Fri, 15 Nov 1996 16:07:28 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id QAA04115 for freebsd-hackers@freefall.cdrom.com; Fri, 15 Nov 1996 16:16:02 +0100 Date: Fri, 15 Nov 1996 16:16:02 +0100 From: Christoph Kukulies Message-Id: <199611151516.QAA04115@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: multicast - does NT 4.0 have it? Does Linux have it? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As the subject asks: Do NT 4.0 and Linux 2.x have multicast routing in their kernel, i.e. can they act as a multicast router resp. run mrouted? --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri Nov 15 07:19:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA19863 for hackers-outgoing; Fri, 15 Nov 1996 07:19:58 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA19849 for ; Fri, 15 Nov 1996 07:19:53 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id HAA25295; Fri, 15 Nov 1996 07:18:11 -0800 (PST) From: "Rodney W. Grimes" Message-Id: <199611151518.HAA25295@GndRsh.aac.dev.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: <199611150436.WAA27108@brasil.moneng.mei.com> from Joe Greco at "Nov 14, 96 10:36:04 pm" To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 07:18:11 -0800 (PST) Cc: todd@gov.com, jkh@time.cdrom.com, hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I have clients with 2 and 3 of these cards in one system running 32 and > > 48 ports respectifully. It will work for you when you go above your > > current 4 port utilization. > > > > You are correct about the 8 port not having modem control, but I think > > the (not positive here) the 4 port does. If not I _know_ the 6 port > > board does. > > 4 port does not, 6 port does. > > Unless the product offering has changed lately. Thanks Joe, combining your statement with what another person said defanitly qualifies the fact that the BB1004 does not have modem support, and that the IOAT66 (6-port) does. Jordan, can you please list this in the serial board section of the release/whatever notes: Boca BB1004 4-Port serial card (Modems NOT supported) Boca IOAT66 6-Port serial card (Modems supported) Boca BB1008 8-Port serial card (Modems NOT supported) Boca BB2016 16-Port serial card (Modems supported) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-hackers Fri Nov 15 07:33:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA20867 for hackers-outgoing; Fri, 15 Nov 1996 07:33:21 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA20832 for ; Fri, 15 Nov 1996 07:33:11 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id CAA16817; Sat, 16 Nov 1996 02:29:19 +1100 Date: Sat, 16 Nov 1996 02:29:19 +1100 From: Bruce Evans Message-Id: <199611151529.CAA16817@godzilla.zeta.org.au> To: jgreco@brasil.moneng.mei.com, terry@lambert.org Subject: Re: Sockets question... Cc: hackers@FreeBSD.ORG, jdp@polstra.com, scrappy@ki.net Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >% man 2 read >(SunOS version) >... >READ(2V) SYSTEM CALLS READ(2V) > > system guarantees to read the number of bytes requested if > the descriptor references a normal file which has that many > bytes left before the EOF (end of file), but in no other > case. > >Key words, "but in no other case".. FreeBSD says the same thing in the same words except for English improvements. It lies :-). Short reads are possible even for normal files because the read might be into a partially invalid buffer. ffs_read() returns the blocks that are successfully read instead of unwinding the read and returning an EFAULT error. Example: --- #include #include #define SIZE 0x10000 main() { void *buf; int n; buf = malloc(0x10000); n = read(0, buf, 0x10000); printf("read %d\n", n); } --- This prints 65536 here. A watertight example can be probably be constructed using mmap(). Short writes to normal files are more likely. They occur when the disk fills up and for partially invalid buffers. There are more serious problems for the latter case. Bruce From owner-freebsd-hackers Fri Nov 15 07:43:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA21932 for hackers-outgoing; Fri, 15 Nov 1996 07:43:37 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA21919 for ; Fri, 15 Nov 1996 07:43:26 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id KAA01199; Fri, 15 Nov 1996 10:43:11 -0500 (EST) From: "John S. Dyson" Message-Id: <199611151543.KAA01199@dyson.iquest.net> Subject: Re: Q: system specific binaries To: rob@xs1.simplex.nl (Rob Simons) Date: Fri, 15 Nov 1996 10:43:10 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611151329.OAA00724@xs1.simplex.nl> from "Rob Simons" at Nov 15, 96 02:29:19 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Hi, > > Does anyone have any experience with customising FreeBSD so that only > binaries which are compiled on a system itself will actually run on > that system ? > So the local compiler has to give a key to each binary when it's > compiled, and when executed there'd be a check for that key. ? > That way only people who have access to the compiler may generate > binaries, and no 'foreign' binaries will be executed by the syetem. > > If this is too easy to break, is there perhaps a way to specify > from which directories binaries may be executed ? > Perhaps, formulate a system whereby the flags bits on a file are used in some way... Note that I am not talking about the "protection" bits, but there is another group of interesting things called flags bits that can be placed only under the control of the kernel. Just a thought. (Perhaps an "annoint" command???) John From owner-freebsd-hackers Fri Nov 15 08:03:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA23483 for hackers-outgoing; Fri, 15 Nov 1996 08:03:22 -0800 (PST) Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA23456; Fri, 15 Nov 1996 08:03:10 -0800 (PST) Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id JAA11157; Fri, 15 Nov 1996 09:22:57 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id QAA05023; Fri, 15 Nov 1996 16:01:11 GMT Message-Id: <199611151601.QAA05023@right.PCS> Date: Fri, 15 Nov 1996 10:01:10 -0600 From: jlemon@americantv.com (Jonathan Lemon) To: dyson@freebsd.org Cc: rob@xs1.simplex.nl (Rob Simons), hackers@freebsd.org Subject: Re: Q: system specific binaries References: <199611151329.OAA00724@xs1.simplex.nl> <199611151543.KAA01199@dyson.iquest.net> X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 In-Reply-To: <199611151543.KAA01199@dyson.iquest.net>; from John S. Dyson on Nov 15, 1996 10:43:10 -0500 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Does anyone have any experience with customising FreeBSD so that only > > binaries which are compiled on a system itself will actually run on > > that system ? > > So the local compiler has to give a key to each binary when it's > > compiled, and when executed there'd be a check for that key. ? > > That way only people who have access to the compiler may generate > > binaries, and no 'foreign' binaries will be executed by the syetem. > > > > If this is too easy to break, is there perhaps a way to specify > > from which directories binaries may be executed ? > > > Perhaps, formulate a system whereby the flags bits on a file are used > in some way... Note that I am not talking about the "protection" bits, > but there is another group of interesting things called flags bits that > can be placed only under the control of the kernel. Just a thought. > > (Perhaps an "annoint" command???) Now, why does this remind me of nettrek's "blessed" binaries? -- Jonathan From owner-freebsd-hackers Fri Nov 15 08:10:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24401 for hackers-outgoing; Fri, 15 Nov 1996 08:10:44 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA24387 for ; Fri, 15 Nov 1996 08:10:38 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id KAA00937; Fri, 15 Nov 1996 10:07:52 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA26098; Fri, 15 Nov 1996 10:07:49 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA20718; Fri, 15 Nov 1996 10:07:48 -0600 (CST) From: Karl Denninger Message-Id: <199611151607.KAA20718@Mercury.mcs.net> Subject: Re: Sockets question... To: jdp@polstra.com (John Polstra) Date: Fri, 15 Nov 1996 10:07:47 -0600 (CST) Cc: karl@Mcs.Net, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <199611150258.SAA12064@austin.polstra.com> from "John Polstra" at Nov 14, 96 06:58:11 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I have an application which sends a query to a back-end server -- and that > > server can return literally hundreds of KB of data in response. > > > > On very long responses, it just STOPS. > > > > The writing end thinks it wrote all of the data, netstat -an shows nothing > > in the socket buffers, the reader is waiting in read() for more data (it > > never saw the end marker, and in fact never saw more than half of the > > response!) > > If the socket is not in non-blocking mode, and you do a write(2) of N > bytes to it, and the write call returns anything other than -1 or N, > then that is a bug. The mode has not been modified; it should be in *blocking* mode. The write returns the correct number of bytes in each case. > If the sending socket returns N, but not all of the data gets to > the receiving socket, then that is either a bug or a network problem. Bingo. Send more than about 400KB in a stream transaction and you WILL see this. Its very repeatable. Bascially, what we do is this: The query goes to the server. It specifies the moral equivalent of a "select" call in ESQL (this is a home-brew database application). The server computes the response, and squirts out ~8500 records in response, each of which is ~140 bytes long. This is 8500 write(2) calls, one for each record. All return with no errors. About 2700 of the records get to the other end. The rest DISAPPEAR. They are NOT in the socket buffers (netstat -an shows *zero* bytes in the queue). I have *also* seen this if you zmodem a file to a terminal server port. You have a very good chance of long files not getting there intact. I thought this was a terminal server problem, but I'm no longer convinced -- this looks like a problem in the network code. Note that for the NETWORK case if we compile an on older machine running a -CURRENT kernel (built around the July timeframe, has gcc 2.6.3 on it) the application does NOT exhibit this problem. Compile on the -current machine, and it DOES. In both cases the application is linked -static. > >From write(2): > > When using non-blocking I/O on objects such as sockets that are subject > ^^^^^^^^^^^^ > to flow control, write() and writev() may write fewer bytes than request- > ed; the return value must be noted, and the remainder of the operation > should be retried when possible. > > OK, it doesn't come right out and say directly that it _won't_ do that > when using blocking I/O. But that is the implication. And it is the > historical behavior. And it is the behavior that probably 90% of > network applications are written to expect. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Fri Nov 15 08:14:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA24879 for hackers-outgoing; Fri, 15 Nov 1996 08:14:14 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA24864 for ; Fri, 15 Nov 1996 08:14:09 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id KAA01259; Fri, 15 Nov 1996 10:14:03 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA27329; Fri, 15 Nov 1996 10:13:59 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA21230; Fri, 15 Nov 1996 10:13:58 -0600 (CST) From: Karl Denninger Message-Id: <199611151613.KAA21230@Mercury.mcs.net> Subject: Re: Sockets question... To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 10:13:58 -0600 (CST) Cc: karl@mcs.net, jgreco@brasil.moneng.mei.com, scrappy@ki.net, jdp@polstra.com, hackers@FreeBSD.org In-Reply-To: <199611150430.WAA27067@brasil.moneng.mei.com> from "Joe Greco" at Nov 14, 96 10:30:39 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Are you checking the return value from write() to make sure it actually > > > thinks that N bytes were _written_? > > > > > > ... JG > > > > Uh, hang on a second... > > > > Are you saying that the behavior of a *TCP* connection is such that you > > would expect to see a write(2) call to the socket come back with a short > > count for any reason other than the remote having closed or some other > > kind of transport error (ie: host unreachable, etc)? > > Yes: a nonblocking socket write will most definitely display this > behaviour. Yes, but I did not set nonblocking mode on that socket. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Fri Nov 15 08:16:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA25086 for hackers-outgoing; Fri, 15 Nov 1996 08:16:07 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA25043 for ; Fri, 15 Nov 1996 08:16:01 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA27978; Fri, 15 Nov 1996 10:13:49 -0600 From: Joe Greco Message-Id: <199611151613.KAA27978@brasil.moneng.mei.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Fri, 15 Nov 1996 10:13:49 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, todd@gov.com, jkh@time.cdrom.com, hackers@FreeBSD.org In-Reply-To: <199611151518.HAA25295@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Nov 15, 96 07:18:11 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > 4 port does not, 6 port does. > > > > Unless the product offering has changed lately. > > Thanks Joe, combining your statement with what another person said > defanitly qualifies the fact that the BB1004 does not have modem > support, and that the IOAT66 (6-port) does. Actually cruising the Boca Web site is handy... ( :-) :-) ) http://www.bocaresearch.com/docs/prodlist.htm Product Code: BB1008 Eight-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and PC-MOS. Includes eight six-foot RJ-11 to DB-25 cables. Product Code: BB1004 Four-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and PC-MOS. Includes four six-foot RJ-11 to DB-25 cables. Product Code: IOAT66 I/O ports for ISA/EISA. Six high-speed RS-232 serial ports with 10-pin RJ-45 connectors and 16C550 buffered UARTs. Excellent product for bulletin board and fax server applications. Product Code: BB2016 16-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and PC-MOS. External concentrator supports up to 16 RJ-45 ports. Unfortunately their use of "RJ-45" is incorrect, it's actually a ten pin connector, allowing for full modem control. > Jordan, can you please list this in the serial board section of the > release/whatever notes: > > Boca BB1004 4-Port serial card (Modems NOT supported) > Boca IOAT66 6-Port serial card (Modems supported) > Boca BB1008 8-Port serial card (Modems NOT supported) > Boca BB2016 16-Port serial card (Modems supported) That is reasonable. I have been toying with the idea of picking up an IOAT66, but I've had bad experiences with a BB2016 (interrupt problems) and I am a bit hesitant to try a Boca serial board again. :-) I guess that's fine since I don't think I know anyone who sells them anyways. But they ARE very inexpensive! ... JG From owner-freebsd-hackers Fri Nov 15 08:19:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA25486 for hackers-outgoing; Fri, 15 Nov 1996 08:19:58 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA25479 for ; Fri, 15 Nov 1996 08:19:51 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA28016; Fri, 15 Nov 1996 10:17:30 -0600 From: Joe Greco Message-Id: <199611151617.KAA28016@brasil.moneng.mei.com> Subject: Re: Sockets question... To: karl@mcs.net (Karl Denninger) Date: Fri, 15 Nov 1996 10:17:30 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, karl@mcs.net, scrappy@ki.net, jdp@polstra.com, hackers@FreeBSD.org In-Reply-To: <199611151613.KAA21230@Mercury.mcs.net> from "Karl Denninger" at Nov 15, 96 10:13:58 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > Are you checking the return value from write() to make sure it actually > > > > thinks that N bytes were _written_? > > > > > > > > ... JG > > > > > > Uh, hang on a second... > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > would expect to see a write(2) call to the socket come back with a short > > > count for any reason other than the remote having closed or some other > > > kind of transport error (ie: host unreachable, etc)? > > > > Yes: a nonblocking socket write will most definitely display this > > behaviour. > > Yes, but I did not set nonblocking mode on that socket. Did you receive a signal? That is known to cause similar behaviour on SunOS... However, if you received a return value from write() equal to the number of bytes you supplied to write(), I would state that the problem is almost certainly elsewhere. ... JG From owner-freebsd-hackers Fri Nov 15 08:20:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA25684 for hackers-outgoing; Fri, 15 Nov 1996 08:20:52 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA25665 for ; Fri, 15 Nov 1996 08:20:38 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA00625; Fri, 15 Nov 1996 11:20:02 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Nov 1996 11:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id HAA08131; Fri, 15 Nov 1996 07:22:09 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id HAA21805; Fri, 15 Nov 1996 07:23:40 -0500 (EST) Date: Fri, 15 Nov 1996 07:23:40 -0500 (EST) From: Thomas David Rivers Message-Id: <199611151223.HAA21805@lakes.water.net> To: ponds!freefall.freebsd.org!dyson, ponds!freefall.freebsd.org!freebsd-hackers, ponds!lakes.water.net!rivers, ponds!lambert.org!terry Subject: Today's panic. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, I got a panic last night just after 1am - a different time; but it's a panic I've reported before. "panic: ifree: freeing free inode" in ffs_vfree(). Recall, this is a 2.1.5-STABLE kernel I grabbed on Oct. 17th (should I refresh this?), with Terry's suggested check in vfs_subr.c and David's check for v_usecount==0 in vnode_pager.c [Previous mail contains the context diff's for these two files.] Here's the traceback - but we've seen it before.... Again, let me say how much I appreciate everyone's effort on this! - Dave Rivers - [ponds.water.net]$ gdb -k kernel.9 vmcore.9 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 1e4000 current pcb at 1d5484 panic: ifree: freeing free inode #0 0xf0193d2b in boot () (kgdb) where #0 0xf0193d2b in boot () #1 0xf0112b83 in panic () #2 0xf0176f67 in ffs_vfree () #3 0xf017c1f2 in ufs_inactive () #4 0xf0128d65 in vrele () #5 0xf0128cab in vput () #6 0xf017f724 in ufs_remove () #7 0xf012ad6e in unlink () #8 0xf019c0a6 in syscall () #9 0xf019156b in Xsyscall () #10 0x2d9a in ?? () #11 0x2b2a in ?? () #12 0x2507 in ?? () #13 0x19b9 in ?? () #14 0x10d3 in ?? () (kgdb) [ponds.water.net]$ Script done on Fri Nov 15 07:15:14 1996 From owner-freebsd-hackers Fri Nov 15 08:22:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA25818 for hackers-outgoing; Fri, 15 Nov 1996 08:22:02 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA25794 for ; Fri, 15 Nov 1996 08:21:50 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15046(5)>; Fri, 15 Nov 1996 08:21:02 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Fri, 15 Nov 1996 08:20:54 -0800 To: Christoph Kukulies cc: freebsd-hackers@freefall.freebsd.org Subject: Re: multicast - does NT 4.0 have it? Does Linux have it? In-reply-to: Your message of "Fri, 15 Nov 96 07:16:02 PST." <199611151516.QAA04115@gilberto.physik.rwth-aachen.de> Date: Fri, 15 Nov 1996 08:20:44 PST From: Bill Fenner Message-Id: <96Nov15.082054pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199611151516.QAA04115@gilberto.physik.rwth-aachen.de> you write: >NT 4.0 No. Microsoft apparently has no plans for implementing this, and I have it on good authority that they use some FreeBSD machines as their internal multicast routers =) >Linux 2.x More recent versions, yes. I haven't tried them but have been assured that they work well. Bill From owner-freebsd-hackers Fri Nov 15 08:24:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA26177 for hackers-outgoing; Fri, 15 Nov 1996 08:24:47 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA26086 for ; Fri, 15 Nov 1996 08:24:14 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id KAA01578; Fri, 15 Nov 1996 10:24:08 -0600 (CST) Received: from Mercury.mcs.net (karl@Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA28966; Fri, 15 Nov 1996 10:24:06 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA21706; Fri, 15 Nov 1996 10:24:05 -0600 (CST) From: Karl Denninger Message-Id: <199611151624.KAA21706@Mercury.mcs.net> Subject: Re: Sockets question... To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 10:24:05 -0600 (CST) Cc: karl@mcs.net, jgreco@brasil.moneng.mei.com, scrappy@ki.net, jdp@polstra.com, hackers@FreeBSD.org In-Reply-To: <199611151617.KAA28016@brasil.moneng.mei.com> from "Joe Greco" at Nov 15, 96 10:17:30 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > > > Are you checking the return value from write() to make sure it actually > > > > > thinks that N bytes were _written_? > > > > > > > > > > ... JG > > > > > > > > Uh, hang on a second... > > > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > > would expect to see a write(2) call to the socket come back with a short > > > > count for any reason other than the remote having closed or some other > > > > kind of transport error (ie: host unreachable, etc)? > > > > > > Yes: a nonblocking socket write will most definitely display this > > > behaviour. > > > > Yes, but I did not set nonblocking mode on that socket. > > Did you receive a signal? That is known to cause similar behaviour on > SunOS... Can't. Any signal on that process is a SERIOUS error; its a DBMS! We have a generic "oh shit" trap for all signals set; it does not go off. > However, if you received a return value from write() equal to the number > of bytes you supplied to write(), I would state that the problem is > almost certainly elsewhere. > > ... JG Bingo. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Fri Nov 15 08:27:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA26441 for hackers-outgoing; Fri, 15 Nov 1996 08:27:20 -0800 (PST) Received: from Guard.PolyNet.Lviv.UA (Guard.PolyNet.Lviv.UA [194.44.138.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA26372 for ; Fri, 15 Nov 1996 08:26:40 -0800 (PST) Received: (from smap@localhost) by Guard.PolyNet.Lviv.UA (8.6.12/8.6.12) id SAA20545; Fri, 15 Nov 1996 18:26:09 +0200 Received: from netsurfer.lp.lviv.ua(192.168.0.3) by Guard.PolyNet.Lviv.UA via smap (V2.0beta) id xma020543; Fri, 15 Nov 96 18:26:08 +0200 Received: (from smap@localhost) by NetSurfer.lp.lviv.ua (8.6.12/8.6.12) id SAA23882; Fri, 15 Nov 1996 18:26:07 +0200 Received: from nova.lp.lviv.ua(192.168.0.6) by NetSurfer.lp.lviv.ua via smap (V2.0beta) id xma023879; Fri, 15 Nov 96 18:25:40 +0200 Message-ID: <328C9983.41C6@polynet.lviv.ua> Date: Fri, 15 Nov 1996 18:25:40 +0200 From: Slavik Terletsky Organization: State University "Lvivska Polytechnicka" X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.2 alpha) MIME-Version: 1.0 To: Andrew.Gordon@net-tel.co.uk CC: hackers@freefall.freebsd.org Subject: Re: Q: How to read hardware port ? *HELP* References: <"4893-961114184756-5C40*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andrew.Gordon@net-tel.co.uk wrote: > Does your port actually want byte-wide reads? There are other macros > in /usr/include/machine/cpufunc.h for 16-bit or 32-bit reads. no difference, the hardware just catches the trial of reading 0x443 port Say, if i am using port 0x443 and have no driver compiled for it - can i read this port at all? (without driver!) -- # Slavik Terletsky # University "Lvivska Poytechnica" # # Network Administrator # mailto:ts@polynet.lviv.ua # From owner-freebsd-hackers Fri Nov 15 08:31:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA26740 for hackers-outgoing; Fri, 15 Nov 1996 08:31:55 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA26726 for ; Fri, 15 Nov 1996 08:31:46 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.7.5/8.7.3) with ESMTP id KAA01032 for ; Fri, 15 Nov 1996 10:31:34 -0600 (CST) Received: from jaguar (jaguar.vale.com [204.117.217.146]) by crocodile.vale.com (8.7.5/8.7.3) with SMTP id KAA15426 for ; Fri, 15 Nov 1996 10:31:31 -0600 (CST) Message-ID: <328C9AE5.7339@vailsys.com> Date: Fri, 15 Nov 1996 10:31:33 -0600 From: Hal Snyder Reply-To: hal@vailsys.com Organization: Vail Systems, Inc. X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: hackers@FreeBSD.org Subject: Re: Programming technique for non-forking servers? References: <199611142228.PAA24870@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Not exactly on subject, but does anyone know of a C++ class library for network servers? Or is C++ still mainly for cooking application-level code? I've looked as socket++, but it seems to have been abandoned, not sure why. From owner-freebsd-hackers Fri Nov 15 08:42:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27925 for hackers-outgoing; Fri, 15 Nov 1996 08:42:14 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA27910 for ; Fri, 15 Nov 1996 08:41:58 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id DAA18603; Sat, 16 Nov 1996 03:36:41 +1100 Date: Sat, 16 Nov 1996 03:36:41 +1100 From: Bruce Evans Message-Id: <199611151636.DAA18603@godzilla.zeta.org.au> To: jdp@polstra.com, michaelh@cet.co.jp Subject: Re: Programming technique for non-forking servers? Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> mset and mclear would be implemented as lib functions because Intel does >> have an atomic test and set. > >Yes it does: the "xchg" instruction. Load 1 into a register, then "xchg" >the register with the memory location containing the lock. Look at the >new value of the register to find out whether the lock was already >locked. It also has many other instructions suitable for locking primitives: bt, btc, btr, bts (386 up) sal (386 up) (standard trick) cmpxchg (486 up) xadd (486 up) cmpxchg8b (Pentium (up?)) >It even works in a multiprocessor system. According to the >Intel book: > If a memory operand is involved, the LOCK# signal is asserted for the > duration of the exchange, regardless of the presence or absence of the > LOCK prefix or of the value of the IOPL. I think the other instructions work in multiprocessor systems if they have a `lock' prefix. The optional locking makes them more useful on uniprocessors (actually, except for `sal' they are usually too slow to be worth using except for locking. E.g., on Pentiums `bt' of a memory variable takes 26 times as long as a simple instruction). Bruce From owner-freebsd-hackers Fri Nov 15 08:59:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA29402 for hackers-outgoing; Fri, 15 Nov 1996 08:59:26 -0800 (PST) Received: from ioda.diatel.upm.es (ioda.diatel.upm.es [138.100.49.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA29134 for ; Fri, 15 Nov 1996 08:55:51 -0800 (PST) Received: by ioda.diatel.upm.es (SMI-8.6/SMI-SVR4) Fri, 15 Nov 1996 17:53:42 +0100 X400-Received: by /PRMD=iris/ADMD=400net/C=es/; Relayed; Fri, 15 Nov 1996 17:53:37 UTC+0100 Date: Fri, 15 Nov 1996 17:53:37 UTC+0100 X400-Originator: jmrueda@diatel.upm.es X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=iris/ADMD=400net/C=es/;961115175337] Content-Identifier: 1230 From: Javier Martin Rueda To: hackers@freebsd.org Message-ID: <1230*/S=jmrueda/OU=diatel/O=upm/PRMD=iris/ADMD=400net/C=es/@MHS> Subject: Contribution of Intel EtherExpress Pro/10 driver MIME-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've read the handbook on how to contribute new pieces of code to FreeBSD, and I've done what is says, namely: 1. The driver has a BSD-style copyright. 2. I've uploaded it to ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming, with filename if_ex-961115.tar.gz. 3. I'm sending a message to hackers@freebsd.org telling about this, so that someone can commit/review/whatever the driver. I hope it is not too late to include this driver in FreeBSD 2.2, assuming you find it appropriate enough. From owner-freebsd-hackers Fri Nov 15 09:04:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA29859 for hackers-outgoing; Fri, 15 Nov 1996 09:04:11 -0800 (PST) Received: from chai.plexuscom.com (chai.plexuscom.com [207.87.46.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA29828 for ; Fri, 15 Nov 1996 09:03:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by chai.plexuscom.com (8.7.6/8.6.12) with SMTP id MAA02558; Fri, 15 Nov 1996 12:04:13 -0500 (EST) Message-Id: <199611151704.MAA02558@chai.plexuscom.com> X-Authentication-Warning: chai.plexuscom.com: Host localhost [127.0.0.1] didn't use HELO protocol To: hal@vailsys.com Cc: hackers@FreeBSD.ORG Subject: Re: Programming technique for non-forking servers? In-reply-to: Your message of "Fri, 15 Nov 1996 10:31:33 CST." <328C9AE5.7339@vailsys.com> Date: Fri, 15 Nov 1996 12:04:13 -0500 From: Bakul Shah Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Not exactly on subject, but does anyone know of a C++ class library for > network servers? Or is C++ still mainly for cooking application-level > code? C++ is eminently useful for doing network servers. See http://siesta.cs.wustl.edu/~schmidt/ACE.html for one example of it. I cooked up something much more light-weight at a previous job but I can't give it away. While I am at this, I will also recommend Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Hard-cover, 416 pages, Addison-Wesley 1995, ISBN 0-201-63361-2. If you can get past all the O-O buzzwords this is a very useful book on how to structure large software projects, it has examples of patterns (or idioms) useful in many different contexts etc. From owner-freebsd-hackers Fri Nov 15 09:21:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00941 for hackers-outgoing; Fri, 15 Nov 1996 09:21:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA00935 for ; Fri, 15 Nov 1996 09:21:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA26239; Fri, 15 Nov 1996 10:06:55 -0700 From: Terry Lambert Message-Id: <199611151706.KAA26239@phaeton.artisoft.com> Subject: Re: Sockets question... To: jdp@polstra.com (John Polstra) Date: Fri, 15 Nov 1996 10:06:54 -0700 (MST) Cc: terry@lambert.org, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG In-Reply-To: <199611150127.RAA11283@austin.polstra.com> from "John Polstra" at Nov 14, 96 05:27:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If you don't use non-blocking I/O, the read will block until the > > buffer is full. Use blocking I/O, and you won't have the problem > > with the reader returning before it should (or shouldn't). > > This is most certainly not guaranteed by the documentation. From > read(2): > > The system guarantees to read the number of bytes requested > if the descriptor references a normal file that has that many > bytes left before the end-of-file, but in no other case. Then what use is the thing? How do I read into a structure on a machine that demands aligned data access? Specifically, if it's allowed to read 3 bytes of an integer value, and you are suppossed to reissue a read for the third byte (this I find hard to believe!), how do you access this data area atomically? No, I understand that the implementation *allows* this type of behavior for non-blocking I/O, and device I/O on non-blocking devices (like the bit-set mouse device), and for tty devices where the read count exceeds the vmin for more than vtime, but nothing would work at all if you couldn't issue a read for n bytes that didn't complete until you *got* n bytes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 09:22:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00977 for hackers-outgoing; Fri, 15 Nov 1996 09:22:11 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA00967 for ; Fri, 15 Nov 1996 09:21:58 -0800 (PST) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id JAA02194 for ; Fri, 15 Nov 1996 09:21:56 -0800 (PST) Received: from crocodile.vale.com (crocodile [204.117.217.147]) by vdp01.vailsystems.com (8.7.5/8.7.3) with ESMTP id LAA01176; Fri, 15 Nov 1996 11:20:10 -0600 (CST) Received: from jaguar (jaguar.vale.com [204.117.217.146]) by crocodile.vale.com (8.7.5/8.7.3) with SMTP id LAA15665; Fri, 15 Nov 1996 11:20:08 -0600 (CST) Message-ID: <328CA64A.7A2B@vailsys.com> Date: Fri, 15 Nov 1996 11:20:10 -0600 From: Hal Snyder Reply-To: hal@vailsys.com Organization: Vail Systems, Inc. X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Bakul Shah CC: hackers@FreeBSD.ORG Subject: Re: Programming technique for non-forking servers? References: <199611151704.MAA02558@chai.plexuscom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bakul Shah wrote: > C++ is eminently useful for doing network servers. See > http://siesta.cs.wustl.edu/~schmidt/ACE.html > for one example of it. Thanks, looked at ACE, backed off when I saw it required - I think I remember this right - several hundred megabytes of drive space to build the library. I didn't want to write a server that needed more space than all the rest of the OS put together. I'd be interested to know if ACE is usable in the Real World - including FreeBSD users. From owner-freebsd-hackers Fri Nov 15 09:30:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA01355 for hackers-outgoing; Fri, 15 Nov 1996 09:30:38 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA01340 for ; Fri, 15 Nov 1996 09:30:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA26280; Fri, 15 Nov 1996 10:17:03 -0700 From: Terry Lambert Message-Id: <199611151717.KAA26280@phaeton.artisoft.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 10:17:03 -0700 (MST) Cc: scrappy@ki.net, jdp@polstra.com, hackers@FreeBSD.org In-Reply-To: <96Nov14.180824pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 14, 96 06:08:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > TCP is not a record-oriented protocol, and will buffer up (or re-packetize > however it wants) any data that you give it. Therefore, you have to be > prepared to read whatever size it wants to give you, and your application > has to be able to put it back together into what it wants. Your data will > all get there, eventually. Then why do we have all of the silly frag reconstruction code in the packet receive path, if having the code makes no difference? > my part anyway. What you need to do is write all your data to the network, > and not count on it arriving in the same sized chunks as you wrote it. > But it will all arrive. ?!? This is (supposedly) what happens *for you* during packet reassembly on the receiving end. Packets, as they arrive, are reassembled, in order, into the user buffer, so the user buffer on the receiver ends up looking thesame as the user buffer on the sender. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 09:34:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA01697 for hackers-outgoing; Fri, 15 Nov 1996 09:34:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA01686 for ; Fri, 15 Nov 1996 09:34:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA26294; Fri, 15 Nov 1996 10:19:50 -0700 From: Terry Lambert Message-Id: <199611151719.KAA26294@phaeton.artisoft.com> Subject: Re: Sockets question... To: jdp@polstra.com (John Polstra) Date: Fri, 15 Nov 1996 10:19:50 -0700 (MST) Cc: karl@Mcs.Net, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <199611150258.SAA12064@austin.polstra.com> from "John Polstra" at Nov 14, 96 06:58:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If the socket is not in non-blocking mode, and you do a write(2) of N > bytes to it, and the write call returns anything other than -1 or N, > then that is a bug. You mean "blocking" mode, right? > If the sending socket returns N, but not all of the data gets to > the receiving socket, then that is either a bug or a network problem. Yes. This is an acceptable event. However, the receiver should then not have "all frags received" and therfore a *blocking* read on the receiving socket should hang. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 09:41:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA02281 for hackers-outgoing; Fri, 15 Nov 1996 09:41:45 -0800 (PST) Received: from relay.ieunet.ie (relay.ieunet.ie [192.111.39.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA02268 for ; Fri, 15 Nov 1996 09:41:28 -0800 (PST) Received: from nixdub.sse.ie by relay.ieunet.ie with SMTP id aa24445; 15 Nov 96 17:39 +0000 Received: from bold (bold.sse.ie [193.120.33.33]) by nixdub.sse.ie (8.6.4/8.6.4) with SMTP id RAA25738; Fri, 15 Nov 1996 17:38:55 GMT Message-ID: <328CABA7.74E0@brd.ie> Date: Fri, 15 Nov 1996 17:43:03 +0000 From: "Frank O'Dwyer" X-Mailer: Mozilla 2.01 (WinNT; I) MIME-Version: 1.0 To: hal@vailsys.com CC: hackers@freebsd.org Subject: Re: Programming technique for non-forking servers? References: <199611142228.PAA24870@phaeton.artisoft.com> <328C9AE5.7339@vailsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hal Snyder wrote: > Not exactly on subject, but does anyone know of a C++ class library for > network servers? Or is C++ still mainly for cooking application-level > code? > > I've looked as socket++, but it seems to have been abandoned, not sure > why. I'm writing one with an emphasis on security called 'FFC' ('firewall foundation classes'). It's still prealpha (i.e. very incomplete and somewhat buggy) but you can find out about it (and download a prerelease) at http://www.iol.ie/~fod/ffc.html. It requires FreeBSD 2.1R with gcc 2.7.2.1, or WIN32 with MSVC 4.2. I expect to make a more interesting release in about a month or so, so you may want to hold off til then. Otherwise, a pretty good and more mature class library is 'ACE'. I don't have the reference handy but it's linked off the URL above. It is also cross-platform but adds classes for concurrency, threads, semaphores and so on. I haven't managed to port it to FreeBSD yet though. If you do I'd appreciate a copy of the patches. Basically, my idea with FFC is to hopefully be simpler than ACE (i.e. be suitable for firewalls), to add more support for crypto, and to review it for security holes once the design stabilises. I also hope to leverage kernel features in FreeBSD (ip filtering, etc. + ipsec when and if). Anyone is welcome to contribute or to comment on what's there, of course... FFC is/will be free software (as is ACE, AFAIK). Cheers, Frank O'Dwyer. From owner-freebsd-hackers Fri Nov 15 09:56:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA03369 for hackers-outgoing; Fri, 15 Nov 1996 09:56:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA03258 for ; Fri, 15 Nov 1996 09:56:20 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id EAA20990; Sat, 16 Nov 1996 04:54:32 +1100 Date: Sat, 16 Nov 1996 04:54:32 +1100 From: Bruce Evans Message-Id: <199611151754.EAA20990@godzilla.zeta.org.au> To: bde@zeta.org.au, jgreco@brasil.moneng.mei.com, terry@lambert.org Subject: Re: Sockets question... Cc: hackers@FreeBSD.ORG, jdp@polstra.com, scrappy@ki.net Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: >... Short reads are possible even for >normal files because the read might be into a partially invalid >buffer. ffs_read() returns the blocks that are successfully >read instead of unwinding the read and returning an EFAULT error. >Example: > >--- >#include >#include > >#define SIZE 0x10000 > >main() >{ > void *buf; > int n; > > > buf = malloc(0x10000); > n = read(0, buf, 0x10000); > printf("read %d\n", n); >} >--- > >This prints 65536 here. A watertight example can be probably be >constructed using mmap(). Oops, pass the pointy hat. This is a non-example since i forgot to increase the read size and forget to tell you to invoke it with /kernel as stdin. Increasing the read size to 0x20000 gives more interesting behaviour: on system 1 with 32MB RAM: the kernel panics with a double fault on system 2 with 8MB RAM: read returns -1. I have seen a similar panic for writing from a bad address like 0xfffffc00 but I couldn't duplicate the problem and I thought it had something to do with a fixed vm bug. Bruce From owner-freebsd-hackers Fri Nov 15 10:04:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04082 for hackers-outgoing; Fri, 15 Nov 1996 10:04:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA04074 for ; Fri, 15 Nov 1996 10:04:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA26388; Fri, 15 Nov 1996 10:48:35 -0700 From: Terry Lambert Message-Id: <199611151748.KAA26388@phaeton.artisoft.com> Subject: Re: Sockets question... To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 10:48:35 -0700 (MST) Cc: terry@lambert.org, jdp@polstra.com, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.org In-Reply-To: <199611150414.WAA26986@brasil.moneng.mei.com> from "Joe Greco" at Nov 14, 96 10:14:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Well now, wait a minute. As long as you haven't set the socket for > > > non-blocking I/O, the write will always block until it's written the > > > full N bytes that you asked for. In other words, the write will always > > > return either -1 or N. Only if it's set up for non-blocking I/O can it > > > return a short count. Writes are different from reads in this respect. > > > > The problem that is supposedly being addressed by looking at the bytes > > written is knowing that the data will be available as a unit to the > > reader. > > Wrong, Terry. > > The problem that is supposedly being addressed (and as the person who > wrote the advice, I am telling you indisputably that this is what is > being addressed) is that sometimes, people will forget that they are > writing to a particular type of socket (such as {,non}blocking) and > will inadvertently forget to check to see if all the data was written. Non-blocking sockets for reliable stream protocols like TCP/IP are a stupid idea. If I wanted datagrams, I would pick a protocol like UDP. > In the case of a nonblocking socket, the test is mandatory. What is this, a bizzarre method of dealing with source quench on TCP? What is the point of a non-blocking write if this is what happens? I assume the only case where this is possible is where local buffer space is not available to queue all the write data? I assume you would use this for "frigging huge writes which you expect to exceed the available buffer space"? This is potentially useful for lazy programmers, and for directed finite state automatons. On the other hand, I would expect that the initial write failure would set the size of the expected delivery on the reliable stream, and that subsequent writes would then pe packed off as "additional frags" up to the satisfaction of the original (failed) write request. Otherwise, you have just un-formatted your transport contents. 8-(. > In the case of an indeterminate socket, the test is also mandatory - > precisely BECAUSE you don't know. Indeterminate sockets are evil. They are on the order of not knowing your lock state when entering into a function that's going to need the lock held. > > If you don't use non-blocking I/O, the read will block until the buffer > > is full. Use blocking I/O, and you won't have the problem with the > > reader returning before it should (or shouldn't). Otherwise the RPC > > interfaces wouldn't work at all. > > I am not too sure that statement is true... but then I am a paranoid > programmer, so I always define an xread() function guaranteed to do what > I mean. Still, that bothers me... It bothers me too... I am used to formatting my IPC data streams. I either use fixed length data units so that the receiver can post a fixed size read, or I use a fix length data unit, and guarantee write ordering by maintaining state. I do this in order to send a fixed length header to indicate that I'm writing a variable length packet, so the receiver can then issue a blocking read for the right size. > > Instead of making a non-blocking read for which "it's OK if no data > > is available", use select() and only call a blocking read if the select > > is true. > > And I think this is what I was looking for... > > If you have a blocking read, select() returns true on a FD because one > byte is available, and you try a read(1000), will it block? Yes. It will block pending all 1000 bytes being available. > I am reasonably certain that it will not - it will return the one byte. > > Ahhh. Yes. > > % man 2 read > (SunOS version) > > Upon successful completion, read() and readv() return the > number of bytes actually read and placed in the buffer. The > > Sun Release 4.1 Last change: 21 January 1990 1 > > READ(2V) SYSTEM CALLS READ(2V) > > system guarantees to read the number of bytes requested if > the descriptor references a normal file which has that many > bytes left before the EOF (end of file), but in no other > case. > > Key words, "but in no other case".. That isn't the same as "and guarantees to return random numbers in all other cases". 8-). The question, I suppose, is whether pending packet data less than the packet length from the transmitter is fragged. To answer that, I refer you to socket(2). Specifically, you are describing the difference between SOCK_STREAM and SOCK_SEQPACKET... the short reads you are defining are for the SOCK_SEQPACKET case. From the man page: The communications protocols used to implement a SOCK_STREAM insure that data is not lost or duplicated. If a piece of data for which the peer protocol has buffer space cannot be successfully transmitted within a reasonable length of time, then the connection is considered broken and calls will indicate an error with -1 returns and with ETIMEDOUT as the specific code in the global variable errno. The protocols optionally keep sockets ``warm'' by forcing transmissions roughly every minute in the ab- sence of other activity. An error is then indicated if no response can be elicited on an otherwise idle connection for a extended period (e.g. 5 minutes). A SIGPIPE signal is raised if a process sends on a broken stream; this causes naive processes, which do not handle the signal, to exit. If you want to get technical, according to this description, if you are using a SOCK_STREAM, then a read on a blocking socket will act like a recv(2) or recvfrom(2) with flags MSG_WAITALL by default. If you want the read to not hang pending arrival of all packets in the run resulting from a single write... Maybe you should be using send/recv instead of write/read? Maybe you should be using SOCK_SEQPACKET instead of SOCK_STREAM? IMO, it is not useful to use read(2) in conjunction with non-blocking sockets. I suggest you create a socket without setting any non-default options, and then fcntl it with F_GETFL and look for the defaults for O_NONBLOCK and O_ASYNC. There is no substitute for asking the machine. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 10:10:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04530 for hackers-outgoing; Fri, 15 Nov 1996 10:10:16 -0800 (PST) Received: from VMS1.TAMU.EDU (VMS1.TAMU.EDU [128.194.103.13]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA04470 for ; Fri, 15 Nov 1996 10:09:53 -0800 (PST) Received: from VMS1.TAMU.EDU by VMS1.TAMU.EDU with SMTP; Fri, 15 Nov 1996 12:09:14 -0600 (CST) Date: Fri, 15 Nov 1996 12:09:11 +0000 From: "RIVERA, ELADIO " X-Sender: E0R8047@VMS1.TAMU.EDU To: hackers@freefall.freebsd.org cc: freebsd-hackers-digest@FreeBSD.ORG Subject: Re: hackers-digest V1 #1641 In-Reply-To: <199611151659.IAA29419@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 15 Nov 1996 owner-hackers-digest@freefall.freebsd.org wrote: Does anyone have any hints about Unix I would really appreciate the help. Thanks goat boy > > hackers-digest Friday, 15 November 1996 Volume 01 : Number 1641 > > In this issue: > Re: userland PPP giving weird load numbers > Re: Interesting URL > multicast - does NT 4.0 have it? Does Linux have it? > Re: FreeBSD 2.2-ALPHA is now available. > Re: Sockets question... > Re: Q: system specific binaries > Re: Q: system specific binaries > Re: Sockets question... > Re: Sockets question... > Re: FreeBSD 2.2-ALPHA is now available. > Re: Sockets question... > Today's panic. > Re: multicast - does NT 4.0 have it? Does Linux have it? > Re: Sockets question... > Re: Q: How to read hardware port ? *HELP* > Re: Programming technique for non-forking servers? > Re: Programming technique for non-forking servers? > Contribution of Intel EtherExpress Pro/10 driver > > ---------------------------------------------------------------------- > > From: hm@kts.org (Hellmuth Michaelis) > Date: Fri, 15 Nov 1996 12:45:06 +0100 (MET) > Subject: Re: userland PPP giving weird load numbers > > > > > I see this too all the time, from 2.0.5 all the way to 2.1.5. While > > > > /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, > > > > it'll drop. It's odd ... it's usually when ppp is idle that it hangs > > > > around 1.0. > > > > > > I had this phenomenon too - but NOT with ppp. An isdn userland daemon i am > > > working on showed this exact behaviour; when it was running, the system load > > > was constantly 1.0 or very nearby. This all is under 2.1.5 (and 2.1 too). > > > The process wasn't doing anything (or very little). > > > > But what _was_ it supposed to be doing? > > Ok, when this happened, the daemon was in a tight read() loop, where the > read() timed out every second in the driver. Basically after implementing > select() in the driver and using that with a one second timeout made the > problem go away. > > In the whole application several one second timeouts exists at several > drivers in the kernel - i'm quite shure there is a problem with something > like several timeouts timing out simultaneously causing something. > > I just ran out of ideas where to search for and what to search for so i > stopped looking for the real problem. But i'm able to reproduce it. > > hellmuth > - -- > Hellmuth Michaelis hm@kts.org Hamburg, Europe > (A)bort, (R)etry, (I)nstall BSD ? > - -------------------------------------------------------------------------------- > kts.org will move and will be not available from November 20th for 10 days > - -------------------------------------------------------------------------------- > > ------------------------------ > > From: John Fieber > Date: Fri, 15 Nov 1996 09:11:58 -0500 (EST) > Subject: Re: Interesting URL > > On Thu, 14 Nov 1996, Chuck Robey wrote: > > > I found an interesting URL full of some neat C++ graphics and network > > code. I'm always complaining to friends that C++ doesn't have enough > > public code out there, so this is a nice surprise I thought I'd share. > > Speaking of C++, there is a showstopper problem in 2.2-ALPHA with > respect to STL. The fix appears to be simple and a patch has > been submitted via send-pr. I have neither space nor time at > this final hour to check it out personally or I would commit it > myself, but it would *really* be a shame to ship 2.2 with an > inoperable STL because of 3 missed files in the stdc++ library... > > - -john > > == jfieber@indiana.edu =========================================== > == http://fallout.campusview.indiana.edu/~jfieber ================ > > > ------------------------------ > > From: Christoph Kukulies > Date: Fri, 15 Nov 1996 16:16:02 +0100 > Subject: multicast - does NT 4.0 have it? Does Linux have it? > > As the subject asks: Do NT 4.0 and Linux 2.x have multicast > routing in their kernel, i.e. can they act as a multicast router > resp. run mrouted? > > - --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > ------------------------------ > > From: "Rodney W. Grimes" > Date: Fri, 15 Nov 1996 07:18:11 -0800 (PST) > Subject: Re: FreeBSD 2.2-ALPHA is now available. > > > > I have clients with 2 and 3 of these cards in one system running 32 and > > > 48 ports respectifully. It will work for you when you go above your > > > current 4 port utilization. > > > > > > You are correct about the 8 port not having modem control, but I think > > > the (not positive here) the 4 port does. If not I _know_ the 6 port > > > board does. > > > > 4 port does not, 6 port does. > > > > Unless the product offering has changed lately. > > Thanks Joe, combining your statement with what another person said > defanitly qualifies the fact that the BB1004 does not have modem > support, and that the IOAT66 (6-port) does. > > Jordan, can you please list this in the serial board section of the > release/whatever notes: > > Boca BB1004 4-Port serial card (Modems NOT supported) > Boca IOAT66 6-Port serial card (Modems supported) > Boca BB1008 8-Port serial card (Modems NOT supported) > Boca BB2016 16-Port serial card (Modems supported) > > - -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation, Inc. Reliable computers for FreeBSD > > ------------------------------ > > From: Bruce Evans > Date: Sat, 16 Nov 1996 02:29:19 +1100 > Subject: Re: Sockets question... > > >% man 2 read > >(SunOS version) > >... > >READ(2V) SYSTEM CALLS READ(2V) > > > > system guarantees to read the number of bytes requested if > > the descriptor references a normal file which has that many > > bytes left before the EOF (end of file), but in no other > > case. > > > >Key words, "but in no other case".. > > FreeBSD says the same thing in the same words except for English > improvements. It lies :-). Short reads are possible even for > normal files because the read might be into a partially invalid > buffer. ffs_read() returns the blocks that are successfully > read instead of unwinding the read and returning an EFAULT error. > Example: > > - --- > #include > #include > > #define SIZE 0x10000 > > main() > { > void *buf; > int n; > > > buf = malloc(0x10000); > n = read(0, buf, 0x10000); > printf("read %d\n", n); > } > - --- > > This prints 65536 here. A watertight example can be probably be > constructed using mmap(). > > Short writes to normal files are more likely. They occur when the > disk fills up and for partially invalid buffers. There are more > serious problems for the latter case. > > Bruce > > ------------------------------ > > From: "John S. Dyson" > Date: Fri, 15 Nov 1996 10:43:10 -0500 (EST) > Subject: Re: Q: system specific binaries > > > > > > > Hi, > > > > Does anyone have any experience with customising FreeBSD so that only > > binaries which are compiled on a system itself will actually run on > > that system ? > > So the local compiler has to give a key to each binary when it's > > compiled, and when executed there'd be a check for that key. ? > > That way only people who have access to the compiler may generate > > binaries, and no 'foreign' binaries will be executed by the syetem. > > > > If this is too easy to break, is there perhaps a way to specify > > from which directories binaries may be executed ? > > > Perhaps, formulate a system whereby the flags bits on a file are used > in some way... Note that I am not talking about the "protection" bits, > but there is another group of interesting things called flags bits that > can be placed only under the control of the kernel. Just a thought. > > (Perhaps an "annoint" command???) > John > > ------------------------------ > > From: jlemon@americantv.com (Jonathan Lemon) > Date: Fri, 15 Nov 1996 10:01:10 -0600 > Subject: Re: Q: system specific binaries > > > > Does anyone have any experience with customising FreeBSD so that only > > > binaries which are compiled on a system itself will actually run on > > > that system ? > > > So the local compiler has to give a key to each binary when it's > > > compiled, and when executed there'd be a check for that key. ? > > > That way only people who have access to the compiler may generate > > > binaries, and no 'foreign' binaries will be executed by the syetem. > > > > > > If this is too easy to break, is there perhaps a way to specify > > > from which directories binaries may be executed ? > > > > > Perhaps, formulate a system whereby the flags bits on a file are used > > in some way... Note that I am not talking about the "protection" bits, > > but there is another group of interesting things called flags bits that > > can be placed only under the control of the kernel. Just a thought. > > > > (Perhaps an "annoint" command???) > > Now, why does this remind me of nettrek's "blessed" binaries? > - -- > Jonathan > > ------------------------------ > > From: Karl Denninger > Date: Fri, 15 Nov 1996 10:07:47 -0600 (CST) > Subject: Re: Sockets question... > > > > I have an application which sends a query to a back-end server -- and that > > > server can return literally hundreds of KB of data in response. > > > > > > On very long responses, it just STOPS. > > > > > > The writing end thinks it wrote all of the data, netstat -an shows nothing > > > in the socket buffers, the reader is waiting in read() for more data (it > > > never saw the end marker, and in fact never saw more than half of the > > > response!) > > > > If the socket is not in non-blocking mode, and you do a write(2) of N > > bytes to it, and the write call returns anything other than -1 or N, > > then that is a bug. > > The mode has not been modified; it should be in *blocking* mode. The write > returns the correct number of bytes in each case. > > > If the sending socket returns N, but not all of the data gets to > > the receiving socket, then that is either a bug or a network problem. > > Bingo. Send more than about 400KB in a stream transaction and you WILL see > this. Its very repeatable. > > Bascially, what we do is this: > > The query goes to the server. It specifies the moral equivalent of a > "select" call in ESQL (this is a home-brew database application). > > The server computes the response, and squirts out ~8500 records in response, > each of which is ~140 bytes long. This is 8500 write(2) calls, one for each > record. All return with no errors. > > About 2700 of the records get to the other end. The rest DISAPPEAR. They > are NOT in the socket buffers (netstat -an shows *zero* bytes in the > queue). > > I have *also* seen this if you zmodem a file to a terminal server port. You > have a very good chance of long files not getting there intact. I thought > this was a terminal server problem, but I'm no longer convinced -- this > looks like a problem in the network code. > > Note that for the NETWORK case if we compile an on older machine running a > - -CURRENT kernel (built around the July timeframe, has gcc 2.6.3 on it) the > application does NOT exhibit this problem. > > Compile on the -current machine, and it DOES. > > In both cases the application is linked -static. > > > >From write(2): > > > > When using non-blocking I/O on objects such as sockets that are subject > > ^^^^^^^^^^^^ > > to flow control, write() and writev() may write fewer bytes than request- > > ed; the return value must be noted, and the remainder of the operation > > should be retried when possible. > > > > OK, it doesn't come right out and say directly that it _won't_ do that > > when using blocking I/O. But that is the implication. And it is the > > historical behavior. And it is the behavior that probably 90% of > > network applications are written to expect. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Karl Denninger > Date: Fri, 15 Nov 1996 10:13:58 -0600 (CST) > Subject: Re: Sockets question... > > > > > Are you checking the return value from write() to make sure it actually > > > > thinks that N bytes were _written_? > > > > > > > > ... JG > > > > > > Uh, hang on a second... > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > would expect to see a write(2) call to the socket come back with a short > > > count for any reason other than the remote having closed or some other > > > kind of transport error (ie: host unreachable, etc)? > > > > Yes: a nonblocking socket write will most definitely display this > > behaviour. > > Yes, but I did not set nonblocking mode on that socket. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Joe Greco > Date: Fri, 15 Nov 1996 10:13:49 -0600 (CST) > Subject: Re: FreeBSD 2.2-ALPHA is now available. > > > > 4 port does not, 6 port does. > > > > > > Unless the product offering has changed lately. > > > > Thanks Joe, combining your statement with what another person said > > defanitly qualifies the fact that the BB1004 does not have modem > > support, and that the IOAT66 (6-port) does. > > Actually cruising the Boca Web site is handy... ( :-) :-) ) > > http://www.bocaresearch.com/docs/prodlist.htm > > Product Code: BB1008 > Eight-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix > and PC-MOS. Includes eight six-foot RJ-11 to DB-25 cables. > > Product Code: BB1004 > Four-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and > PC-MOS. Includes four six-foot RJ-11 to DB-25 cables. > > Product Code: IOAT66 > I/O ports for ISA/EISA. Six high-speed RS-232 serial ports with 10-pin RJ-45 > connectors and 16C550 buffered UARTs. Excellent product for bulletin board > and fax server applications. > > Product Code: BB2016 > 16-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and > PC-MOS. External concentrator supports up to 16 RJ-45 ports. > > Unfortunately their use of "RJ-45" is incorrect, it's actually a ten pin > connector, allowing for full modem control. > > > Jordan, can you please list this in the serial board section of the > > release/whatever notes: > > > > Boca BB1004 4-Port serial card (Modems NOT supported) > > Boca IOAT66 6-Port serial card (Modems supported) > > Boca BB1008 8-Port serial card (Modems NOT supported) > > Boca BB2016 16-Port serial card (Modems supported) > > That is reasonable. > > I have been toying with the idea of picking up an IOAT66, but I've had > bad experiences with a BB2016 (interrupt problems) and I am a bit > hesitant to try a Boca serial board again. :-) I guess that's fine > since I don't think I know anyone who sells them anyways. But they > ARE very inexpensive! > > ... JG > > ------------------------------ > > From: Joe Greco > Date: Fri, 15 Nov 1996 10:17:30 -0600 (CST) > Subject: Re: Sockets question... > > > > > > Are you checking the return value from write() to make sure it actually > > > > > thinks that N bytes were _written_? > > > > > > > > > > ... JG > > > > > > > > Uh, hang on a second... > > > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > > would expect to see a write(2) call to the socket come back with a short > > > > count for any reason other than the remote having closed or some other > > > > kind of transport error (ie: host unreachable, etc)? > > > > > > Yes: a nonblocking socket write will most definitely display this > > > behaviour. > > > > Yes, but I did not set nonblocking mode on that socket. > > Did you receive a signal? That is known to cause similar behaviour on > SunOS... > > However, if you received a return value from write() equal to the number > of bytes you supplied to write(), I would state that the problem is > almost certainly elsewhere. > > ... JG > > ------------------------------ > > From: Thomas David Rivers > Date: Fri, 15 Nov 1996 07:23:40 -0500 (EST) > Subject: Today's panic. > > Well, I got a panic last night just after 1am - a different > time; but it's a panic I've reported before. > > "panic: ifree: freeing free inode" > > in ffs_vfree(). > > Recall, this is a 2.1.5-STABLE kernel I grabbed on Oct. 17th > (should I refresh this?), with Terry's suggested check in > vfs_subr.c and David's check for v_usecount==0 in vnode_pager.c > [Previous mail contains the context diff's for these two files.] > > Here's the traceback - but we've seen it before.... > > Again, let me say how much I appreciate everyone's effort on this! > > - Dave Rivers - > > > > [ponds.water.net]$ gdb -k kernel.9 vmcore.9 > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.13 (i386-unknown-freebsd), > Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... > IdlePTD 1e4000 > current pcb at 1d5484 > panic: ifree: freeing free inode > #0 0xf0193d2b in boot () > (kgdb) where > #0 0xf0193d2b in boot () > #1 0xf0112b83 in panic () > #2 0xf0176f67 in ffs_vfree () > #3 0xf017c1f2 in ufs_inactive () > #4 0xf0128d65 in vrele () > #5 0xf0128cab in vput () > #6 0xf017f724 in ufs_remove () > #7 0xf012ad6e in unlink () > #8 0xf019c0a6 in syscall () > #9 0xf019156b in Xsyscall () > #10 0x2d9a in ?? () > #11 0x2b2a in ?? () > #12 0x2507 in ?? () > #13 0x19b9 in ?? () > #14 0x10d3 in ?? () > (kgdb) [ponds.water.net]$ > Script done on Fri Nov 15 07:15:14 1996 > > ------------------------------ > > From: Bill Fenner > Date: Fri, 15 Nov 1996 08:20:44 PST > Subject: Re: multicast - does NT 4.0 have it? Does Linux have it? > > In message <199611151516.QAA04115@gilberto.physik.rwth-aachen.de> you write: > >NT 4.0 > > No. Microsoft apparently has no plans for implementing this, and I have > it on good authority that they use some FreeBSD machines as their internal > multicast routers =) > > >Linux 2.x > > More recent versions, yes. I haven't tried them but have been assured that > they work well. > > Bill > > ------------------------------ > > From: Karl Denninger > Date: Fri, 15 Nov 1996 10:24:05 -0600 (CST) > Subject: Re: Sockets question... > > > > > > > Are you checking the return value from write() to make sure it actually > > > > > > thinks that N bytes were _written_? > > > > > > > > > > > > ... JG > > > > > > > > > > Uh, hang on a second... > > > > > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > > > would expect to see a write(2) call to the socket come back with a short > > > > > count for any reason other than the remote having closed or some other > > > > > kind of transport error (ie: host unreachable, etc)? > > > > > > > > Yes: a nonblocking socket write will most definitely display this > > > > behaviour. > > > > > > Yes, but I did not set nonblocking mode on that socket. > > > > Did you receive a signal? That is known to cause similar behaviour on > > SunOS... > > Can't. Any signal on that process is a SERIOUS error; its a DBMS! We have > a generic "oh shit" trap for all signals set; it does not go off. > > > However, if you received a return value from write() equal to the number > > of bytes you supplied to write(), I would state that the problem is > > almost certainly elsewhere. > > > > ... JG > > Bingo. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Slavik Terletsky > Date: Fri, 15 Nov 1996 18:25:40 +0200 > Subject: Re: Q: How to read hardware port ? *HELP* > > Andrew.Gordon@net-tel.co.uk wrote: > > > Does your port actually want byte-wide reads? There are other macros > > in /usr/include/machine/cpufunc.h for 16-bit or 32-bit reads. > no difference, the hardware just catches the trial of reading 0x443 port > > Say, if i am using port 0x443 and have no driver compiled for it - > can i read this port at all? (without driver!) > - -- > # Slavik Terletsky # University "Lvivska Poytechnica" # > # Network Administrator # mailto:ts@polynet.lviv.ua # > > ------------------------------ > > From: Hal Snyder > Date: Fri, 15 Nov 1996 10:31:33 -0600 > Subject: Re: Programming technique for non-forking servers? > > Not exactly on subject, but does anyone know of a C++ class library for > network servers? Or is C++ still mainly for cooking application-level > code? > > I've looked as socket++, but it seems to have been abandoned, not sure > why. > > ------------------------------ > > From: Bruce Evans > Date: Sat, 16 Nov 1996 03:36:41 +1100 > Subject: Re: Programming technique for non-forking servers? > > >> mset and mclear would be implemented as lib functions because Intel does > >> have an atomic test and set. > > > >Yes it does: the "xchg" instruction. Load 1 into a register, then "xchg" > >the register with the memory location containing the lock. Look at the > >new value of the register to find out whether the lock was already > >locked. > > It also has many other instructions suitable for locking primitives: > > bt, btc, btr, bts (386 up) > sal (386 up) (standard trick) > cmpxchg (486 up) > xadd (486 up) > cmpxchg8b (Pentium (up?)) > > >It even works in a multiprocessor system. According to the > >Intel book: > > > If a memory operand is involved, the LOCK# signal is asserted for the > > duration of the exchange, regardless of the presence or absence of the > > LOCK prefix or of the value of the IOPL. > > I think the other instructions work in multiprocessor systems if they > have a `lock' prefix. The optional locking makes them more useful on > uniprocessors (actually, except for `sal' they are usually too slow to > be worth using except for locking. E.g., on Pentiums `bt' of a memory > variable takes 26 times as long as a simple instruction). > > Bruce > > ------------------------------ > > From: Javier Martin Rueda > Date: Fri, 15 Nov 1996 17:53:37 UTC+0100 > Subject: Contribution of Intel EtherExpress Pro/10 driver > > I've read the handbook on how to contribute new pieces of code to FreeBSD, > and I've done what is says, namely: > > 1. The driver has a BSD-style copyright. > > 2. I've uploaded it to ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming, with > filename if_ex-961115.tar.gz. > > 3. I'm sending a message to hackers@freebsd.org telling about this, so that > someone can commit/review/whatever the driver. > > I hope it is not too late to include this driver in FreeBSD 2.2, assuming you > find it appropriate enough. > > > ------------------------------ > > End of hackers-digest V1 #1641 > ****************************** > > From owner-freebsd-hackers Fri Nov 15 10:11:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04668 for hackers-outgoing; Fri, 15 Nov 1996 10:11:11 -0800 (PST) Received: from VMS1.TAMU.EDU (VMS1.TAMU.EDU [128.194.103.13]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA04592 for ; Fri, 15 Nov 1996 10:10:33 -0800 (PST) Received: from VMS1.TAMU.EDU by VMS1.TAMU.EDU with SMTP; Fri, 15 Nov 1996 12:09:14 -0600 (CST) Date: Fri, 15 Nov 1996 12:09:11 +0000 From: "RIVERA, ELADIO " X-Sender: E0R8047@VMS1.TAMU.EDU To: hackers@freefall.freebsd.org cc: freebsd-hackers-digest@FreeBSD.ORG Subject: Re: hackers-digest V1 #1641 In-Reply-To: <199611151659.IAA29419@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 15 Nov 1996 owner-hackers-digest@freefall.freebsd.org wrote: Does anyone have any hints about Unix I would really appreciate the help. Thanks goat boy > > hackers-digest Friday, 15 November 1996 Volume 01 : Number 1641 > > In this issue: > Re: userland PPP giving weird load numbers > Re: Interesting URL > multicast - does NT 4.0 have it? Does Linux have it? > Re: FreeBSD 2.2-ALPHA is now available. > Re: Sockets question... > Re: Q: system specific binaries > Re: Q: system specific binaries > Re: Sockets question... > Re: Sockets question... > Re: FreeBSD 2.2-ALPHA is now available. > Re: Sockets question... > Today's panic. > Re: multicast - does NT 4.0 have it? Does Linux have it? > Re: Sockets question... > Re: Q: How to read hardware port ? *HELP* > Re: Programming technique for non-forking servers? > Re: Programming technique for non-forking servers? > Contribution of Intel EtherExpress Pro/10 driver > > ---------------------------------------------------------------------- > > From: hm@kts.org (Hellmuth Michaelis) > Date: Fri, 15 Nov 1996 12:45:06 +0100 (MET) > Subject: Re: userland PPP giving weird load numbers > > > > > I see this too all the time, from 2.0.5 all the way to 2.1.5. While > > > > /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, > > > > it'll drop. It's odd ... it's usually when ppp is idle that it hangs > > > > around 1.0. > > > > > > I had this phenomenon too - but NOT with ppp. An isdn userland daemon i am > > > working on showed this exact behaviour; when it was running, the system load > > > was constantly 1.0 or very nearby. This all is under 2.1.5 (and 2.1 too). > > > The process wasn't doing anything (or very little). > > > > But what _was_ it supposed to be doing? > > Ok, when this happened, the daemon was in a tight read() loop, where the > read() timed out every second in the driver. Basically after implementing > select() in the driver and using that with a one second timeout made the > problem go away. > > In the whole application several one second timeouts exists at several > drivers in the kernel - i'm quite shure there is a problem with something > like several timeouts timing out simultaneously causing something. > > I just ran out of ideas where to search for and what to search for so i > stopped looking for the real problem. But i'm able to reproduce it. > > hellmuth > - -- > Hellmuth Michaelis hm@kts.org Hamburg, Europe > (A)bort, (R)etry, (I)nstall BSD ? > - -------------------------------------------------------------------------------- > kts.org will move and will be not available from November 20th for 10 days > - -------------------------------------------------------------------------------- > > ------------------------------ > > From: John Fieber > Date: Fri, 15 Nov 1996 09:11:58 -0500 (EST) > Subject: Re: Interesting URL > > On Thu, 14 Nov 1996, Chuck Robey wrote: > > > I found an interesting URL full of some neat C++ graphics and network > > code. I'm always complaining to friends that C++ doesn't have enough > > public code out there, so this is a nice surprise I thought I'd share. > > Speaking of C++, there is a showstopper problem in 2.2-ALPHA with > respect to STL. The fix appears to be simple and a patch has > been submitted via send-pr. I have neither space nor time at > this final hour to check it out personally or I would commit it > myself, but it would *really* be a shame to ship 2.2 with an > inoperable STL because of 3 missed files in the stdc++ library... > > - -john > > == jfieber@indiana.edu =========================================== > == http://fallout.campusview.indiana.edu/~jfieber ================ > > > ------------------------------ > > From: Christoph Kukulies > Date: Fri, 15 Nov 1996 16:16:02 +0100 > Subject: multicast - does NT 4.0 have it? Does Linux have it? > > As the subject asks: Do NT 4.0 and Linux 2.x have multicast > routing in their kernel, i.e. can they act as a multicast router > resp. run mrouted? > > - --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > ------------------------------ > > From: "Rodney W. Grimes" > Date: Fri, 15 Nov 1996 07:18:11 -0800 (PST) > Subject: Re: FreeBSD 2.2-ALPHA is now available. > > > > I have clients with 2 and 3 of these cards in one system running 32 and > > > 48 ports respectifully. It will work for you when you go above your > > > current 4 port utilization. > > > > > > You are correct about the 8 port not having modem control, but I think > > > the (not positive here) the 4 port does. If not I _know_ the 6 port > > > board does. > > > > 4 port does not, 6 port does. > > > > Unless the product offering has changed lately. > > Thanks Joe, combining your statement with what another person said > defanitly qualifies the fact that the BB1004 does not have modem > support, and that the IOAT66 (6-port) does. > > Jordan, can you please list this in the serial board section of the > release/whatever notes: > > Boca BB1004 4-Port serial card (Modems NOT supported) > Boca IOAT66 6-Port serial card (Modems supported) > Boca BB1008 8-Port serial card (Modems NOT supported) > Boca BB2016 16-Port serial card (Modems supported) > > - -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation, Inc. Reliable computers for FreeBSD > > ------------------------------ > > From: Bruce Evans > Date: Sat, 16 Nov 1996 02:29:19 +1100 > Subject: Re: Sockets question... > > >% man 2 read > >(SunOS version) > >... > >READ(2V) SYSTEM CALLS READ(2V) > > > > system guarantees to read the number of bytes requested if > > the descriptor references a normal file which has that many > > bytes left before the EOF (end of file), but in no other > > case. > > > >Key words, "but in no other case".. > > FreeBSD says the same thing in the same words except for English > improvements. It lies :-). Short reads are possible even for > normal files because the read might be into a partially invalid > buffer. ffs_read() returns the blocks that are successfully > read instead of unwinding the read and returning an EFAULT error. > Example: > > - --- > #include > #include > > #define SIZE 0x10000 > > main() > { > void *buf; > int n; > > > buf = malloc(0x10000); > n = read(0, buf, 0x10000); > printf("read %d\n", n); > } > - --- > > This prints 65536 here. A watertight example can be probably be > constructed using mmap(). > > Short writes to normal files are more likely. They occur when the > disk fills up and for partially invalid buffers. There are more > serious problems for the latter case. > > Bruce > > ------------------------------ > > From: "John S. Dyson" > Date: Fri, 15 Nov 1996 10:43:10 -0500 (EST) > Subject: Re: Q: system specific binaries > > > > > > > Hi, > > > > Does anyone have any experience with customising FreeBSD so that only > > binaries which are compiled on a system itself will actually run on > > that system ? > > So the local compiler has to give a key to each binary when it's > > compiled, and when executed there'd be a check for that key. ? > > That way only people who have access to the compiler may generate > > binaries, and no 'foreign' binaries will be executed by the syetem. > > > > If this is too easy to break, is there perhaps a way to specify > > from which directories binaries may be executed ? > > > Perhaps, formulate a system whereby the flags bits on a file are used > in some way... Note that I am not talking about the "protection" bits, > but there is another group of interesting things called flags bits that > can be placed only under the control of the kernel. Just a thought. > > (Perhaps an "annoint" command???) > John > > ------------------------------ > > From: jlemon@americantv.com (Jonathan Lemon) > Date: Fri, 15 Nov 1996 10:01:10 -0600 > Subject: Re: Q: system specific binaries > > > > Does anyone have any experience with customising FreeBSD so that only > > > binaries which are compiled on a system itself will actually run on > > > that system ? > > > So the local compiler has to give a key to each binary when it's > > > compiled, and when executed there'd be a check for that key. ? > > > That way only people who have access to the compiler may generate > > > binaries, and no 'foreign' binaries will be executed by the syetem. > > > > > > If this is too easy to break, is there perhaps a way to specify > > > from which directories binaries may be executed ? > > > > > Perhaps, formulate a system whereby the flags bits on a file are used > > in some way... Note that I am not talking about the "protection" bits, > > but there is another group of interesting things called flags bits that > > can be placed only under the control of the kernel. Just a thought. > > > > (Perhaps an "annoint" command???) > > Now, why does this remind me of nettrek's "blessed" binaries? > - -- > Jonathan > > ------------------------------ > > From: Karl Denninger > Date: Fri, 15 Nov 1996 10:07:47 -0600 (CST) > Subject: Re: Sockets question... > > > > I have an application which sends a query to a back-end server -- and that > > > server can return literally hundreds of KB of data in response. > > > > > > On very long responses, it just STOPS. > > > > > > The writing end thinks it wrote all of the data, netstat -an shows nothing > > > in the socket buffers, the reader is waiting in read() for more data (it > > > never saw the end marker, and in fact never saw more than half of the > > > response!) > > > > If the socket is not in non-blocking mode, and you do a write(2) of N > > bytes to it, and the write call returns anything other than -1 or N, > > then that is a bug. > > The mode has not been modified; it should be in *blocking* mode. The write > returns the correct number of bytes in each case. > > > If the sending socket returns N, but not all of the data gets to > > the receiving socket, then that is either a bug or a network problem. > > Bingo. Send more than about 400KB in a stream transaction and you WILL see > this. Its very repeatable. > > Bascially, what we do is this: > > The query goes to the server. It specifies the moral equivalent of a > "select" call in ESQL (this is a home-brew database application). > > The server computes the response, and squirts out ~8500 records in response, > each of which is ~140 bytes long. This is 8500 write(2) calls, one for each > record. All return with no errors. > > About 2700 of the records get to the other end. The rest DISAPPEAR. They > are NOT in the socket buffers (netstat -an shows *zero* bytes in the > queue). > > I have *also* seen this if you zmodem a file to a terminal server port. You > have a very good chance of long files not getting there intact. I thought > this was a terminal server problem, but I'm no longer convinced -- this > looks like a problem in the network code. > > Note that for the NETWORK case if we compile an on older machine running a > - -CURRENT kernel (built around the July timeframe, has gcc 2.6.3 on it) the > application does NOT exhibit this problem. > > Compile on the -current machine, and it DOES. > > In both cases the application is linked -static. > > > >From write(2): > > > > When using non-blocking I/O on objects such as sockets that are subject > > ^^^^^^^^^^^^ > > to flow control, write() and writev() may write fewer bytes than request- > > ed; the return value must be noted, and the remainder of the operation > > should be retried when possible. > > > > OK, it doesn't come right out and say directly that it _won't_ do that > > when using blocking I/O. But that is the implication. And it is the > > historical behavior. And it is the behavior that probably 90% of > > network applications are written to expect. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Karl Denninger > Date: Fri, 15 Nov 1996 10:13:58 -0600 (CST) > Subject: Re: Sockets question... > > > > > Are you checking the return value from write() to make sure it actually > > > > thinks that N bytes were _written_? > > > > > > > > ... JG > > > > > > Uh, hang on a second... > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > would expect to see a write(2) call to the socket come back with a short > > > count for any reason other than the remote having closed or some other > > > kind of transport error (ie: host unreachable, etc)? > > > > Yes: a nonblocking socket write will most definitely display this > > behaviour. > > Yes, but I did not set nonblocking mode on that socket. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Joe Greco > Date: Fri, 15 Nov 1996 10:13:49 -0600 (CST) > Subject: Re: FreeBSD 2.2-ALPHA is now available. > > > > 4 port does not, 6 port does. > > > > > > Unless the product offering has changed lately. > > > > Thanks Joe, combining your statement with what another person said > > defanitly qualifies the fact that the BB1004 does not have modem > > support, and that the IOAT66 (6-port) does. > > Actually cruising the Boca Web site is handy... ( :-) :-) ) > > http://www.bocaresearch.com/docs/prodlist.htm > > Product Code: BB1008 > Eight-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix > and PC-MOS. Includes eight six-foot RJ-11 to DB-25 cables. > > Product Code: BB1004 > Four-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and > PC-MOS. Includes four six-foot RJ-11 to DB-25 cables. > > Product Code: IOAT66 > I/O ports for ISA/EISA. Six high-speed RS-232 serial ports with 10-pin RJ-45 > connectors and 16C550 buffered UARTs. Excellent product for bulletin board > and fax server applications. > > Product Code: BB2016 > 16-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and > PC-MOS. External concentrator supports up to 16 RJ-45 ports. > > Unfortunately their use of "RJ-45" is incorrect, it's actually a ten pin > connector, allowing for full modem control. > > > Jordan, can you please list this in the serial board section of the > > release/whatever notes: > > > > Boca BB1004 4-Port serial card (Modems NOT supported) > > Boca IOAT66 6-Port serial card (Modems supported) > > Boca BB1008 8-Port serial card (Modems NOT supported) > > Boca BB2016 16-Port serial card (Modems supported) > > That is reasonable. > > I have been toying with the idea of picking up an IOAT66, but I've had > bad experiences with a BB2016 (interrupt problems) and I am a bit > hesitant to try a Boca serial board again. :-) I guess that's fine > since I don't think I know anyone who sells them anyways. But they > ARE very inexpensive! > > ... JG > > ------------------------------ > > From: Joe Greco > Date: Fri, 15 Nov 1996 10:17:30 -0600 (CST) > Subject: Re: Sockets question... > > > > > > Are you checking the return value from write() to make sure it actually > > > > > thinks that N bytes were _written_? > > > > > > > > > > ... JG > > > > > > > > Uh, hang on a second... > > > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > > would expect to see a write(2) call to the socket come back with a short > > > > count for any reason other than the remote having closed or some other > > > > kind of transport error (ie: host unreachable, etc)? > > > > > > Yes: a nonblocking socket write will most definitely display this > > > behaviour. > > > > Yes, but I did not set nonblocking mode on that socket. > > Did you receive a signal? That is known to cause similar behaviour on > SunOS... > > However, if you received a return value from write() equal to the number > of bytes you supplied to write(), I would state that the problem is > almost certainly elsewhere. > > ... JG > > ------------------------------ > > From: Thomas David Rivers > Date: Fri, 15 Nov 1996 07:23:40 -0500 (EST) > Subject: Today's panic. > > Well, I got a panic last night just after 1am - a different > time; but it's a panic I've reported before. > > "panic: ifree: freeing free inode" > > in ffs_vfree(). > > Recall, this is a 2.1.5-STABLE kernel I grabbed on Oct. 17th > (should I refresh this?), with Terry's suggested check in > vfs_subr.c and David's check for v_usecount==0 in vnode_pager.c > [Previous mail contains the context diff's for these two files.] > > Here's the traceback - but we've seen it before.... > > Again, let me say how much I appreciate everyone's effort on this! > > - Dave Rivers - > > > > [ponds.water.net]$ gdb -k kernel.9 vmcore.9 > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.13 (i386-unknown-freebsd), > Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... > IdlePTD 1e4000 > current pcb at 1d5484 > panic: ifree: freeing free inode > #0 0xf0193d2b in boot () > (kgdb) where > #0 0xf0193d2b in boot () > #1 0xf0112b83 in panic () > #2 0xf0176f67 in ffs_vfree () > #3 0xf017c1f2 in ufs_inactive () > #4 0xf0128d65 in vrele () > #5 0xf0128cab in vput () > #6 0xf017f724 in ufs_remove () > #7 0xf012ad6e in unlink () > #8 0xf019c0a6 in syscall () > #9 0xf019156b in Xsyscall () > #10 0x2d9a in ?? () > #11 0x2b2a in ?? () > #12 0x2507 in ?? () > #13 0x19b9 in ?? () > #14 0x10d3 in ?? () > (kgdb) [ponds.water.net]$ > Script done on Fri Nov 15 07:15:14 1996 > > ------------------------------ > > From: Bill Fenner > Date: Fri, 15 Nov 1996 08:20:44 PST > Subject: Re: multicast - does NT 4.0 have it? Does Linux have it? > > In message <199611151516.QAA04115@gilberto.physik.rwth-aachen.de> you write: > >NT 4.0 > > No. Microsoft apparently has no plans for implementing this, and I have > it on good authority that they use some FreeBSD machines as their internal > multicast routers =) > > >Linux 2.x > > More recent versions, yes. I haven't tried them but have been assured that > they work well. > > Bill > > ------------------------------ > > From: Karl Denninger > Date: Fri, 15 Nov 1996 10:24:05 -0600 (CST) > Subject: Re: Sockets question... > > > > > > > Are you checking the return value from write() to make sure it actually > > > > > > thinks that N bytes were _written_? > > > > > > > > > > > > ... JG > > > > > > > > > > Uh, hang on a second... > > > > > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > > > would expect to see a write(2) call to the socket come back with a short > > > > > count for any reason other than the remote having closed or some other > > > > > kind of transport error (ie: host unreachable, etc)? > > > > > > > > Yes: a nonblocking socket write will most definitely display this > > > > behaviour. > > > > > > Yes, but I did not set nonblocking mode on that socket. > > > > Did you receive a signal? That is known to cause similar behaviour on > > SunOS... > > Can't. Any signal on that process is a SERIOUS error; its a DBMS! We have > a generic "oh shit" trap for all signals set; it does not go off. > > > However, if you received a return value from write() equal to the number > > of bytes you supplied to write(), I would state that the problem is > > almost certainly elsewhere. > > > > ... JG > > Bingo. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Slavik Terletsky > Date: Fri, 15 Nov 1996 18:25:40 +0200 > Subject: Re: Q: How to read hardware port ? *HELP* > > Andrew.Gordon@net-tel.co.uk wrote: > > > Does your port actually want byte-wide reads? There are other macros > > in /usr/include/machine/cpufunc.h for 16-bit or 32-bit reads. > no difference, the hardware just catches the trial of reading 0x443 port > > Say, if i am using port 0x443 and have no driver compiled for it - > can i read this port at all? (without driver!) > - -- > # Slavik Terletsky # University "Lvivska Poytechnica" # > # Network Administrator # mailto:ts@polynet.lviv.ua # > > ------------------------------ > > From: Hal Snyder > Date: Fri, 15 Nov 1996 10:31:33 -0600 > Subject: Re: Programming technique for non-forking servers? > > Not exactly on subject, but does anyone know of a C++ class library for > network servers? Or is C++ still mainly for cooking application-level > code? > > I've looked as socket++, but it seems to have been abandoned, not sure > why. > > ------------------------------ > > From: Bruce Evans > Date: Sat, 16 Nov 1996 03:36:41 +1100 > Subject: Re: Programming technique for non-forking servers? > > >> mset and mclear would be implemented as lib functions because Intel does > >> have an atomic test and set. > > > >Yes it does: the "xchg" instruction. Load 1 into a register, then "xchg" > >the register with the memory location containing the lock. Look at the > >new value of the register to find out whether the lock was already > >locked. > > It also has many other instructions suitable for locking primitives: > > bt, btc, btr, bts (386 up) > sal (386 up) (standard trick) > cmpxchg (486 up) > xadd (486 up) > cmpxchg8b (Pentium (up?)) > > >It even works in a multiprocessor system. According to the > >Intel book: > > > If a memory operand is involved, the LOCK# signal is asserted for the > > duration of the exchange, regardless of the presence or absence of the > > LOCK prefix or of the value of the IOPL. > > I think the other instructions work in multiprocessor systems if they > have a `lock' prefix. The optional locking makes them more useful on > uniprocessors (actually, except for `sal' they are usually too slow to > be worth using except for locking. E.g., on Pentiums `bt' of a memory > variable takes 26 times as long as a simple instruction). > > Bruce > > ------------------------------ > > From: Javier Martin Rueda > Date: Fri, 15 Nov 1996 17:53:37 UTC+0100 > Subject: Contribution of Intel EtherExpress Pro/10 driver > > I've read the handbook on how to contribute new pieces of code to FreeBSD, > and I've done what is says, namely: > > 1. The driver has a BSD-style copyright. > > 2. I've uploaded it to ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming, with > filename if_ex-961115.tar.gz. > > 3. I'm sending a message to hackers@freebsd.org telling about this, so that > someone can commit/review/whatever the driver. > > I hope it is not too late to include this driver in FreeBSD 2.2, assuming you > find it appropriate enough. > > > ------------------------------ > > End of hackers-digest V1 #1641 > ****************************** > > From owner-freebsd-hackers Fri Nov 15 10:11:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04744 for hackers-outgoing; Fri, 15 Nov 1996 10:11:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA04710 for ; Fri, 15 Nov 1996 10:11:28 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA26410; Fri, 15 Nov 1996 10:53:26 -0700 From: Terry Lambert Message-Id: <199611151753.KAA26410@phaeton.artisoft.com> Subject: Re: Sockets question... To: karl@mcs.net (Karl Denninger) Date: Fri, 15 Nov 1996 10:53:26 -0700 (MST) Cc: jdp@polstra.com, karl@mcs.net, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <199611151607.KAA20718@Mercury.mcs.net> from "Karl Denninger" at Nov 15, 96 10:07:47 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > If the sending socket returns N, but not all of the data gets to > > the receiving socket, then that is either a bug or a network problem. > > Bingo. Send more than about 400KB in a stream transaction and you WILL see > this. Its very repeatable. [ ... ] This is a bug. This should be fixed. This is most likely related to inability to continue generating fragments from the source buffer once the local write buffer space has been exhausted. Someone needs to chedk a return value and put in an offset bias buffer copy loop. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 10:13:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04885 for hackers-outgoing; Fri, 15 Nov 1996 10:13:00 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA04833 for ; Fri, 15 Nov 1996 10:12:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA26424; Fri, 15 Nov 1996 10:58:52 -0700 From: Terry Lambert Message-Id: <199611151758.KAA26424@phaeton.artisoft.com> Subject: Re: Sockets question... To: bde@zeta.org.au (Bruce Evans) Date: Fri, 15 Nov 1996 10:58:51 -0700 (MST) Cc: bde@zeta.org.au, jgreco@brasil.moneng.mei.com, terry@lambert.org, hackers@FreeBSD.ORG, jdp@polstra.com, scrappy@ki.net In-Reply-To: <199611151754.EAA20990@godzilla.zeta.org.au> from "Bruce Evans" at Nov 16, 96 04:54:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Oops, pass the pointy hat. This is a non-example since i forgot to > increase the read size and forget to tell you to invoke it with > /kernel as stdin. Increasing the read size to 0x20000 gives > more interesting behaviour: > > on system 1 with 32MB RAM: the kernel panics with a double fault This is, I think, expected behaviour for a page which is not present but for which a kmem mapping exists. This happens because the /kernel file is mapped to /dev/kmem. If you try this with a different file (one without an established mapping), what happens? > on system 2 with 8MB RAM: read returns -1. > > I have seen a similar panic for writing from a bad address like > 0xfffffc00 but I couldn't duplicate the problem and I thought it had > something to do with a fixed vm bug. Or an unfixed one. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 10:14:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA05028 for hackers-outgoing; Fri, 15 Nov 1996 10:14:04 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA04988 for ; Fri, 15 Nov 1996 10:13:40 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15104(5)>; Fri, 15 Nov 1996 10:12:51 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Fri, 15 Nov 1996 10:12:31 -0800 To: Terry Lambert cc: fenner@parc.xerox.com (Bill Fenner), scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Fri, 15 Nov 96 09:17:03 PST." <199611151717.KAA26280@phaeton.artisoft.com> Date: Fri, 15 Nov 1996 10:12:18 PST From: Bill Fenner Message-Id: <96Nov15.101231pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611151717.KAA26280@phaeton.artisoft.com> Terry wrote: >Bill Fenner: >> What you need to do is write all your data to the network, >> and not count on it arriving in the same sized chunks as you wrote it. >> But it will all arrive. > >This is (supposedly) what happens *for you* during packet reassembly >on the receiving end. No; what happens for you at the receiving end is that the packets get reassembled into the same *stream* of data as they were at the sender. The sender can buffer small writes into big chunks, or can fragment big writes. If the underlying MTU of the path changes, writes that didn't used to have to be fragmented may now have to be. Packet N can get lost in the network, while packets N+1, N+2, N+3 and N+4 arrive; when the sender retransmits packet N all of a sudden a ton of data "shows up" at the receiver. The receiver's job is *solely* to put those packets back together into the same stream as the sender sent. >From TCP/IP Illustrated, Volume 1, page 224: A stream of 8-bit bytes is exchanged across the TCP connection between the two applications. There are no record markes automatically inserted by TCP. This is what we called a *byte stream service*. If the application on one end writes 10 bytes, followed by a write of 20 bytes, followed by a write of 50 bytes, the application at the other end of the connection cannot tell what size the individual writes were. The other end may read the 80 bytes in four reads of 20 bytes at a time. One end puts a stream of bytes into TCP and the same. identical stream of bytes appears at the other end. Or, if you'd prefer, you could read RFC's 793 and 1122, but they're more verbose than I'd like to quote. Bill From owner-freebsd-hackers Fri Nov 15 10:17:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA05460 for hackers-outgoing; Fri, 15 Nov 1996 10:17:32 -0800 (PST) Received: from gargoyle.bazzle.com (gargoyle.bazzle.com [206.103.246.190]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA05433 for ; Fri, 15 Nov 1996 10:17:08 -0800 (PST) Received: from gargoyle.bazzle.com (localhost [127.0.0.1]) by gargoyle.bazzle.com (8.8.2/8.6.12) with SMTP id NAA13987; Fri, 15 Nov 1996 13:16:54 -0500 (EST) Date: Fri, 15 Nov 1996 13:16:54 -0500 (EST) From: "Eric J. Chet" To: Hal Snyder cc: hackers@FreeBSD.org Subject: Re: Programming technique for non-forking servers? In-Reply-To: <328C9AE5.7339@vailsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 15 Nov 1996, Hal Snyder wrote: > Not exactly on subject, but does anyone know of a C++ class library for > network servers? Or is C++ still mainly for cooking application-level > code? > > I've looked as socket++, but it seems to have been abandoned, not sure > why. > Hello How about the mother load. ACE(ADAPTIVE Communication Environment) An Object-Oriented Network Programming Toolkit in C++. http://www.cs.wustl.edu/%7Eschmidt/ACE.html Has anybody tried to make this into a port? I have included the overview below. Eric J. Chet - ejc@bazzle.com Overview -------- The ADAPTIVE Communication Environment is an object-oriented toolkit that implements strategic and tactical design patterns to simplify the development of concurrent, event-driven communication software. ACE provides a rich set of reusable C++ wrappers, class categories, and frameworks that perform common communication software tasks across a range of operating system platforms. The communication software tasks provided by ACE include event demultiplexing and event handler dispatching, service initialization, interprocess communication, shared memory management, message routing, dynamic (re)configuration of distributed services, multi-threading, and concurrency control. ACE is targeted for developers of high-performance concurrent network applications and services. The primary goal of ACE is to simplify the development of concurrent OO communication software that utilizes interprocess communication, event demultiplexing, explicit dynamic linking, and concurrency. In addition, ACE automates communication software configuration and reconfiguration by dynamically linking services into applications at run-time and executing these services on one or more processes or threads. ACE has been ported to a wide range of uni-processor and multi-process OS platforms including Win32 (i.e., WinNT and Win95), most versions of UNIX (e.g., SunOS 4.x and 5.x, SGI IRIX, HP-UX, OSF/1, AIX, Linux, and SCO), VxWorks, and MVS OpenEdition. It is currently used in commercial products by dozens of companies. ----- From owner-freebsd-hackers Fri Nov 15 10:20:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA05805 for hackers-outgoing; Fri, 15 Nov 1996 10:20:41 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA05789 for ; Fri, 15 Nov 1996 10:20:32 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id KAA02603; Fri, 15 Nov 1996 10:15:38 -0800 (PST) To: John Fieber cc: Chuck Robey , FreeBSD-Hackers Subject: Re: Interesting URL In-reply-to: Your message of "Fri, 15 Nov 1996 09:11:58 EST." Date: Fri, 15 Nov 1996 10:15:38 -0800 Message-ID: <2601.848081738@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Speaking of C++, there is a showstopper problem in 2.2-ALPHA with > respect to STL. The fix appears to be simple and a patch has > been submitted via send-pr. I have neither space nor time at > this final hour to check it out personally or I would commit it > myself, but it would *really* be a shame to ship 2.2 with an > inoperable STL because of 3 missed files in the stdc++ library... OK, I just dealt with this in -current and in 2.2. Jordan From owner-freebsd-hackers Fri Nov 15 10:29:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06347 for hackers-outgoing; Fri, 15 Nov 1996 10:29:15 -0800 (PST) Received: from ioda.diatel.upm.es (ioda.diatel.upm.es [138.100.49.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA06313 for ; Fri, 15 Nov 1996 10:28:41 -0800 (PST) Received: by ioda.diatel.upm.es (SMI-8.6/SMI-SVR4) Fri, 15 Nov 1996 19:26:34 +0100 X400-Received: by /PRMD=iris/ADMD=400net/C=es/; Relayed; Fri, 15 Nov 1996 19:26:29 UTC+0100 Date: Fri, 15 Nov 1996 19:26:29 UTC+0100 X400-Originator: jmrueda@diatel.upm.es X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=iris/ADMD=400net/C=es/;961115192629] Content-Identifier: 1231 From: Javier Martin Rueda To: hackers@freebsd.org (confirm) Message-ID: <1231*/S=jmrueda/OU=diatel/O=upm/PRMD=iris/ADMD=400net/C=es/@MHS> Subject: New upload of if_ex (EtherExpress Pro/10 driver) MIME-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry for bugging you again. I've just uploaded a new version of the EtherExpress Pro/10 driver. The text indentation of the original sources was sort of a mess. Now, I've passed it through Emacs' BSD style indentation, and some parts will be more easily read. Also, I've deleted a couple of forgotten comments. No code change has taken place. This new version is in: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/if_ex-961115.tar.gz-INDENTED From owner-freebsd-hackers Fri Nov 15 10:34:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06571 for hackers-outgoing; Fri, 15 Nov 1996 10:34:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA06562 for ; Fri, 15 Nov 1996 10:34:30 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26525; Fri, 15 Nov 1996 11:21:55 -0700 From: Terry Lambert Message-Id: <199611151821.LAA26525@phaeton.artisoft.com> Subject: Re: data segment To: imp@village.org (Warner Losh) Date: Fri, 15 Nov 1996 11:21:55 -0700 (MST) Cc: terry@lambert.org, toor@dyson.iquest.net, cskim@cslsun10.sogang.ac.kr, freebsd-hackers@FreeBSD.org In-Reply-To: from "Warner Losh" at Nov 14, 96 10:48:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > : Any chance we can get some additional mappings defined to coincide with > : the Microsoft mappings? I've been trying to load (and use) some simple > : NT drivers, and they want "pageable" (which I wouldn't expect to do > : anything, initially anyway) and "discradable" for init, etc., etc.. > : > : If you need a full list, I can provide it with a day or so lead time. > > Isn't the Microsoft NT stuff PEI format, which is basically COFF or > ECOFF with some mutant headers and minor tweaks? Isn't that different > than our current a.out? Or am I confused again. Yeah, it's different than a.out. 8-). I'm more concerned with having bits to represent the segment attributes that are possible in PE (Portable Executable) format files. Microsoft didn't formerly provide this information. Now they hide it. You can download it from: http://www.microsoft.com/win32dev/base/pefile.htm I am interested in handling the attribute bits: 0x00000020 Code section 0x00000040 Initialized data section 0x00000080 Uninitialized data section 0x04000000 Section cannot be cached 0x08000000 Section is not pageable 0x10000000 Section is shared 0x20000000 Executable section 0x40000000 Readable section 0x80000000 Writable section (obviously, the first 3 are treated as mutually exclusive; the rest are attribute bits applicable to one of the first three). Within the context of a VM page. Basically, segments in a loaded image are grouped by segment indentifier, which implies a set of attributes. There's more documentation on this in "WinICE", where they explain the output of the "VXD" command's "Seg" column. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 10:36:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06796 for hackers-outgoing; Fri, 15 Nov 1996 10:36:54 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA06770 for ; Fri, 15 Nov 1996 10:36:41 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA12528; Fri, 15 Nov 1996 11:32:55 -0700 (MST) Date: Fri, 15 Nov 1996 11:32:55 -0700 (MST) Message-Id: <199611151832.LAA12528@rocky.mt.sri.com> From: Nate Williams To: Terry Lambert Cc: jgreco@brasil.moneng.mei.com (Joe Greco), jdp@polstra.com, scrappy@ki.net, hackers@freebsd.org Subject: Re: Sockets question... In-Reply-To: <199611151748.KAA26388@phaeton.artisoft.com> References: <199611150414.WAA26986@brasil.moneng.mei.com> <199611151748.KAA26388@phaeton.artisoft.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Non-blocking sockets for reliable stream protocols like TCP/IP are > a stupid idea. > > If I wanted datagrams, I would pick a protocol like UDP. You are outta your league now Terry, and into mine. This is what *I* have been doing for years, and I'd like to think I know a little bit about it given that it's what I get paid to do. *grin* You have *very little* idea what you are talking about here, and in the midst of the volumnous email said very little in terms of content and knowledge of what's going on. Your best bet at this point in time is to either back off and leave what little shred of credibility you have, or keep going and lose it all. Yes, you *can* use UDP for packets, but it brings with it a host of other problems too numerous too mention. It's a piece of cake to use TCP to send 'packetized' data (and for many applications the 'right' thing to do) IFF you know what you are doing and are aware of the gotchas, which you apparently don't given your blanket statement. There are tradeoffs for any solution, and knowing the advantages and tradeoffs for each is an excercise left for the reader since Terry's advice is misguided at best, and wrong in the worst case. Nate From owner-freebsd-hackers Fri Nov 15 10:39:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06984 for hackers-outgoing; Fri, 15 Nov 1996 10:39:40 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA06966 for ; Fri, 15 Nov 1996 10:39:30 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id FAA22344; Sat, 16 Nov 1996 05:35:16 +1100 Date: Sat, 16 Nov 1996 05:35:16 +1100 From: Bruce Evans Message-Id: <199611151835.FAA22344@godzilla.zeta.org.au> To: jgreco@brasil.moneng.mei.com, karl@Mcs.Net Subject: Re: Sockets question... Cc: hackers@FreeBSD.org, jdp@polstra.com, scrappy@ki.net Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Did you receive a signal? That is known to cause similar behaviour on >> SunOS... > >Can't. Any signal on that process is a SERIOUS error; its a DBMS! We have >a generic "oh shit" trap for all signals set; it does not go off. Don't do that for SIGIO. Anyone can send SIGIO to any process. Bruce From owner-freebsd-hackers Fri Nov 15 10:42:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07192 for hackers-outgoing; Fri, 15 Nov 1996 10:42:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA07186 for ; Fri, 15 Nov 1996 10:42:37 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26543; Fri, 15 Nov 1996 11:24:50 -0700 From: Terry Lambert Message-Id: <199611151824.LAA26543@phaeton.artisoft.com> Subject: Re: User class/capabilities database To: davidn@sdev.usn.blaze.net.au (David Nugent) Date: Fri, 15 Nov 1996 11:24:50 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "David Nugent" at Nov 15, 96 09:55:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > There is a reference in both man pages and source files to > the user class being a pointer to a "termcap-like" capabilities > and attributes database. I assume that support for this is not > completed, or has ceased. Is this a FreeBSD-specific project, > or is it tied to bsd 4.4lite? I could use this sorts of hook > in an accounting system I'm developing, and was wondering to > whom I might speak for mor information on the subject. > > Specifically, I need to know: > > 1) Is this a FreeBSD specific facility, or is it a bsd one > (involving not only FreeBSD developers but the others)? It's an unimplemented one which BSDI has since implemented. > 2) How much work has already been done already in terms of > standardising user attributes (and what they are), Talk to SEF; he was working on a free implementation. > 3) What existing code supports the facility, and how much > freedom exists to expand the concept to cover user/session > accounting in general. It's non-standard stuff, and will probably be implementation dependent unless the free code wins, or unless BSDI shares their implementation to make it the standard. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 10:45:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07460 for hackers-outgoing; Fri, 15 Nov 1996 10:45:59 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA07452 for ; Fri, 15 Nov 1996 10:45:49 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id KAA04021; Fri, 15 Nov 1996 10:44:35 -0800 (PST) To: "Rodney W. Grimes" cc: jgreco@brasil.moneng.mei.com (Joe Greco), todd@gov.com, hackers@FreeBSD.org Subject: Re: FreeBSD 2.2-ALPHA is now available. In-reply-to: Your message of "Fri, 15 Nov 1996 07:18:11 PST." <199611151518.HAA25295@GndRsh.aac.dev.com> Date: Fri, 15 Nov 1996 10:44:35 -0800 Message-ID: <4019.848083475@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Jordan, can you please list this in the serial board section of the > release/whatever notes: > > Boca BB1004 4-Port serial card (Modems NOT supported) > Boca IOAT66 6-Port serial card (Modems supported) > Boca BB1008 8-Port serial card (Modems NOT supported) > Boca BB2016 16-Port serial card (Modems supported) Done. Needs to be brought into 2.2, but they're in -current and in -stable. Jordan From owner-freebsd-hackers Fri Nov 15 10:52:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07906 for hackers-outgoing; Fri, 15 Nov 1996 10:52:44 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA07895 for ; Fri, 15 Nov 1996 10:52:34 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id KAA18955; Fri, 15 Nov 1996 10:50:52 -0800 (PST) Message-Id: <199611151850.KAA18955@austin.polstra.com> To: Bruce Evans cc: jgreco@brasil.moneng.mei.com, karl@Mcs.Net, hackers@FreeBSD.org, scrappy@ki.net Subject: Re: Sockets question... In-reply-to: Your message of "Sat, 16 Nov 1996 05:35:16 +1100." <199611151835.FAA22344@godzilla.zeta.org.au> References: <199611151835.FAA22344@godzilla.zeta.org.au> Date: Fri, 15 Nov 1996 10:50:52 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Can't. Any signal on that process is a SERIOUS error; its a DBMS! We have > >a generic "oh shit" trap for all signals set; it does not go off. > > Don't do that for SIGIO. Anyone can send SIGIO to any process. Really?! Gads, KILL(2) doesn't say anything about that. I believe you, but isn't that a bug? Is there some useful purpose served by allowing it? John From owner-freebsd-hackers Fri Nov 15 10:58:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA08278 for hackers-outgoing; Fri, 15 Nov 1996 10:58:30 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA08257 for ; Fri, 15 Nov 1996 10:58:24 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id TAA10139 for ; Fri, 15 Nov 1996 19:58:12 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id TAA02294 for freebsd-hackers@freebsd.org; Fri, 15 Nov 1996 19:57:42 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id TAA11081; Fri, 15 Nov 1996 19:25:06 +0100 (MET) Message-ID: Date: Fri, 15 Nov 1996 19:25:05 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-hackers@freebsd.org Subject: Re: User class/capabilities database References: X-Mailer: Mutt 0.50.05 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2686 In-Reply-To: ; from David Nugent on Nov 15, 1996 21:55:02 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to David Nugent: > the user class being a pointer to a "termcap-like" capabilities > and attributes database. I assume that support for this is not > completed, or has ceased. Is this a FreeBSD-specific project, > or is it tied to bsd 4.4lite? I could use this sorts of hook > 1) Is this a FreeBSD specific facility, or is it a bsd one > (involving not only FreeBSD developers but the others)? This is a generic 4.4BSD feature although the code to support them is not written. BSD/OS has an implementation of these. > 2) How much work has already been done already in terms of > standardising user attributes (and what they are), I don't know but I don't believe much. > 3) What existing code supports the facility, and how much > freedom exists to expand the concept to cover user/session > accounting in general. Talk to Sean Eric Fagan who was working into implementing user classes in FreeBSD. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996 From owner-freebsd-hackers Fri Nov 15 11:06:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA08699 for hackers-outgoing; Fri, 15 Nov 1996 11:06:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA08692 for ; Fri, 15 Nov 1996 11:06:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26597; Fri, 15 Nov 1996 11:50:50 -0700 From: Terry Lambert Message-Id: <199611151850.LAA26597@phaeton.artisoft.com> Subject: Re: Sockets question... To: nate@mt.sri.com (Nate Williams) Date: Fri, 15 Nov 1996 11:50:50 -0700 (MST) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, jdp@polstra.com, scrappy@ki.net, hackers@freebsd.org In-Reply-To: <199611151832.LAA12528@rocky.mt.sri.com> from "Nate Williams" at Nov 15, 96 11:32:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Non-blocking sockets for reliable stream protocols like TCP/IP are > > a stupid idea. > > > > If I wanted datagrams, I would pick a protocol like UDP. > > You are outta your league now Terry, and into mine. This is what *I* > have been doing for years, and I'd like to think I know a little bit > about it given that it's what I get paid to do. *grin* > > You have *very little* idea what you are talking about here, and in the > midst of the volumnous email said very little in terms of content and > knowledge of what's going on. > > Your best bet at this point in time is to either back off and leave what > little shred of credibility you have, or keep going and lose it all. > > Yes, you *can* use UDP for packets, but it brings with it a host of > other problems too numerous too mention. It's a piece of cake to use > TCP to send 'packetized' data (and for many applications the 'right' > thing to do) IFF you know what you are doing and are aware of the > gotchas, which you apparently don't given your blanket statement. There > are tradeoffs for any solution, and knowing the advantages and tradeoffs > for each is an excercise left for the reader since Terry's advice is > misguided at best, and wrong in the worst case. There is a difference between "packetized data" (formatting of the data stream) and "datagrams". Karl has set up for blocking reads and writes on a reliable stream delivery transport. The writes on the sender are completing successfully. The data isn't getting to the reads on the receiver. Karl wonders how the writes on the server can blatantly lie to him. I suggest he run a network monitor or tcpdump to determine if: o The data is failing to hit the wire (sender bug) o The data is hitting the wire, but is invalid for reassembly (also a sender bug). Tracking this probably requires a third machine, non-FreeBSD, to act as both sender and receiver against FreeBSD. o The data is hitting the wire, it's in a format the receiver should recognize and deal with correctly, but it's not getting to the user buffer (reveiver bug) He should also try AF_UNIX instead of AF_INET (or vice versa) to further localize the problem to the transport or the generic code. He should also try send/recv in place of write/read, since the fd-to-socket interfaceing in FreeBSD may be less than perfect. But then, this is stating the obvious, as you did above when you referred to a formatted data stream as being "packetized". Given the symptoms he described, before it was clear that he was seeing the writes complete successfully on blocking sockets (indicating all data from his user buffer had been placed in allocated network buffers for subsequent transmission), I enumerated all possible circumstances under which he might see the behaviour. Since Karl is trying to address what is obviously (now that he has made the circumstances clear) a bug in FreeBSD, advice about sending datagrams is the last thing he needs. My suggestion about using F_GETFL to look at the socket defaults remains valid. He should do so, since the problem could easily be in bogus defaults supplied by FreeBSD. In terms of "shredded credibility" or "saying very little in terms of content and knowledge of what's going on", I suggest you muck out your own barn before you offer to muck out mine. You could start with acknowledging that what Karl's trying to do should work, and then identifying the circumstances under which it could potentially fail (much as I have done), instead of assuming that both he and I are "idiots who don't know what they are doing". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 11:15:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09572 for hackers-outgoing; Fri, 15 Nov 1996 11:15:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA09565 for ; Fri, 15 Nov 1996 11:15:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26626; Fri, 15 Nov 1996 11:58:52 -0700 From: Terry Lambert Message-Id: <199611151858.LAA26626@phaeton.artisoft.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 11:58:51 -0700 (MST) Cc: terry@lambert.org, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <96Nov15.101231pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 10:12:18 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> What you need to do is write all your data to the network, > >> and not count on it arriving in the same sized chunks as you wrote it. > >> But it will all arrive. > > > >This is (supposedly) what happens *for you* during packet reassembly > >on the receiving end. > > No; what happens for you at the receiving end is that the packets get > reassembled into the same *stream* of data as they were at the sender. > The sender can buffer small writes into big chunks, or can fragment big > writes. If the underlying MTU of the path changes, writes that didn't > used to have to be fragmented may now have to be. Packet N can get > lost in the network, while packets N+1, N+2, N+3 and N+4 arrive; when > the sender retransmits packet N all of a sudden a ton of data "shows > up" at the receiver. The receiver's job is *solely* to put those > packets back together into the same stream as the sender sent. So at the "read" interface, you *can* count on it arriving in the same sized chunks as you wrote it, as long as the order and chunk size of your reads is identical to those of your writes... in other words, synchronized client and server automatons. Right? IF I issue a blocking read for 1000 bytes, AND I issue a blocking write for 1000 bytes, AND the blocking write returns "1000", THEN the blocking read will return 1000 bytes OR it won't return (EPIPE after connection timeout). Karl is saying he has synchronized client and server automatons, but that it's not working for large buffer sizes on the writes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 11:18:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09908 for hackers-outgoing; Fri, 15 Nov 1996 11:18:35 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.251]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA09899 for ; Fri, 15 Nov 1996 11:18:30 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id LAA23268; Fri, 15 Nov 1996 11:00:03 -0800 (PST) From: Brant Katkansky Message-Id: <199611151900.LAA23268@itchy.atlas.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 11:00:02 -0800 (PST) Cc: rgrimes@GndRsh.aac.dev.com, jgreco@brasil.moneng.mei.com, todd@gov.com, jkh@time.cdrom.com, hackers@FreeBSD.org In-Reply-To: <199611151613.KAA27978@brasil.moneng.mei.com> from Joe Greco at "Nov 15, 96 10:13:49 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I have been toying with the idea of picking up an IOAT66, but I've had I have one I'm not using. I'd be happy to loan it to you so you can evaluate if it meets your needs. -- Brant Katkansky (brantk@atlas.com) Software Engineer, ADC From owner-freebsd-hackers Fri Nov 15 11:28:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA10470 for hackers-outgoing; Fri, 15 Nov 1996 11:28:02 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA10461 for ; Fri, 15 Nov 1996 11:27:54 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16010(3)>; Fri, 15 Nov 1996 11:26:48 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177557>; Fri, 15 Nov 1996 11:24:19 -0800 X-Mailer: exmh version 1.6.7 5/3/96 To: Terry Lambert cc: jdp@polstra.com (John Polstra), scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Fri, 15 Nov 1996 09:06:54 PST." <199611151706.KAA26239@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Nov 1996 11:24:14 PST From: Bill Fenner Message-Id: <96Nov15.112419pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611151706.KAA26239@phaeton.artisoft.com> Terry wrote: >How do I read into a structure on a machine that demands aligned >data access? You read into an intermediate buffer and copy it. You have to convert from network to machine representation anyway, so this isn't (much) more overhead. Or you use UDP if you want a record-oriented protocol. >nothing would work at all if you couldn't issue a read for n >bytes that didn't complete until you *got* n bytes. Well, I guess the BSD networking code has probably never worked at all. The read() system call on a socket is based on soreceive(), which returns up to N bytes. Bill From owner-freebsd-hackers Fri Nov 15 11:34:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA10921 for hackers-outgoing; Fri, 15 Nov 1996 11:34:00 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA10916 for ; Fri, 15 Nov 1996 11:33:53 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16073(6)>; Fri, 15 Nov 1996 11:33:17 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Fri, 15 Nov 1996 11:33:05 -0800 To: Terry Lambert cc: fenner@parc.xerox.com (Bill Fenner), scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Fri, 15 Nov 96 10:58:51 PST." <199611151858.LAA26626@phaeton.artisoft.com> Date: Fri, 15 Nov 1996 11:32:55 PST From: Bill Fenner Message-Id: <96Nov15.113305pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611151858.LAA26626@phaeton.artisoft.com> you write: >So at the "read" interface, you *can* count on it arriving in the >same sized chunks as you wrote it No, you can *never* count on that, since non-blocking reads from a stream socket return as much data as is available, which could be less than you asked for. See soo_read() (or soo_rw() in earlier BSD's) and soreceive(). 4.4BSD introduced the MSG_WAITALL flag, so if you use recv() or any of its friends you can ask for your whole request to be performed. This is, of course, not portable, and MSG_WAITALL won't even do the trick if your request is larger than the socket's high water mark (e.g. SO_RECVBUF). Bill From owner-freebsd-hackers Fri Nov 15 11:55:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA12032 for hackers-outgoing; Fri, 15 Nov 1996 11:55:20 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA12025 for ; Fri, 15 Nov 1996 11:55:16 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA12974; Fri, 15 Nov 1996 12:51:33 -0700 (MST) Date: Fri, 15 Nov 1996 12:51:33 -0700 (MST) Message-Id: <199611151951.MAA12974@rocky.mt.sri.com> From: Nate Williams To: Terry Lambert Cc: nate@mt.sri.com (Nate Williams), jgreco@brasil.moneng.mei.com, jdp@polstra.com, scrappy@ki.net, hackers@freebsd.org Subject: Re: Sockets question... In-Reply-To: <199611151850.LAA26597@phaeton.artisoft.com> References: <199611151832.LAA12528@rocky.mt.sri.com> <199611151850.LAA26597@phaeton.artisoft.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In terms of "shredded credibility" or "saying very little in terms of > content and knowledge of what's going on", I suggest you muck out > your own barn before you offer to muck out mine. I'm telling you that you have no credibility with your statements. > You could start > with acknowledging that what Karl's trying to do should work I never stated it shouldn't. My statement was that your 'blanket' statements in trying to describe his problem show that you like to see your email more than you want to fix the problem. > ... assuming that both he and I > are "idiots who don't know what they are doing". I never stated he didn't know what he was doing, simply that you have shown an obvious lack of understanding of the problem. Nate From owner-freebsd-hackers Fri Nov 15 12:04:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA12579 for hackers-outgoing; Fri, 15 Nov 1996 12:04:15 -0800 (PST) Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA12566 for ; Fri, 15 Nov 1996 12:04:12 -0800 (PST) Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id NAA11689; Fri, 15 Nov 1996 13:22:57 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id UAA28019; Fri, 15 Nov 1996 20:01:04 GMT Message-Id: <199611152001.UAA28019@right.PCS> Date: Fri, 15 Nov 1996 14:01:03 -0600 From: jlemon@americantv.com (Jonathan Lemon) To: terry@lambert.org (Terry Lambert) Cc: jgreco@brasil.moneng.mei.com (Joe Greco), terry@lambert.org, jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org Subject: Re: Sockets question... References: <199611150414.WAA26986@brasil.moneng.mei.com> <199611151748.KAA26388@phaeton.artisoft.com> X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 In-Reply-To: <199611151748.KAA26388@phaeton.artisoft.com>; from Terry Lambert on Nov 15, 1996 10:48:35 -0700 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > Otherwise, you have just un-formatted your transport contents. 8-(. TCP streams are byte oriented, not record oriented. There is no preservation of record boundaries with TCP. > > If you have a blocking read, select() returns true on a FD because one > > byte is available, and you try a read(1000), will it block? > > Yes. It will block pending all 1000 bytes being available. No it won't, if the FD is a socket. It'll return as soon as sequenced data is available from the TCP layer, with the additional constraint: SO_RCVLOWAT is an option to set the minimum count for input operations. In general, receive calls will block until any (non-zero) amount of data is received, then return with the smaller of the amount available or the amount requested. The default value for SO_RCVLOWAT is 1. If SO_RCVLOWAT is set to a larger value, blocking receive calls normally wait until they have received the smaller of the low water mark value or the requested amount. [...] > If you want to get technical, according to this description, if you are > using a SOCK_STREAM, then a read on a blocking socket will act like a > recv(2) or recvfrom(2) with flags MSG_WAITALL by default. read(2), recv(2), and recvfrom(2) all call soreceive() for sockets. read(2) does NOT set MSG_WAITALL when calling soreceive(). Also: * If MSG_WAITALL is set but resid is larger than the receive buffer, * we have to do the receive in sections, and thus risk returning * a short count if a timeout or signal occurs after we start. So MSG_WAITALL can also return a short count. > Maybe you should be using SOCK_SEQPACKET instead of SOCK_STREAM? That might be difficult. A SOCK_SEQPACKET socket [ .... ] is protocol specific, and presently implemented only for PF_NS. (PF_NS == Xerox Network Systems protocols) -- Jonathan From owner-freebsd-hackers Fri Nov 15 12:05:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA12674 for hackers-outgoing; Fri, 15 Nov 1996 12:05:03 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA12658 for ; Fri, 15 Nov 1996 12:04:56 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id LAA03639 for ; Fri, 15 Nov 1996 11:52:49 -0800 (PST) Message-ID: <328CCA0F.2781E494@whistle.com> Date: Fri, 15 Nov 1996 11:52:47 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: cvsup not even hinted at on web pages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk there are plenty of mentions of SUP but none for cvsup.. I think we should conver them over and have a special cvsup page. (I'm trying to convert but the info isn't easy to find from the web) (next I'm going to search the mail archives) julian From owner-freebsd-hackers Fri Nov 15 12:06:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA12760 for hackers-outgoing; Fri, 15 Nov 1996 12:06:18 -0800 (PST) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA12755 for ; Fri, 15 Nov 1996 12:06:15 -0800 (PST) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.2+UW96.11/8.8.2+UW96.10) with SMTP id MAA01618 for ; Fri, 15 Nov 1996 12:06:14 -0800 (PST) Date: Fri, 15 Nov 1996 12:06:13 -0800 (PST) From: John Utz To: hackers@freebsd.org Subject: Maelstrom patch? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello All; I recall somebody posting a patch to Maestroom to get it to compile on freebsd. I thought i had saved it, but i cant find it. What's even more frrustrating is that i used the archive search at www.freebsd.org with the keyord Maelstrom and got totally unrelated mail entries back concering somebody's ethernet card patches... what is up with that? if somebody could send it to me i would appreciate it, i find that i have entirely too much valuable study time on my hands :-)! tnx! ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-hackers Fri Nov 15 12:19:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13298 for hackers-outgoing; Fri, 15 Nov 1996 12:19:02 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA13292 for ; Fri, 15 Nov 1996 12:19:00 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA28769; Fri, 15 Nov 1996 14:14:47 -0600 From: Joe Greco Message-Id: <199611152014.OAA28769@brasil.moneng.mei.com> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Fri, 15 Nov 1996 14:14:47 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org In-Reply-To: <199611151748.KAA26388@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 10:48:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > The problem that is supposedly being addressed by looking at the bytes > > > written is knowing that the data will be available as a unit to the > > > reader. > > > > Wrong, Terry. > > > > The problem that is supposedly being addressed (and as the person who > > wrote the advice, I am telling you indisputably that this is what is > > being addressed) is that sometimes, people will forget that they are > > writing to a particular type of socket (such as {,non}blocking) and > > will inadvertently forget to check to see if all the data was written. > > Non-blocking sockets for reliable stream protocols like TCP/IP are > a stupid idea. I am glad that you can make a broad, sweeping generalization such as that. I guess if I had a lot of faith in the portability of threads, I might agree that that model is not too useful. However, until you can show me a way to write a select() based server that writes data to a client and provides guarantees against blocking on a write() call, I will ask you to kindly avoid making such stupid statements about network programming paradigms. The whole world is NOT broken (although many parts of it are). > If I wanted datagrams, I would pick a protocol like UDP. If I wanted unreliable packet delivery, I would pick a protocol like UDP. If I wanted reliable stream oriented data delivery, I would pick a protocol like TCP. If I wanted reliable stream oriented data delivery, while still being able to provide guarantees of availability of the server process, which is closer to being able to provide it? > > In the case of a nonblocking socket, the test is mandatory. > > What is this, a bizzarre method of dealing with source quench on TCP? No. It is a method of testing to see how much data actually made it into the pipe. If I want to do a write(fd, buf, 1048576) on a socket connected via a 9600 baud SLIP link, I might expect the system call to take around 1092 seconds. If I have a server process dealing with two such sockets, response time will be butt slow if the server is currently writing to the other socket... it has to wait for the write to complete because write(2) has to finish sending the entire 1048576 bytes. So a clever software author does not do this. He has 1048576 bytes of (different, even) data that he wants to write "simultaneously" to two sockets. He wants to do the equivalent of Sun's aiowrite(fd1, buf1, 1048576, SEEK_CUR, 0, NULL); aiowrite(fd2, buf2, 1048576, SEEK_CUR, 0, NULL); Well how the hell do you do THAT if you are busy blocked in a write call? Well, you use non-blocking I/O... and you take advantage of the fact that the OS is capable of buffering some data on your behalf. Let's say you have "buf1" and "buf2" to write to "fd1" and "fd2", and "len1" and "len2" for the size of the corresponding buf's. You write code to do the following: rval = write(fd1, buf1, len1) # Wrote 2K of data len1 -= rval; # 1046528 bytes remain buf1 += rval; # Move forward 2K in buffer rval = write(fd2, buf2, len2) # Wrote 3K of data len2 -= rval; # 1045504 bytes remain buf2 += rval; # Move forward 3K in buffer rval = write(fd1, buf1, len1) # Wrote 1K of data len1 -= rval; # 1045504 bytes remain buf1 += rval; # Move forward 1K in buffer rval = write(fd2, buf2, len2) # Wrote 1K of data len2 -= rval; # 1044480 bytes remain buf2 += rval; # Move forward 1K in buffer You can trivially do this with a moderately complex select() mechanism, so that the outbound buffers for both sockets are kept filled. A little hard to do without nonblocking sockets. Very useful. I don't think that this is a "stupid idea" at all. > What is the point of a non-blocking write if this is what happens? I will leave that as your homework for tonite. > I assume you would use this for "frigging huge writes which you expect > to exceed the available buffer space"? This is potentially useful > for lazy programmers, and for directed finite state automatons. On Please tell that to FreeBSD's FTP server, which uses a single (blocking) write to perform delivery of data. Why should an application developer have to know or care what the available buffer space is? Please tell me where in write(2) and read(2) it says I must worry about this. It doesn't. > Otherwise, you have just un-formatted your transport contents. 8-(. > > > > In the case of an indeterminate socket, the test is also mandatory - > > precisely BECAUSE you don't know. > > Indeterminate sockets are evil. They are on the order of not knowing > your lock state when entering into a function that's going to need > the lock held. I suppose you have never written a library function. I suppose you do not subscribe to the philosophy that you should be liberal in what you accept (in this case, assume that you may need to deal with either type of socket). I wonder if anyone has ever rewritten one of your programs, and made a fundamental change that silently broke one of your programs because an underlying concept was changed. Any software author who writes code and does not perform reasonable sanity checks on the return value, particularly for something as important as the read and write system calls, is hanging a big sign around their neck saying "Kick Me I Code Worth Shit". > > I am not too sure that statement is true... but then I am a paranoid > > programmer, so I always define an xread() function guaranteed to do what > > I mean. Still, that bothers me... > > It bothers me too... I am used to formatting my IPC data streams. I > either use fixed length data units so that the receiver can post a > fixed size read, or I use a fix length data unit, and guarantee write > ordering by maintaining state. I do this in order to send a fixed > length header to indicate that I'm writing a variable length packet, > so the receiver can then issue a blocking read for the right size. I have never seen that work as expected with a large data size. > > > Instead of making a non-blocking read for which "it's OK if no data > > > is available", use select() and only call a blocking read if the select > > > is true. > > > > And I think this is what I was looking for... > > > > If you have a blocking read, select() returns true on a FD because one > > byte is available, and you try a read(1000), will it block? > > Yes. It will block pending all 1000 bytes being available. Wrong. > > I am reasonably certain that it will not - it will return the one byte. > > > > Ahhh. Yes. > > > > % man 2 read > > (SunOS version) > > > > Upon successful completion, read() and readv() return the > > number of bytes actually read and placed in the buffer. The > > > > Sun Release 4.1 Last change: 21 January 1990 1 > > > > READ(2V) SYSTEM CALLS READ(2V) > > > > system guarantees to read the number of bytes requested if > > the descriptor references a normal file which has that many > > bytes left before the EOF (end of file), but in no other > > case. > > > > Key words, "but in no other case".. > > That isn't the same as "and guarantees to return random numbers in all > other cases". 8-). Sigh. > The question, I suppose, is whether pending packet data less than the > packet length from the transmitter is fragged. > > To answer that, I refer you to socket(2). > > Specifically, you are describing the difference between SOCK_STREAM > and SOCK_SEQPACKET... the short reads you are defining are for the > SOCK_SEQPACKET case. From the man page: > > The communications protocols used to implement a SOCK_STREAM insure that > data is not lost or duplicated. If a piece of data for which the peer > protocol has buffer space cannot be successfully transmitted within a > reasonable length of time, then the connection is considered broken and > calls will indicate an error with -1 returns and with ETIMEDOUT as the > specific code in the global variable errno. The protocols optionally keep > sockets ``warm'' by forcing transmissions roughly every minute in the ab- > sence of other activity. An error is then indicated if no response can > be elicited on an otherwise idle connection for a extended period (e.g. 5 > minutes). A SIGPIPE signal is raised if a process sends on a broken > stream; this causes naive processes, which do not handle the signal, to > exit. > > If you want to get technical, according to this description, if you are > using a SOCK_STREAM, then a read on a blocking socket will act like a > recv(2) or recvfrom(2) with flags MSG_WAITALL by default. HUH? Where the hell do you get THAT from? Sigh. Terry, take the weekend off. You are obviously a few cards short of a full deck :-) ... JG From owner-freebsd-hackers Fri Nov 15 12:23:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA13477 for hackers-outgoing; Fri, 15 Nov 1996 12:23:08 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA13469 for ; Fri, 15 Nov 1996 12:23:03 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA28812; Fri, 15 Nov 1996 14:21:51 -0600 From: Joe Greco Message-Id: <199611152021.OAA28812@brasil.moneng.mei.com> Subject: Re: Sockets question... To: bde@zeta.org.au (Bruce Evans) Date: Fri, 15 Nov 1996 14:21:51 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, karl@mcs.net, hackers@FreeBSD.org, jdp@polstra.com, scrappy@ki.net In-Reply-To: <199611151835.FAA22344@godzilla.zeta.org.au> from "Bruce Evans" at Nov 16, 96 05:35:16 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >> Did you receive a signal? That is known to cause similar behaviour on > >> SunOS... > > > >Can't. Any signal on that process is a SERIOUS error; its a DBMS! We have > >a generic "oh shit" trap for all signals set; it does not go off. > > Don't do that for SIGIO. Anyone can send SIGIO to any process. Bruce, Could you clarify what you mean? Obviously "anyone" can not do that... Sorry, I am just missing your meaning. ... JG From owner-freebsd-hackers Fri Nov 15 12:37:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA14427 for hackers-outgoing; Fri, 15 Nov 1996 12:37:40 -0800 (PST) Received: from apollo.it.hq.nasa.gov (apollo.it.hq.nasa.gov [131.182.119.87]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA14422 for ; Fri, 15 Nov 1996 12:37:38 -0800 (PST) Received: from wirehead.it.hq.nasa.gov (WireHead.it.hq.nasa.gov [131.182.119.88]) by apollo.it.hq.nasa.gov (8.6.12/8.6.12) with ESMTP id UAA01631 for ; Fri, 15 Nov 1996 20:37:59 GMT Received: from localhost (cshenton@localhost) by wirehead.it.hq.nasa.gov (8.6.12/8.6.12) with SMTP id UAA29055 for ; Fri, 15 Nov 1996 20:37:03 GMT Message-Id: <199611152037.UAA29055@wirehead.it.hq.nasa.gov> X-Authentication-Warning: wirehead.it.hq.nasa.gov: cshenton owned process doing -bs X-Authentication-Warning: wirehead.it.hq.nasa.gov: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: 2.1.5-stable build fails in gdb, mrouted, named, nslookup X-Mailer: Mew version 1.03 on Emacs 19.31.8 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 15 Nov 1996 15:37:02 -0500 From: Chris Shenton Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Flame me (informatively) if I'm doing this wrong, but... I'm running 2.1.5-RELEASE and recently supped -stable. I do a "make world" from /usr/src, and get a few compilation errors that I probably shouldn't. Nothing fatal, but gdb, mroute, named, and nslookup *should* build. Can anyone enlighten me? Thanks. cd /usr/src/ make -k [...] ===> gnu/usr.bin/gdb/gdb cc -O -I/home/src/gnu/usr.bin/gdb/gdb/. -I/usr/include/readline -I/home/src/gnu/usr.bin/gdb/gdb/../bfd -o gdb annotate.o blockframe.o breakpoint.o buildsym.o c-lang.o c-typeprint.o c-valprint.o ch-lang.o ch-typeprint.o ch-valprint.o coffread.o command.o complaints.o copying.o core.o coredep.o corelow.o cp-valprint.o dcache.o dbxread.o demangle.o disassemble.o dis-buf.o dwarfread.o elfread.o environ.o eval.o exec.o expprint.o findvar.o fork-child.o freebsd-nat.o gdbtypes.o i386-dis.o i386-pinsn.o i386-tdep.o infcmd.o inflow.o infptrace.o infrun.o inftarg.o init.o kcorelow.o language.o m2-lang.o m2-typeprint.o m2-valprint.o main.o maint.o mem-break.o minsyms.o objfiles.o parse.o printcmd.o remote.o remote-utils.o solib.o source.o stabsread.o stack.o symfile.o symmisc.o symtab.o target.o thread.o top.o typeprint.o utils.o valarith.o valops.o valprint.o values.o version.o serial.o ser-unix.o mdebugread.o c-exp.tab.o ch-exp.tab.o m2-exp.tab.o compat_que.o -lreadline -ltermca! p ! -lgnuregex -L/home/src/gnu/usr.bin/gdb/gdb/../libiberty/obj -liberty -L/home/src/gnu/usr.bin/gdb/gdb/../bfd/obj -lbfd -L/home/src/gnu/usr.bin/gdb/gdb/../mmalloc/obj -lmmalloc utils.o: Undefined symbol `_vasprintf' referenced from text segment utils.o: Undefined symbol `_vasprintf' referenced from text segment *** Error code 1 (continuing) `all' not remade because of errors. ===> usr.sbin/mrouted/mrouted cc -O -I/home/src/usr.sbin/mrouted/mrouted/.. -DRSRR -DRSRR -o mrouted config.o cfparse.o main.o route.o vif.o prune.o callout.o rsrr.o -L/home/src/usr.sbin/mrouted/mrouted/obj/../common -lmrouted main.o: Undefined symbol `_configfilename' referenced from text segment vif.o: Undefined symbol `_configfilename' referenced from text segment vif.o: Undefined symbol `_config_vifs_from_file' referenced from text segment *** Error code 1 (continuing) `all' not remade because of errors. ===> usr.sbin/named cc -O -o named version.o db_dump.o db_load.o db_lookup.o db_reload.o db_save.o db_update.o db_secure.o db_glue.o ns_forw.o ns_init.o ns_main.o ns_maint.o ns_req.o ns_resp.o ns_sort.o ns_stats.o ns_validate.o ns_ncache.o storage.o dmalloc.o tree.o -lutil ns_main.o: Undefined symbol `_Version' referenced from text segment ns_main.o: Undefined symbol `_Version' referenced from text segment *** Error code 1 (continuing) `all' not remade because of errors. ===> usr.sbin/nslookup cc -O -o nslookup main.o commands.o getinfo.o debug.o send.o skip.o list.o subr.o -ll main.o: Undefined symbol `_yylex' referenced from text segment subr.o: Undefined symbol `_yyin' referenced from text segment subr.o: Undefined symbol `_yyrestart' referenced from text segment *** Error code 1 (continuing) `all' not remade because of errors. From owner-freebsd-hackers Fri Nov 15 12:44:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA14823 for hackers-outgoing; Fri, 15 Nov 1996 12:44:04 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA14802 for ; Fri, 15 Nov 1996 12:43:56 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA28878; Fri, 15 Nov 1996 14:37:12 -0600 From: Joe Greco Message-Id: <199611152037.OAA28878@brasil.moneng.mei.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 14:37:11 -0600 (CST) Cc: terry@lambert.org, jdp@polstra.com, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <96Nov15.112419pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 11:24:14 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In message <199611151706.KAA26239@phaeton.artisoft.com> Terry wrote: > >How do I read into a structure on a machine that demands aligned > >data access? > > You read into an intermediate buffer and copy it. You have to convert from > network to machine representation anyway, so this isn't (much) more overhead. > Or you use UDP if you want a record-oriented protocol. Actually... I usually found it easier to do the following. #include /* * One dull variant of Joe's "xread" function. */ int xread(fd, buf, siz) int fd; char *buf; int siz; { int rval; int chrs = 0; while (siz) { if ((rval = read(fd, buf, siz)) < 0) { return(rval); } chrs += rval; siz -= rval; buf += rval; } } int main() { int rval; struct big_ugly { yadda; yadda; yadda; } data; if ((rval = xread(fd, (char *)&data, sizeof(data))) != sizeof(data)) { fprintf(stderr, "Help me, I am on fire, xread returned %d\n", rval); } } This of course assumes you either do not need to do byte reordering, or do it elsewhere. ... JG From owner-freebsd-hackers Fri Nov 15 12:50:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA15247 for hackers-outgoing; Fri, 15 Nov 1996 12:50:52 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA15242 for ; Fri, 15 Nov 1996 12:50:50 -0800 (PST) Received: from alpha.Xerox.COM by mail.crl.com with SMTP id AA21468 (5.65c/IDA-1.5 for ); Fri, 15 Nov 1996 12:51:46 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16276(6)>; Fri, 15 Nov 1996 12:44:24 PST Received: by crevenia.parc.xerox.com id <177557>; Fri, 15 Nov 1996 12:44:12 -0800 From: Bill Fenner To: fenner@parc.xerox.com, jgreco@brasil.moneng.mei.com Subject: Re: Sockets question... Cc: hackers@freebsd.org Message-Id: <96Nov15.124412pst.177557@crevenia.parc.xerox.com> Date: Fri, 15 Nov 1996 12:44:03 PST Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Actually... I usually found it easier to do the following. And that's what Terry's complaining about; if you have alignment requirements when writing big_ugly->yadda, those alignment requirements might not be met by the read() inside of xread(). Bill From owner-freebsd-hackers Fri Nov 15 13:00:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA15966 for hackers-outgoing; Fri, 15 Nov 1996 13:00:31 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA15957 for ; Fri, 15 Nov 1996 13:00:28 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA28943; Fri, 15 Nov 1996 14:59:35 -0600 From: Joe Greco Message-Id: <199611152059.OAA28943@brasil.moneng.mei.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 14:59:34 -0600 (CST) Cc: fenner@parc.xerox.com, jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <96Nov15.124412pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 12:44:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Actually... I usually found it easier to do the following. > > And that's what Terry's complaining about; if you have alignment > requirements when writing big_ugly->yadda, those alignment requirements > might not be met by the read() inside of xread(). Ummm... and the problem is...? As far as I am aware, byte oriented data can be written to unaligned addresses on any UNIX architecture that I have seen. xread is explicitly called with what is clearly a byte oriented buffer. If you are possibly worried about something such as the atomicity of reads (potentially valid in a threaded environment, or one using shared memory), I agree that there may be some concern. Since it is not clear to _me_ that such atomicity of access would be valid under the same circumstances even with read(), I would probably code around the situation anyways. Is there some other problem that I am missing? I've done this sort of things for several years now... ... JG From owner-freebsd-hackers Fri Nov 15 13:01:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16067 for hackers-outgoing; Fri, 15 Nov 1996 13:01:29 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA16047 for ; Fri, 15 Nov 1996 13:01:23 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id HAA27679; Sat, 16 Nov 1996 07:59:35 +1100 Date: Sat, 16 Nov 1996 07:59:35 +1100 From: Bruce Evans Message-Id: <199611152059.HAA27679@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: Sockets question... Cc: hackers@FreeBSD.org, jdp@polstra.com, jgreco@brasil.moneng.mei.com, scrappy@ki.net Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> on system 1 with 32MB RAM: the kernel panics with a double fault > >This is, I think, expected behaviour for a page which is not present but >for which a kmem mapping exists. This happens because the /kernel file >is mapped to /dev/kmem. Not in FreeBSD. /kernel is an ordinary, unmapped file. >If you try this with a different file (one without an established mapping), >what happens? Same. It was a bug in i586_copyout. > >> on system 2 with 8MB RAM: read returns -1. This worked because it's an i486. The memory size was irrelevant. This shows why everyone should include full information information in bug reports. Bruce From owner-freebsd-hackers Fri Nov 15 13:02:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16149 for hackers-outgoing; Fri, 15 Nov 1996 13:02:43 -0800 (PST) Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA16143 for ; Fri, 15 Nov 1996 13:02:41 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.2/8.7.3) with ESMTP id NAA01999 for ; Fri, 15 Nov 1996 13:02:31 -0800 (PST) Received: from incognito.intel.com by ichips.intel.com (8.7.4/jIII) id NAA26156; Fri, 15 Nov 1996 13:01:58 -0800 (PST) Received: (from haertel@localhost) by incognito.intel.com (8.7.5/8.7.3) id NAA09906 for hackers@FreeBSD.org; Fri, 15 Nov 1996 13:04:52 -0800 (PST) Date: Fri, 15 Nov 1996 13:04:52 -0800 (PST) From: Mike Haertel Message-Id: <199611152104.NAA09906@incognito.intel.com> To: hackers@FreeBSD.org Subject: earlier "holographic shell" in 2.2-ALPHA install procedure Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I would like the ability to launch the "emergency holographic shell" earlier in the install process, say from a menu entry somewhere. Mainly I would like to be able to launch it before "ifconfig" is called in network installs. From owner-freebsd-hackers Fri Nov 15 13:15:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16647 for hackers-outgoing; Fri, 15 Nov 1996 13:15:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA16642 for ; Fri, 15 Nov 1996 13:15:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA26903; Fri, 15 Nov 1996 13:58:03 -0700 From: Terry Lambert Message-Id: <199611152058.NAA26903@phaeton.artisoft.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 13:58:03 -0700 (MST) Cc: terry@lambert.org, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <96Nov15.113305pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 11:32:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >So at the "read" interface, you *can* count on it arriving in the > >same sized chunks as you wrote it > > No, you can *never* count on that, since non-blocking reads from a stream > socket return as much data as is available, which could be less than you > asked for. See soo_read() (or soo_rw() in earlier BSD's) and soreceive(). By default, the sockets are blocking. You have to go out of your way to make them non-blocking (ie: loading the gun before you can shoot yourself in the foot). > 4.4BSD introduced the MSG_WAITALL flag, so if you use recv() or any of its > friends you can ask for your whole request to be performed. This is, of > course, not portable, and MSG_WAITALL won't even do the trick if your > request is larger than the socket's high water mark (e.g. SO_RECVBUF). This makes sense. But on a blocking socket, it doesn't make sense to have to issue multiple system calls to read chunks of a whole message when you aren't going to do anything with it until all the reads have been satisfied? It makes sense to do it on the server, if you have a server getting messaged from a bunch of sources, but that's just moving the packet assembly into user space. You'd expect the server to have a higher premium on interleaving operations than on atomicity of transactions. Even so, this only becomes a problem if you send "outrageously large" packets in a single write. You'd think that you could move it back down into kernel space by the select not coming true until all frags had been reassembled. I could see SO_RECVBUF putting a limit on your biggest message size in that case. The MSG_WAITALL seems like, even without the flag, it would be the default behaviour for the read. The alternative is to push the "frag" assembly ("frags" in this case being buffers larger than SO_RECVBUF cut into SO_RECVBUF) up into the user program, an dictate to the user how he must code a state machine in user space in order to use the interface. Ugh, copy overhead. Bleah. 8-(. I suppose one very real possibility is that he's trying to send huge packets... most of the drivers don't support them, and the DEC driver supports them only with a couple of patches that Matt and Amancio beat out between them a while back... If it's huge packets, he's probably SOL, and needs to redesign his stream formatting. Anyway, let's wait and see what clarifications he has to offer before we speculate ourselves to death. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 13:23:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17134 for hackers-outgoing; Fri, 15 Nov 1996 13:23:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA17126 for ; Fri, 15 Nov 1996 13:23:19 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA26956; Fri, 15 Nov 1996 14:09:35 -0700 From: Terry Lambert Message-Id: <199611152109.OAA26956@phaeton.artisoft.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 14:09:34 -0700 (MST) Cc: terry@lambert.org, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@FreeBSD.org In-Reply-To: <96Nov15.113305pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 11:32:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > In message <199611151858.LAA26626@phaeton.artisoft.com> you write: > >So at the "read" interface, you *can* count on it arriving in the > >same sized chunks as you wrote it > > No, you can *never* count on that, since non-blocking reads from a stream > socket return as much data as is available, which could be less than you > asked for. See soo_read() (or soo_rw() in earlier BSD's) and soreceive(). > > 4.4BSD introduced the MSG_WAITALL flag, so if you use recv() or any of its > friends you can ask for your whole request to be performed. This is, of > course, not portable, and MSG_WAITALL won't even do the trick if your > request is larger than the socket's high water mark (e.g. SO_RECVBUF). Maybe this is where I'm confused. I was under the impression that the MSG_WAITALL was for messages that had to be passed up to free up the receive buffer, and was put there to allow the copy to the user buffer to occur in SO_RECVBUF-sized chunks. Again, we aren't really interested in the non-blocking socket case... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 13:24:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17264 for hackers-outgoing; Fri, 15 Nov 1996 13:24:53 -0800 (PST) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA17258 for ; Fri, 15 Nov 1996 13:24:45 -0800 (PST) Received: (from tony@localhost) by nlanr.net (8.7.3/8.7.3) id NAA29098 for hackers@freefall.freebsd.org; Fri, 15 Nov 1996 13:23:20 -0800 (PST) From: Tony Sterrett Message-Id: <199611152123.NAA29098@nlanr.net> Subject: Kernel Commands To: hackers@freefall.freebsd.org Date: Fri, 15 Nov 1996 13:23:20 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello everybody: Does there exist systems calls used in the kernel to do things like disabling the cache(Pentum), allocating memory etc. Can someone do me the flavor of posting and call for disabling cache and maybe provide a reference to this class of commands. Thanks in Advance. Tony From owner-freebsd-hackers Fri Nov 15 13:26:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17342 for hackers-outgoing; Fri, 15 Nov 1996 13:26:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA17325 for ; Fri, 15 Nov 1996 13:25:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA26970; Fri, 15 Nov 1996 14:11:24 -0700 From: Terry Lambert Message-Id: <199611152111.OAA26970@phaeton.artisoft.com> Subject: Re: Sockets question... To: nate@mt.sri.com (Nate Williams) Date: Fri, 15 Nov 1996 14:11:24 -0700 (MST) Cc: terry@lambert.org, nate@mt.sri.com, jgreco@brasil.moneng.mei.com, jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org In-Reply-To: <199611151951.MAA12974@rocky.mt.sri.com> from "Nate Williams" at Nov 15, 96 12:51:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I'm telling you that you have no credibility with your statements. [ ... ] > I never stated it shouldn't. My statement was that your 'blanket' > statements in trying to describe his problem show that you like to see > your email more than you want to fix the problem. [ ... ] > I never stated he didn't know what he was doing, simply that you have > shown an obvious lack of understanding of the problem. Well Nate, you stud, you... If you can solve his problem in 3 notes... SOLVE HIS PROBLEM! Otherwise you are doing exactly what you accuse me of doing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 13:28:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17495 for hackers-outgoing; Fri, 15 Nov 1996 13:28:18 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA17445 for ; Fri, 15 Nov 1996 13:28:05 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id NAA26454; Fri, 15 Nov 1996 13:26:22 -0800 (PST) From: "Rodney W. Grimes" Message-Id: <199611152126.NAA26454@GndRsh.aac.dev.com> Subject: Re: FreeBSD 2.2-ALPHA is now available. In-Reply-To: <199611151613.KAA27978@brasil.moneng.mei.com> from Joe Greco at "Nov 15, 96 10:13:49 am" To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 13:26:22 -0800 (PST) Cc: jgreco@brasil.moneng.mei.com, todd@gov.com, jkh@time.cdrom.com, hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > 4 port does not, 6 port does. > > > > > > Unless the product offering has changed lately. > > > > Thanks Joe, combining your statement with what another person said > > defanitly qualifies the fact that the BB1004 does not have modem > > support, and that the IOAT66 (6-port) does. > > Actually cruising the Boca Web site is handy... ( :-) :-) ) > > http://www.bocaresearch.com/docs/prodlist.htm ... > > Unfortunately their use of "RJ-45" is incorrect, it's actually a ten pin > connector, allowing for full modem control. It is correct, it is called an RJ-45/10, I know, I had to order a bunch of them to make cables when Boca was backorder 30 days on them. You also need a special set of die's for your crimp tool, but it is infact known as an RJ-45, they just left the /10 off :-(. > > Jordan, can you please list this in the serial board section of the > > release/whatever notes: > > > > Boca BB1004 4-Port serial card (Modems NOT supported) > > Boca IOAT66 6-Port serial card (Modems supported) > > Boca BB1008 8-Port serial card (Modems NOT supported) > > Boca BB2016 16-Port serial card (Modems supported) > > That is reasonable. > > I have been toying with the idea of picking up an IOAT66, but I've had > bad experiences with a BB2016 (interrupt problems) and I am a bit > hesitant to try a Boca serial board again. :-) I guess that's fine > since I don't think I know anyone who sells them anyways. But they > ARE very inexpensive! Ahhh... I sell them.... just not a regular item :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-hackers Fri Nov 15 13:31:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA17762 for hackers-outgoing; Fri, 15 Nov 1996 13:31:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA17753 for ; Fri, 15 Nov 1996 13:31:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA26946; Fri, 15 Nov 1996 14:06:50 -0700 From: Terry Lambert Message-Id: <199611152106.OAA26946@phaeton.artisoft.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 14:06:50 -0700 (MST) Cc: terry@lambert.org, jdp@polstra.com, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <96Nov15.112419pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 11:24:14 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >How do I read into a structure on a machine that demands aligned > >data access? > > You read into an intermediate buffer and copy it. You have to convert from > network to machine representation anyway, so this isn't (much) more overhead. DCE RPC does not do a conversion if both ends are the same byte order. BSD RPC does not do a conversion on hardware with correct endianess. I think this is why #pragma pack was invented. 8-(. > >nothing would work at all if you couldn't issue a read for n > >bytes that didn't complete until you *got* n bytes. > > Well, I guess the BSD networking code has probably never worked at all. > The read() system call on a socket is based on soreceive(), which > returns up to N bytes. On a non-blocking socket, right? Or in the case of a blocking call for more bytes than SO_RECVBUF (which you can determine via getsockopt and therefore never trigger). Can it return less than N otherwise? The WAITALL case is only for the user buffer larger than SO_RECVBUF, right? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 13:41:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA18702 for hackers-outgoing; Fri, 15 Nov 1996 13:41:26 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA18685 for ; Fri, 15 Nov 1996 13:41:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA27028; Fri, 15 Nov 1996 14:26:42 -0700 From: Terry Lambert Message-Id: <199611152126.OAA27028@phaeton.artisoft.com> Subject: Re: Sockets question... To: jlemon@americantv.com (Jonathan Lemon) Date: Fri, 15 Nov 1996 14:26:41 -0700 (MST) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org In-Reply-To: <199611152001.UAA28019@right.PCS> from "Jonathan Lemon" at Nov 15, 96 02:01:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Otherwise, you have just un-formatted your transport contents. 8-(. > > TCP streams are byte oriented, not record oriented. There is no preservation > of record boundaries with TCP. I am talking about imposing structure on the stream on the basis of forcing the programs to communicate with the stream using record sized chunks. It's irrelevent what happens in the wire, or how the kernel chooses to copy the byte-oriented data into the user buffer on the receiver, so long as the receiver is not falsly notified that the request has been fulfilled. I admit that there is an implication here that I didn't take into account: That two writes to a socket will not be agregated across write buffer boundries into a single packet, OR that the receiver will read an amount such that if agregation occurs, it is irrelevent to the receiver's ability to distinguish the boundries. I have to say that SO_RCVLOWAT and SO_RCVTIMEO screw this considerably, in their roles as vmin/vtime equivalents. 8-(. My advice for someone building a transaction oriented protocol would be to set SO_RCVLOWAT to the same value as SO_RCVBUF, and to never, ever do packets larger than that as part of the formatted data. > > If you want to get technical, according to this description, if you are > > using a SOCK_STREAM, then a read on a blocking socket will act like a > > recv(2) or recvfrom(2) with flags MSG_WAITALL by default. > > read(2), recv(2), and recvfrom(2) all call soreceive() for sockets. read(2) > does NOT set MSG_WAITALL when calling soreceive(). Also: Well, this is probably an error for a blocking socket read, then... 8-(. > * If MSG_WAITALL is set but resid is larger than the receive buffer, > * we have to do the receive in sections, and thus risk returning > * a short count if a timeout or signal occurs after we start. > > So MSG_WAITALL can also return a short count. Only in case of a timeout or a signal, both of which are error conditions. The default behaviour for BSD prior to the introduction of siginterrupt() was to restart all system calls interrupted by signal. If the default behaviour is used, then the only possible failure would be EPIPE, indicating a timeout (loss of connection) (assuming a blocking socket). > > Maybe you should be using SOCK_SEQPACKET instead of SOCK_STREAM? > > That might be difficult. > > A SOCK_SEQPACKET socket [ .... ] is protocol specific, and presently > implemented only for PF_NS. (PF_NS == Xerox Network Systems protocols) Well, bummer deal. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 13:48:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19422 for hackers-outgoing; Fri, 15 Nov 1996 13:48:17 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA19417 for ; Fri, 15 Nov 1996 13:48:14 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id PAA17873; Fri, 15 Nov 1996 15:46:48 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id PAA03963; Fri, 15 Nov 1996 15:46:45 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id PAA10779; Fri, 15 Nov 1996 15:46:43 -0600 (CST) From: Karl Denninger Message-Id: <199611152146.PAA10779@Jupiter.Mcs.Net> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Fri, 15 Nov 1996 15:46:43 -0600 (CST) Cc: fenner@parc.xerox.com, terry@lambert.org, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611151858.LAA26626@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 11:58:51 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > No; what happens for you at the receiving end is that the packets get > > reassembled into the same *stream* of data as they were at the sender. > > The sender can buffer small writes into big chunks, or can fragment big > > writes. If the underlying MTU of the path changes, writes that didn't > > used to have to be fragmented may now have to be. Packet N can get > > lost in the network, while packets N+1, N+2, N+3 and N+4 arrive; when > > the sender retransmits packet N all of a sudden a ton of data "shows > > up" at the receiver. The receiver's job is *solely* to put those > > packets back together into the same stream as the sender sent. > > So at the "read" interface, you *can* count on it arriving in the > same sized chunks as you wrote it, as long as the order and chunk size of > your reads is identical to those of your writes... in other words, > synchronized client and server automatons. > > Right? > > IF I issue a blocking read for 1000 bytes, AND > I issue a blocking write for 1000 bytes, AND > the blocking write returns "1000", > THEN the blocking read will return 1000 bytes OR > it won't return (EPIPE after connection timeout). > > Karl is saying he has synchronized client and server automatons, but > that it's not working for large buffer sizes on the writes. No, Karl is doing this: 1) The *writer* is writing records of variable size with a prefix to indicate how many byte(s) follow. 2) The writer does this ASSUMING that all of the records will get delivered to the reader. 3) When the writer is done, he writes a "no more records follow" flag record. 4) All of those writes return with no errors. 5) The READER gets about 2700 of the records (out of 8500!) and NEVER SEES ANY MORE DATA. It hangs in read()! This does NOT happen with the 2.6.3 development kit and libraries. It RELIABLY happens with -current. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Fri Nov 15 13:56:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19785 for hackers-outgoing; Fri, 15 Nov 1996 13:56:29 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA19777 for ; Fri, 15 Nov 1996 13:56:23 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16120(2)>; Fri, 15 Nov 1996 13:55:08 PST Received: by crevenia.parc.xerox.com id <177557>; Fri, 15 Nov 1996 13:55:01 -0800 From: Bill Fenner To: fenner@parc.xerox.com, terry@lambert.org Subject: Re: Sockets question... Cc: hackers@freebsd.org, jdp@polstra.com, scrappy@ki.net Message-Id: <96Nov15.135501pst.177557@crevenia.parc.xerox.com> Date: Fri, 15 Nov 1996 13:54:58 PST Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry: >Bill: > Terry: >> >So at the "read" interface, you *can* count on it arriving in the >> >same sized chunks as you wrote it >> >> No, you can *never* count on that, since non-blocking reads from a stream >> socket return as much data as is available, which could be less than you >> asked for. See soo_read() (or soo_rw() in earlier BSD's) and soreceive(). > >By default, the sockets are blocking. You have to go out of your >way to make them non-blocking (ie: loading the gun before you can shoot >yourself in the foot). Terry, STOP SPECULATING. Look at the code. soo_read() is what is called by the read system call, and it calls soreceive(). soreceive() returns whatever is waiting, up to what is requested, unless you set MSG_WAITALL. soo_read() doesn't set MSG_WAITALL, so the semantics of read() on a blocking socket is to return as much data is waiting, up to the amount that was requested. >But on a blocking socket, it doesn't make sense to have to issue multiple >system calls to read chunks of a whole message when you aren't going to >do anything with it until all the reads have been satisfied? The CSRG apparently felt otherwise. Bill From owner-freebsd-hackers Fri Nov 15 14:01:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA20037 for hackers-outgoing; Fri, 15 Nov 1996 14:01:37 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA20030 for ; Fri, 15 Nov 1996 14:01:33 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA02622 for ; Fri, 15 Nov 1996 14:01:32 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16630(4)>; Fri, 15 Nov 1996 13:59:09 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Fri, 15 Nov 1996 13:59:02 -0800 To: Karl Denninger cc: terry@lambert.org (Terry Lambert), fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Fri, 15 Nov 96 13:46:43 PST." <199611152146.PAA10779@Jupiter.Mcs.Net> Date: Fri, 15 Nov 1996 13:58:48 PST From: Bill Fenner Message-Id: <96Nov15.135902pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611152146.PAA10779@Jupiter.Mcs.Net> Karl wrote: >This does NOT happen with the 2.6.3 development kit and libraries. It >RELIABLY happens with -current. This points clearly at: a) incorrect code, compiled one way by 2.6.3 and differently by 2.7.2 b) a compiler bug. We should all stop arguing about SOCK_STREAM semantics. Bill From owner-freebsd-hackers Fri Nov 15 14:05:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA20298 for hackers-outgoing; Fri, 15 Nov 1996 14:05:30 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA20291 for ; Fri, 15 Nov 1996 14:05:23 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA02629 for ; Fri, 15 Nov 1996 14:05:12 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16531(3)>; Fri, 15 Nov 1996 14:02:43 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177557>; Fri, 15 Nov 1996 14:02:32 -0800 X-Mailer: exmh version 1.6.7 5/3/96 To: Terry Lambert cc: jgreco@brasil.moneng.mei.com (Joe Greco), jdp@polstra.com, scrappy@ki.net, hackers@freebsd.org Subject: Re: Sockets question... In-reply-to: Your message of "Fri, 15 Nov 1996 09:48:35 PST." <199611151748.KAA26388@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Nov 1996 14:02:30 PST From: Bill Fenner Message-Id: <96Nov15.140232pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611151748.KAA26388@phaeton.artisoft.com> Terry wrote: >[long quote from socket man page] > >If you want to get technical, according to this description, if you are >using a SOCK_STREAM, then a read on a blocking socket will act like a >recv(2) or recvfrom(2) with flags MSG_WAITALL by default. That's a wild thing to get from that description. What I can get from that description is: - data is not lost or duplicated. - the connection is broken if data cannot be transmitted. - the connection can be optionally send keepalives in the absence of data. - an error is indicated if the keepalive fails. - SIGPIPE means you wrote on a closed socket. What part talks about how a blocking read works? >Maybe you should be using SOCK_SEQPACKET instead of SOCK_STREAM? There is no mapping from SOCK_SEQPACKET to an IP protocol. Maybe there will be if the IETF standardizes SFRP , but there is not today. Bill From owner-freebsd-hackers Fri Nov 15 14:09:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA20604 for hackers-outgoing; Fri, 15 Nov 1996 14:09:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA20588 for ; Fri, 15 Nov 1996 14:09:32 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA27106; Fri, 15 Nov 1996 14:55:30 -0700 From: Terry Lambert Message-Id: <199611152155.OAA27106@phaeton.artisoft.com> Subject: Re: Sockets question... To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 14:55:30 -0700 (MST) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org In-Reply-To: <199611152014.OAA28769@brasil.moneng.mei.com> from "Joe Greco" at Nov 15, 96 02:14:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > If I want to do a > > write(fd, buf, 1048576) > > on a socket connected via a 9600 baud SLIP link, I might expect the system > call to take around 1092 seconds. If I have a server process dealing with > two such sockets, response time will be butt slow if the server is > currently writing to the other socket... it has to wait for the write to > complete because write(2) has to finish sending the entire 1048576 bytes. Actually, write will return when the data has been copied into the local transmit buffers, not when it has actually been sent. It's only when you run out of local transmit buffers that the write blocks. And well it should: something needs to tell the server process to quit making calls which the kernel is unable to satisfy. Halting the server process based on resource unavailability does this. > So a clever software author does not do this. He has 1048576 bytes of > (different, even) data that he wants to write "simultaneously" to two > sockets. He wants to do the equivalent of Sun's > > aiowrite(fd1, buf1, 1048576, SEEK_CUR, 0, NULL); > aiowrite(fd2, buf2, 1048576, SEEK_CUR, 0, NULL); Yes. This is *exactly* what he wants to do. > Well how the hell do you do THAT if you are busy blocked in a write call? He uses a native aiowrite(). Or he wants to call a write from a thread dedicated to that client, which may block the thread, but not the process, and therefore not other writes. The underlying implementation may use non-blocking I/O, or it may use an OS implementation of aiowrote (like Sun's SunOS 4.3 LWP user space threads library provided). It doesn't matter. That's the point of using threads. > Well, you use non-blocking I/O... and you take advantage of the fact that > the OS is capable of buffering some data on your behalf. > > Let's say you have "buf1" and "buf2" to write to "fd1" and "fd2", and "len1" > and "len2" for the size of the corresponding buf's. > > You write code to do the following: > > rval = write(fd1, buf1, len1) # Wrote 2K of data > len1 -= rval; # 1046528 bytes remain > buf1 += rval; # Move forward 2K in buffer [ ... ] > You can trivially do this with a moderately complex select() mechanism, > so that the outbound buffers for both sockets are kept filled. This is exactly the finite state automaton I was talking about having to move into user space code in order to use the interface. It makes things more complex for the user space programmer. > A little hard to do without nonblocking sockets. Very useful. I don't > think that this is a "stupid idea" at all. Maybe not compared to being unable to do it at all... but BSD is not limited this way. We have threads. > > What is the point of a non-blocking write if this is what happens? > > I will leave that as your homework for tonite. Answer: for writes in a multiple client server. Extra credit: the failure case that originated this discussion was concerned with a client using read. > Please tell that to FreeBSD's FTP server, which uses a single (blocking) > write to perform delivery of data. > > Why should an application developer have to know or care what the available > buffer space is? Please tell me where in write(2) and read(2) it says I > must worry about this. > > It doesn't. Exactly my point on a socket read not returning until it completes. > > Indeterminate sockets are evil. They are on the order of not knowing > > your lock state when entering into a function that's going to need > > the lock held. > > I suppose you have never written a library function. > > I suppose you do not subscribe to the philosophy that you should be > liberal in what you accept (in this case, assume that you may need to > deal with either type of socket). If I wrote a library function which operated on a nonu user-opaque object like a socket set up by the user, then it would function for all potential valid states in which that object could be at the time of the call. For potential invalid states, I would trap the ones which I could identify from subfunction returns, and state that the behaviour for other invalid states was "undefined" in the documentation which I published with the library (ie: optimise for the success case). More likely, I would encapsulate the object using an opaque data type, and I would expect the users who wish to consume my interface to obtain an object of that type, operate on the object with my functions, and release the object when done. In other words, I would employ standard data encapsulation techniques. > I wonder if anyone has ever rewritten one of your programs, and made > a fundamental change that silently broke one of your programs because > an underlying concept was changed. Unlikely. I document my assumptions. > Any software author who writes code and does not perform reasonable > sanity checks on the return value, particularly for something as important > as the read and write system calls, is hanging a big sign around their > neck saying "Kick Me I Code Worth Shit". On the other hand, "do not test for an error condition which you can not handle". If as part of my rundown in a program, I go to close a file, and the close fails, what should I do about it? Not exit? Give me a break... > > It bothers me too... I am used to formatting my IPC data streams. I > > either use fixed length data units so that the receiver can post a > > fixed size read, or I use a fix length data unit, and guarantee write > > ordering by maintaining state. I do this in order to send a fixed > > length header to indicate that I'm writing a variable length packet, > > so the receiver can then issue a blocking read for the right size. > > I have never seen that work as expected with a large data size. I have never seen *any* IPC transport work (reliably) with large data sizes... depending on your definition of large. To deal with this, you can only encapsulate the transport and handle them, or don't use large data sizes in the first place. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 14:17:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21114 for hackers-outgoing; Fri, 15 Nov 1996 14:17:44 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21107 for ; Fri, 15 Nov 1996 14:17:39 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA27125; Fri, 15 Nov 1996 15:04:32 -0700 From: Terry Lambert Message-Id: <199611152204.PAA27125@phaeton.artisoft.com> Subject: Re: Sockets question... To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 15:04:32 -0700 (MST) Cc: fenner@parc.xerox.com, jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <199611152059.OAA28943@brasil.moneng.mei.com> from "Joe Greco" at Nov 15, 96 02:59:34 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Ummm... and the problem is...? > > As far as I am aware, byte oriented data can be written to unaligned > addresses on any UNIX architecture that I have seen. It's not efficient. It may take multiple bus cycles each time you break for more data making it not-as-fast-as-it-could-be. It is ugly and inelegant. It offends our aesthetics. > xread is explicitly called with what is clearly a byte oriented buffer. You could make the same arguments about bcopy, but we've optimized it for alignment boundries anyway. > If you are possibly worried about something such as the atomicity of > reads (potentially valid in a threaded environment, or one using shared > memory), I agree that there may be some concern. Since it is not clear > to _me_ that such atomicity of access would be valid under the same > circumstances even with read(), I would probably code around the > situation anyways. > > Is there some other problem that I am missing? I've done this sort of > things for several years now... Non-shared memory, but using a mmap'ed region as the destination buffer. In this case, I want to validate the target address range once and copy direct out of the frag buffers into the user buffer. I can make similar arguments about write's of a mmap'ed region. I believe that an FTP server sending files to a client would qualify, after the initial descriptor header is sent, and the only thing left to send is the file data. Further, if tthe kernel detected this happening, it could asynchronusly complete, and delay the unmapping until the transmit was complete, tunring almost the entire transaction around in kernel space. The same thing goes for whole file downloads (ie: .EXE, .DLL, etc.) for DOS clients of a UNIX server. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 14:21:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21393 for hackers-outgoing; Fri, 15 Nov 1996 14:21:03 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21384 for ; Fri, 15 Nov 1996 14:20:58 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id OAA06145; Fri, 15 Nov 1996 14:19:37 -0800 (PST) To: Mike Haertel cc: hackers@FreeBSD.org Subject: Re: earlier "holographic shell" in 2.2-ALPHA install procedure In-reply-to: Your message of "Fri, 15 Nov 1996 13:04:52 PST." <199611152104.NAA09906@incognito.intel.com> Date: Fri, 15 Nov 1996 14:19:37 -0800 Message-ID: <6143.848096377@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I would like the ability to launch the "emergency > holographic shell" earlier in the install process, So would I. :-) Unfortunately, if you do that before the chroot is done then it's impossible to unmount the floppy and use the drive again for fixit or floppy installation. The EHS is started just as soon as it's possible for me to start it, I'm afraid. Jordan From owner-freebsd-hackers Fri Nov 15 14:22:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21506 for hackers-outgoing; Fri, 15 Nov 1996 14:22:28 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21501 for ; Fri, 15 Nov 1996 14:22:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA27168; Fri, 15 Nov 1996 15:10:53 -0700 From: Terry Lambert Message-Id: <199611152210.PAA27168@phaeton.artisoft.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 15:10:53 -0700 (MST) Cc: fenner@parc.xerox.com, terry@lambert.org, hackers@freebsd.org, jdp@polstra.com, scrappy@ki.net In-Reply-To: <96Nov15.135501pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 01:54:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >But on a blocking socket, it doesn't make sense to have to issue multiple > >system calls to read chunks of a whole message when you aren't going to > >do anything with it until all the reads have been satisfied? > > The CSRG apparently felt otherwise. They didn't have threads or aioread. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 14:24:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21651 for hackers-outgoing; Fri, 15 Nov 1996 14:24:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21611 for ; Fri, 15 Nov 1996 14:24:00 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA27148; Fri, 15 Nov 1996 15:09:53 -0700 From: Terry Lambert Message-Id: <199611152209.PAA27148@phaeton.artisoft.com> Subject: Re: Sockets question... To: karl@Mcs.Net (Karl Denninger) Date: Fri, 15 Nov 1996 15:09:53 -0700 (MST) Cc: terry@lambert.org, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611152146.PAA10779@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 15, 96 03:46:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > No, Karl is doing this: > > 1) The *writer* is writing records of variable size with a prefix to > indicate how many byte(s) follow. > > 2) The writer does this ASSUMING that all of the records will get > delivered to the reader. > > 3) When the writer is done, he writes a "no more records follow" > flag record. > > 4) All of those writes return with no errors. > > 5) The READER gets about 2700 of the records (out of 8500!) and NEVER > SEES ANY MORE DATA. It hangs in read()! > > This does NOT happen with the 2.6.3 development kit and libraries. It > RELIABLY happens with -current. Is the data in #1 getting to the wire? Who is losing the data, the writer or the reader? If the reader, is it because of a buffer overflow? If so, is the reader acking for packets it does not agregate into the processes read buffer, or is the writer pretending he got ack's? What if the reader is 2.6.3 and the writer is -current? What if the situation is reversed? We need to localize the problem to the client or the server (if possible), and then localize the problem further to the kernel interface at which it is occurring. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 14:26:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21875 for hackers-outgoing; Fri, 15 Nov 1996 14:26:12 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21866 for ; Fri, 15 Nov 1996 14:26:07 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id QAA19565; Fri, 15 Nov 1996 16:24:35 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id QAA12532; Fri, 15 Nov 1996 16:24:30 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id QAA11694; Fri, 15 Nov 1996 16:24:15 -0600 (CST) From: Karl Denninger Message-Id: <199611152224.QAA11694@Jupiter.Mcs.Net> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Fri, 15 Nov 1996 16:24:14 -0600 (CST) Cc: karl@Mcs.Net, terry@lambert.org, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611152209.PAA27148@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 03:09:53 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > No, Karl is doing this: > > > > 1) The *writer* is writing records of variable size with a prefix to > > indicate how many byte(s) follow. > > > > 2) The writer does this ASSUMING that all of the records will get > > delivered to the reader. > > > > 3) When the writer is done, he writes a "no more records follow" > > flag record. > > > > 4) All of those writes return with no errors. > > > > 5) The READER gets about 2700 of the records (out of 8500!) and NEVER > > SEES ANY MORE DATA. It hangs in read()! > > > > This does NOT happen with the 2.6.3 development kit and libraries. It > > RELIABLY happens with -current. > > Is the data in #1 getting to the wire? It happens with the local host on both sides (ie: connect back to the local hostname, in which case the wire isn't involved). > Who is losing the data, the writer or the reader? The writer; the reader never gets the data. > If the reader, is it because of a buffer overflow? The reader never sees it, and its NOT in the mbuf clusters (netstat -an shows nothing outstanding and the socket in a connected state for both sides). > If so, is the reader acking for packets it does not agregate into the > processes read buffer, or is the writer pretending he got ack's? See above; the writer never gets ACKs back (he only expects one at the end of the stream, and since the reader never sees the end record he never sends the ACK). > What if the reader is 2.6.3 and the writer is -current? You're dead. The writer is the one which is important; the reader is not. > What if the situation is reversed? See above. > We need to localize the problem to the client or the server (if possible), > and then localize the problem further to the kernel interface at which > it is occurring. > > Terry Lambert > terry@lambert.org Its on the writing end. Leaving all else alone and recompiling the writer with 2.7.x breaks, 2.6.3 works. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Fri Nov 15 14:48:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA23377 for hackers-outgoing; Fri, 15 Nov 1996 14:48:13 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA23370 for ; Fri, 15 Nov 1996 14:48:08 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id RAA02001; Fri, 15 Nov 1996 17:46:12 -0500 (EST) From: "John S. Dyson" Message-Id: <199611152246.RAA02001@dyson.iquest.net> Subject: Re: Sockets question... To: karl@Mcs.Net (Karl Denninger) Date: Fri, 15 Nov 1996 17:46:12 -0500 (EST) Cc: terry@lambert.org, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611152146.PAA10779@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 15, 96 03:46:43 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > No, Karl is doing this: > > 1) The *writer* is writing records of variable size with a prefix to > indicate how many byte(s) follow. > > 2) The writer does this ASSUMING that all of the records will get > delivered to the reader. > > 3) When the writer is done, he writes a "no more records follow" > flag record. > > 4) All of those writes return with no errors. > > 5) The READER gets about 2700 of the records (out of 8500!) and NEVER > SEES ANY MORE DATA. It hangs in read()! > > This does NOT happen with the 2.6.3 development kit and libraries. It > RELIABLY happens with -current. > I guess that Karl is the authority on what Karl is doing :-). This helps put some guessing to rest... Levity aside, Karl, what is the process state for the process that is hanging in read()? This might give the networking people a hint as to where the missing/broken spl or lock is occuring... John From owner-freebsd-hackers Fri Nov 15 14:48:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA23393 for hackers-outgoing; Fri, 15 Nov 1996 14:48:18 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA23384 for ; Fri, 15 Nov 1996 14:48:14 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id RAA02009; Fri, 15 Nov 1996 17:46:58 -0500 (EST) From: "John S. Dyson" Message-Id: <199611152246.RAA02009@dyson.iquest.net> Subject: Re: Sockets question... To: karl@Mcs.Net (Karl Denninger) Date: Fri, 15 Nov 1996 17:46:58 -0500 (EST) Cc: terry@lambert.org, karl@Mcs.Net, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611152224.QAA11694@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 15, 96 04:24:14 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Its on the writing end. Leaving all else alone and recompiling the writer > with 2.7.x breaks, 2.6.3 works. > Ohhh.... cancel my last request for info about read()!!!! John From owner-freebsd-hackers Fri Nov 15 15:01:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24204 for hackers-outgoing; Fri, 15 Nov 1996 15:01:38 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA24194 for ; Fri, 15 Nov 1996 15:01:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA01657; Fri, 15 Nov 1996 15:48:20 -0700 From: Terry Lambert Message-Id: <199611152248.PAA01657@phaeton.artisoft.com> Subject: Re: Sockets question... To: karl@Mcs.Net (Karl Denninger) Date: Fri, 15 Nov 1996 15:48:20 -0700 (MST) Cc: terry@lambert.org, karl@Mcs.Net, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611152224.QAA11694@Jupiter.Mcs.Net> from "Karl Denninger" at Nov 15, 96 04:24:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > This does NOT happen with the 2.6.3 development kit and libraries. It > > > RELIABLY happens with -current. Ugh. This line was singularly unclear; "2.6.3 vs. -current". > Its on the writing end. Leaving all else alone and recompiling the writer > with 2.7.x breaks, 2.6.3 works. So it's the complier change that bit you. What optimization flags, etc., are you using? I would suggest turning off all optimization, and see if that fixes it. o If it does, isolate the offending code, file-by-file, by turning on optimization one file at a time. You may get bit more than onces, so you should iterate this process once you find one file, and back it out. This process will, if you go for half the remaining code at a time, take you log2(N) * M complies for N files and M places you get bitten. 8-(. o If it doesn't, then it is a generic problem in the code generator or a semantic change in an asm statement somewhere. You will need to mix and match compilers, with the same effects. I would suggest using two compilation directories and sapping the time dependencies to let you copy objects back and forth and link. Then it's cc -S time, and diff the -S files. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 15:04:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA24436 for hackers-outgoing; Fri, 15 Nov 1996 15:04:30 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA24431 for ; Fri, 15 Nov 1996 15:04:23 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA29354; Fri, 15 Nov 1996 17:00:53 -0600 From: Joe Greco Message-Id: <199611152300.RAA29354@brasil.moneng.mei.com> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Fri, 15 Nov 1996 17:00:53 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org In-Reply-To: <199611152155.OAA27106@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 02:55:30 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > If I want to do a > > > > write(fd, buf, 1048576) > > > > on a socket connected via a 9600 baud SLIP link, I might expect the system > > call to take around 1092 seconds. If I have a server process dealing with > > two such sockets, response time will be butt slow if the server is > > currently writing to the other socket... it has to wait for the write to > > complete because write(2) has to finish sending the entire 1048576 bytes. > > Actually, write will return when the data has been copied into the > local transmit buffers, not when it has actually been sent. It's > only when you run out of local transmit buffers that the write blocks. Yes, that should be clear, I made it clear that this is precisely what allows non-blocking sockets to be useful in this scenario. > And well it should: something needs to tell the server process to > quit making calls which the kernel is unable to satisfy. Halting > the server process based on resource unavailability does this. So does returning EWOULDBLOCK to the server process, allowing the server to react to this by going on to service someone else. > > So a clever software author does not do this. He has 1048576 bytes of > > (different, even) data that he wants to write "simultaneously" to two > > sockets. He wants to do the equivalent of Sun's > > > > aiowrite(fd1, buf1, 1048576, SEEK_CUR, 0, NULL); > > aiowrite(fd2, buf2, 1048576, SEEK_CUR, 0, NULL); > > Yes. This is *exactly* what he wants to do. > > > Well how the hell do you do THAT if you are busy blocked in a write call? > > He uses a native aiowrite(). Which doesn't exist in a portable fashion. ANYWHERE. > Or he wants to call a write from a thread dedicated to that client, > which may block the thread, but not the process, and therefore not > other writes. Which is fine IF you have a threads implementation. Which is, again, not a given, and therefore, not portable. > The underlying implementation may use non-blocking I/O, or it may use > an OS implementation of aiowrote (like Sun's SunOS 4.3 LWP user space > threads library provided). It doesn't matter. That's the point of > using threads. Yes, well, the point of using threads is currently that you're not really assured of being portable. I do not disagree that in an ideal world, threads are a good way to deal with this. > > Well, you use non-blocking I/O... and you take advantage of the fact that > > the OS is capable of buffering some data on your behalf. > > > > Let's say you have "buf1" and "buf2" to write to "fd1" and "fd2", and "len1" > > and "len2" for the size of the corresponding buf's. > > > > You write code to do the following: > > > > rval = write(fd1, buf1, len1) # Wrote 2K of data > > len1 -= rval; # 1046528 bytes remain > > buf1 += rval; # Move forward 2K in buffer > [ ... ] > > You can trivially do this with a moderately complex select() mechanism, > > so that the outbound buffers for both sockets are kept filled. > > > This is exactly the finite state automaton I was talking about > having to move into user space code in order to use the interface. > > It makes things more complex for the user space programmer. So? Making things more complex is a small tradeoff if it makes it POSSIBLE to do something in the first place. Tell me, how else do you do this on a system that does NOT support threads? You can select() on writability and send one byte at a time on a blocking socket until select() reports no further writability. Poor solution. > > A little hard to do without nonblocking sockets. Very useful. I don't > > think that this is a "stupid idea" at all. > > Maybe not compared to being unable to do it at all... but BSD is not > limited this way. We have threads. _FREE_BSD is not limited this way. _FREE_BSD has threads. The local 4.3BSD Tahoe system (it _is_ a BSD system, I hope you would agree) offers nonblocking writes but does not offer threads. Ultrix does not offer threads. I am sure there are other examples... You are missing the point as usual. BSD != FreeBSD, and FreeBSD != UNIX in general. I am continually amazed that someone like you could make that error... In order to write portable code, one must write portable code. > > > What is the point of a non-blocking write if this is what happens? > > > > I will leave that as your homework for tonite. > > Answer: for writes in a multiple client server. Ahhhh. You got it. > Extra credit: the failure case that originated this discussion was > concerned with a client using read. That is not very relevant. The statement which originated _THIS_ discussion was your assertion that "Non-blocking sockets for reliable stream protocols like TCP/IP are a stupid idea." I do not care about Karl's problem... he may well have a legitimate problem, and I agreed that it was probably beyond the scope of a usage discussion given his description. I do not care about Marc's problem... that is a separate issue. I am simply correcting a misconception that you are spreading that non-blocking sockets are a "stupid idea". > > Please tell that to FreeBSD's FTP server, which uses a single (blocking) > > write to perform delivery of data. > > > > Why should an application developer have to know or care what the available > > buffer space is? Please tell me where in write(2) and read(2) it says I > > must worry about this. > > > > It doesn't. > > Exactly my point on a socket read not returning until it completes. Yes, that's fine. I agree that there are merits on both sides. The read() returning what is available is probably more generally useful, and that seems to be what is implemented. I am not going to argue with the design and implementation of the Berkeley networking code, since it is widely considered to be the standard model for networking. Most other folks have not found this to be a critical design flaw, and neither do I. I can see several cases where a blocking read() call would be a substantial nuisance, and so I think that the behaviour as it exists makes a fair amount of sense. > > > Indeterminate sockets are evil. They are on the order of not knowing > > > your lock state when entering into a function that's going to need > > > the lock held. > > > > I suppose you have never written a library function. > > > > I suppose you do not subscribe to the philosophy that you should be > > liberal in what you accept (in this case, assume that you may need to > > deal with either type of socket). > > If I wrote a library function which operated on a nonu user-opaque > object like a socket set up by the user, then it would function for > all potential valid states in which that object could be at the time > of the call. For potential invalid states, I would trap the ones > which I could identify from subfunction returns, and state that the > behaviour for other invalid states was "undefined" in the documentation > which I published with the library (ie: optimise for the success case). What do you define "potential valid states" to be? I do not claim to cover all the bases all the time, but I do at least catch exceptional conditions I was not expecting. In my case, I would try to write a socket-handling library function to handle both blocking and non-blocking sockets if it was reasonably practical to do so. If not, I would cause it to bomb if it detected something odd. I think you are saying the same thing: that is good. > More likely, I would encapsulate the object using an opaque data > type, and I would expect the users who wish to consume my interface > to obtain an object of that type, operate on the object with my > functions, and release the object when done. In other words, I > would employ standard data encapsulation techniques. Nifty. That's even possible in many cases if you are designing from scratch. Otherwise, it is a real pain in the butt. > > I wonder if anyone has ever rewritten one of your programs, and made > > a fundamental change that silently broke one of your programs because > > an underlying concept was changed. > > Unlikely. I document my assumptions. So what? If I, as the engineer who replaces you five years down the road, decide that your program needs to use non-blocking writes, and I change the program to do them, and I miss one place where you failed to check a return value, your "documented assumptions" are worth diddly squat. Code your assumptions when they are this trivial to check. > > Any software author who writes code and does not perform reasonable > > sanity checks on the return value, particularly for something as important > > as the read and write system calls, is hanging a big sign around their > > neck saying "Kick Me I Code Worth Shit". > > On the other hand, "do not test for an error condition which you can > not handle". One can handle ANY error condition by bringing it to the attention of a higher authority. My UNIX kernel panicks when it hits a condition that it does not know how to handle. It does not foolishly take your advice and "do not test for an error condition which you can not handle". To do so would risk great havoc. You ALWAYS test for error conditions, PARTICULARLY the ones which you can not handle - because they are the really scary ones. > If as part of my rundown in a program, I go to close a file, and the > close fails, what should I do about it? Not exit? Give me a break... No, but if a close() fails, and you had a reasonable expectation for it to succeed, printing a warning is not unreasonable. According to SunOS, there are two reasons this could happen: EBADF and EINTR. If you are closing an inactive descriptor, it is clearly an error in the code, and I WOULD CERTAINLY WANT TO KNOW. If it is due to a signal, it is unclear what to do, but it is certainly not a "bad" idea to at least be aware that such a thing can (and has) happened! > > > It bothers me too... I am used to formatting my IPC data streams. I > > > either use fixed length data units so that the receiver can post a > > > fixed size read, or I use a fix length data unit, and guarantee write > > > ordering by maintaining state. I do this in order to send a fixed > > > length header to indicate that I'm writing a variable length packet, > > > so the receiver can then issue a blocking read for the right size. > > > > I have never seen that work as expected with a large data size. > > I have never seen *any* IPC transport work (reliably) with large data > sizes... depending on your definition of large. To deal with this, > you can only encapsulate the transport and handle them, or don't use > large data sizes in the first place. Okay, here we are in complete agreement. One _always_ needs to be aware of this, then. ... JG From owner-freebsd-hackers Fri Nov 15 15:23:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA25859 for hackers-outgoing; Fri, 15 Nov 1996 15:23:04 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA25850 for ; Fri, 15 Nov 1996 15:23:01 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA29400; Fri, 15 Nov 1996 17:06:28 -0600 From: Joe Greco Message-Id: <199611152306.RAA29400@brasil.moneng.mei.com> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Fri, 15 Nov 1996 17:06:28 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, fenner@parc.xerox.com, hackers@freebsd.org In-Reply-To: <199611152204.PAA27125@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 03:04:32 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Ummm... and the problem is...? > > > > As far as I am aware, byte oriented data can be written to unaligned > > addresses on any UNIX architecture that I have seen. > > It's not efficient. It may take multiple bus cycles each time you > break for more data making it not-as-fast-as-it-could-be. It is ugly > and inelegant. It offends our aesthetics. Tough doodles. It is a fact of life. However, as it is the unusual case, it is probably not a real big performance deal. > > xread is explicitly called with what is clearly a byte oriented buffer. > > You could make the same arguments about bcopy, but we've optimized > it for alignment boundries anyway. Yeah... which has what to do with what? > > If you are possibly worried about something such as the atomicity of > > reads (potentially valid in a threaded environment, or one using shared > > memory), I agree that there may be some concern. Since it is not clear > > to _me_ that such atomicity of access would be valid under the same > > circumstances even with read(), I would probably code around the > > situation anyways. > > > > Is there some other problem that I am missing? I've done this sort of > > things for several years now... > > Non-shared memory, but using a mmap'ed region as the destination buffer. > In this case, I want to validate the target address range once and > copy direct out of the frag buffers into the user buffer. And you can't, because you may have to perform multiple read() calls, is that your objection? I guess I don't really see how that is a major earth shaking crisis. Well, fine, go fix it. While you are at it, break FreeBSD's BSD compatibility. > I can make similar arguments about write's of a mmap'ed region. > > I believe that an FTP server sending files to a client would qualify, > after the initial descriptor header is sent, and the only thing left > to send is the file data. Yes. So use a blocking socket, and arrange not to be disturbed by signals, and I think you are probably in pretty good shape. > Further, if tthe kernel detected this happening, it could asynchronusly > complete, and delay the unmapping until the transmit was complete, > tunring almost the entire transaction around in kernel space. > > The same thing goes for whole file downloads (ie: .EXE, .DLL, etc.) > for DOS clients of a UNIX server. Point being? ... JG From owner-freebsd-hackers Fri Nov 15 15:27:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26261 for hackers-outgoing; Fri, 15 Nov 1996 15:27:33 -0800 (PST) Received: from cher (cher.vnet.net [166.82.1.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA26250 for ; Fri, 15 Nov 1996 15:27:30 -0800 (PST) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by cher (8.8.2/8.8.0) with ESMTP id SAA04002 for ; Fri, 15 Nov 1996 18:27:41 -0500 (EST) Received: from artist.vnet.net (artist.vnet.net [166.82.239.40]) by elvis.vnet.net (8.8.2/8.8.2) with SMTP id SAA23260 for ; Fri, 15 Nov 1996 18:27:19 -0500 (EST) Message-ID: X-Mailer: XFMail 0.4 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 15 Nov 1996 18:15:59 -0500 (EST) From: Edwin Burley To: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk ---------------------------------- E-Mail: khan@vnet.net Date: 11/15/96 Time: 18:15:59 ---------------------------------- I have placed two new program called confkernel and bkidemaker... in freebsd.org /pub/incoming.... what it is ...is programs that help make the script for freebsd kernel... the bkidemaker is made for generic ide system... just download in a temp dir and run it.... have fun and see if it helps... be nice on the feed-back and it is the first piece I have placed on the net... From owner-freebsd-hackers Fri Nov 15 15:29:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26514 for hackers-outgoing; Fri, 15 Nov 1996 15:29:43 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA26508 for ; Fri, 15 Nov 1996 15:29:41 -0800 (PST) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id SAA10396 for ; Fri, 15 Nov 1996 18:29:51 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.8.2/11-10-96) with SMTP id SAA726043; Fri, 15 Nov 1996 18:29:31 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA32475; Fri, 15 Nov 1996 18:29:30 -0500 Date: Fri, 15 Nov 1996 18:29:30 -0500 From: kavitha Message-Id: <9611152329.AA32475@hawpub1.watson.ibm.com> To: hackers@freebsd.org Subject: missing libraries Cc: kavitha@watson.ibm.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I have FreeBSD 2.1.5 on my thinkpad. By mistake I deleted /usr/lib/libc.a & /usr/lib/libc.so.2.2. Now I'm not able to login, ftp or telnet to this machine. I have a backup of these libraries on some other machine. Can anybody tell me how I can install these libraries back and save my disk? Thanks in Advance Regards kavitha From owner-freebsd-hackers Fri Nov 15 16:36:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA29840 for hackers-outgoing; Fri, 15 Nov 1996 16:36:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA29835 for ; Fri, 15 Nov 1996 16:36:21 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA01874; Fri, 15 Nov 1996 17:22:27 -0700 From: Terry Lambert Message-Id: <199611160022.RAA01874@phaeton.artisoft.com> Subject: Re: Sockets question... To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Fri, 15 Nov 1996 17:22:27 -0700 (MST) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, jdp@polstra.com, scrappy@ki.net, hackers@FreeBSD.org In-Reply-To: <199611152300.RAA29354@brasil.moneng.mei.com> from "Joe Greco" at Nov 15, 96 05:00:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > He uses a native aiowrite(). > > Which doesn't exist in a portable fashion. ANYWHERE. [ ... ] > Which is fine IF you have a threads implementation. Which is, again, not > a given, and therefore, not portable. Well, maybe he should be using send(2) instead of write(2). > So? Making things more complex is a small tradeoff if it makes it POSSIBLE > to do something in the first place. > > Tell me, how else do you do this on a system that does NOT support threads? I port sigsched. > You can select() on writability and send one byte at a time on a blocking > socket until select() reports no further writability. Poor solution. Or you can use send(2), whose semantics aren't required to match those of write(2). > I am simply correcting a misconception that you are spreading that > non-blocking sockets are a "stupid idea". Maybe I should correct it to be "a stupid idea in conjunction with write(2)". > I am not going to argue with the design and implementation of the Berkeley > networking code, since it is widely considered to be the standard model > for networking. Most other folks have not found this to be a critical > design flaw, and neither do I. I can see several cases where a blocking > read() call would be a substantial nuisance, and so I think that the > behaviour as it exists makes a fair amount of sense. So use recv(2), whose semantics are not required to match those of read(2). > > If I wrote a library function which operated on a nonu user-opaque > > object like a socket set up by the user, then it would function for > > all potential valid states in which that object could be at the time > > of the call. For potential invalid states, I would trap the ones > > which I could identify from subfunction returns, and state that the > > behaviour for other invalid states was "undefined" in the documentation > > which I published with the library (ie: optimise for the success case). > > What do you define "potential valid states" to be? Object (in this case, file descriptor) states which I claim to support with the routine. > I do not claim to cover all the bases all the time, but I do at least > catch exceptional conditions I was not expecting. In my case, I would > try to write a socket-handling library function to handle both blocking > and non-blocking sockets if it was reasonably practical to do so. If > not, I would cause it to bomb if it detected something odd. > > I think you are saying the same thing: that is good. Yes, I'm saying the same thing. > My UNIX kernel panicks when it hits a condition that it does not know how > to handle. It does not foolishly take your advice and "do not test for > an error condition which you can not handle". To do so would risk great > havoc. You ALWAYS test for error conditions, PARTICULARLY the ones which > you can not handle - because they are the really scary ones. This is a different issue than a user program. A UNIX kernel can not "fail gracefully to caller"; a program can. A UNIX kernel should be engineered such that it is impossible to cause a state transition into a failure state in the first place. That's my whole FS layering argument in a nutshell. It applies equally well to all other potential failure cases, with the sole exception of a hardware failure (the only valid panic case outside a developement environment, where panic is a runtime check for code that is being tested). As far as adulterating expected behaviour: if I read from a serial port (which is at least as likely to have partial data available as a socket), the read does not complete until the requested data has been read or an error condition or external event (signal) intervenes. If you want to adulterate this as a default, call your function recv instead. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 16:39:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA00143 for hackers-outgoing; Fri, 15 Nov 1996 16:39:04 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA00132 for ; Fri, 15 Nov 1996 16:39:03 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.7.6/8.7.3) with SMTP id QAA16182 for ; Fri, 15 Nov 1996 16:38:57 -0800 (PST) Date: Fri, 15 Nov 1996 16:38:56 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org Subject: IRQ sharing on PCI? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Do we support this? I noticed on 1 of my boxes when I rebooted it the following: tible display device> rev 76 int a irq 11 on pci0:8 de0 rev 18 int a irq 11 on pci0:9 de0: DC21140 [10-100Mb/s] pass 1.2 Ethernet address 00:00:c0:4b:10:ed de0: enabling 10baseT UTP port ahc0 rev 0 int a irq 11 on pci0:11 Notice that they're all IRQ11, which I thought seemed odd. None of my other Pentiums do it, they all get different IRQ's. Anyway, any idea appreciated, I suppose it's entirely possible that it's just a reporting problem, as opposed to anything actually wrong. From owner-freebsd-hackers Fri Nov 15 16:39:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA00218 for hackers-outgoing; Fri, 15 Nov 1996 16:39:41 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA00213 for ; Fri, 15 Nov 1996 16:39:39 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id QAA08696; Fri, 15 Nov 1996 16:37:23 -0800 (PST) Message-ID: <328D0CC1.41C67EA6@whistle.com> Date: Fri, 15 Nov 1996 16:37:21 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: kavitha CC: hackers@freebsd.org Subject: Re: missing libraries References: <9611152329.AA32475@hawpub1.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk kavitha wrote: > > Hello, > > I have FreeBSD 2.1.5 on my thinkpad. By mistake I deleted > /usr/lib/libc.a & /usr/lib/libc.so.2.2. Now I'm not able to login, > ftp or telnet to this machine. > > I have a backup of these libraries on some other machine. > > Can anybody tell me how I can install these libraries back and save my disk? > > Thanks in Advance > Regards > kavitha boot: -s fsck -p mount /usr then you have several options: 1/ tar xvf /dev/rfd0 (from floppy) if you still have /stand (always a good move) cd /stand ifconfig up your interface ./ftp otherhost get /usr/lib/libxxxxx quit reboot From owner-freebsd-hackers Fri Nov 15 16:45:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA00472 for hackers-outgoing; Fri, 15 Nov 1996 16:45:20 -0800 (PST) Received: from monk.via.net (monk.via.net [140.174.204.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA00466 for ; Fri, 15 Nov 1996 16:45:16 -0800 (PST) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id QAA27913 for hackers@FreeBSD.org; Fri, 15 Nov 1996 16:44:55 -0800 Date: Fri, 15 Nov 1996 16:44:55 -0800 From: Joe McGuckin Message-Id: <199611160044.QAA27913@monk.via.net> To: hackers@FreeBSD.org Subject: XFREE on TI Extensa 565? X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to get XFREE configured without much luck. Has anyone out there gotten it to work? Thanks, joe joe@via.net From owner-freebsd-hackers Fri Nov 15 19:04:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA05915 for hackers-outgoing; Fri, 15 Nov 1996 19:04:19 -0800 (PST) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA05907 for ; Fri, 15 Nov 1996 19:04:08 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id UAA07230 for freebsd-hackers@freefall.cdrom.com; Fri, 15 Nov 1996 20:04:05 -0700 (MST) From: Don Yuniskis Message-Id: <199611160304.UAA07230@seagull.rtd.com> Subject: CVS Attic... To: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Date: Fri, 15 Nov 1996 20:04:04 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings! It's my understanding that a "cvs remove " should put into the Attic subdirectory in the repository. Are there conditions when this is *not* true? (i.e. *my* removes aren't going to the Attic). I've dug through the FAQ and it, too, claims this to be the case... --don From owner-freebsd-hackers Fri Nov 15 19:20:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06336 for hackers-outgoing; Fri, 15 Nov 1996 19:20:53 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06306 for ; Fri, 15 Nov 1996 19:20:36 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA20676; Fri, 15 Nov 1996 22:20:04 -0500 Received: from lambert.org by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Nov 1996 22:20 EST Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.7.5/8.7.3) with UUCP id SAA25221 for FreeBSD.org!Hackers; Fri, 15 Nov 1996 18:57:55 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA16476; Fri, 15 Nov 1996 14:55:37 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA13105; Fri, 15 Nov 96 14:45:02 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA13060; Fri, 15 Nov 96 14:42:42 -0500 Received: from robin.mcnc.org (robin.mcnc.org [128.109.130.29]) by ncnoc.ncren.net (8.7.4/8.7.3) with SMTP id NAA02199; Fri, 15 Nov 1996 13:15:09 -0500 (EST) Received: from ns.mcnc.org by robin.mcnc.org (8.6.9/MCNC/8-10-92) id NAA12299; Fri, 15 Nov 1996 13:13:17 -0500 for Received: from stingray.mcnc.org by ns.mcnc.org (SMI-8.6/SAM 100194 13:34:37) id SAA05169; Fri, 15 Nov 1996 18:14:20 GMT Received: from sage.mcnc.org by stingray.mcnc.org (8.7.5/MCNC/8-10-92) id NAA22472; Fri, 15 Nov 1996 13:11:43 -0500 (EST) for Received: from relay6.UU.NET by sage.mcnc.org (SMI-8.6/SAM 100194 13:34:37) id SAA18677; Fri, 15 Nov 1996 18:12:31 GMT Received: from coyote.Artisoft.COM by relay6.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQbpyu22804; Fri, 15 Nov 1996 13:12:59 -0500 (EST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by coyote.Artisoft.COM (8.7.6/8.7.3) with SMTP id LAA15118; Fri, 15 Nov 1996 11:11:49 -0700 (MST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26447; Fri, 15 Nov 1996 11:00:53 -0700 Posted-Date: Fri, 15 Nov 1996 18:12:31 GMT From: Terry Lambert Message-Id: <199611151800.LAA26447@phaeton.artisoft.com> Subject: Re: Even more info on daily panics... To: ponds!ponds!rivers (Thomas David Rivers) Date: Fri, 15 Nov 1996 11:00:53 -0700 (MST) Cc: ponds!lambert.org!terry, ponds!Artisoft.COM!ponds!root.com!dg, ponds!Artisoft.COM!ponds!FreeBSD.org!Hackers, ponds!Artisoft.COM!ponds!cet.co.jp!michaelh, ponds!Artisoft.COM!ponds!rivers, ponds!Artisoft.COM!ponds!lambert.org!terry In-Reply-To: <199611150147.UAA20711@lakes.water.net> from "Thomas David Rivers" at Nov 14, 96 08:47:35 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Again, I hate to be a bearer of less-than-good news; but I've > got a kernel, with your patch installed, that still gets my panic. > > I can't explain why it did not get the panic before... (see my > other mail.) Again: You removed the unlock when you put in the printf. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 19:20:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06333 for hackers-outgoing; Fri, 15 Nov 1996 19:20:53 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06307 for ; Fri, 15 Nov 1996 19:20:37 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA20622; Fri, 15 Nov 1996 22:20:02 -0500 Received: from lambert.org by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Nov 1996 22:20 EST Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.7.5/8.7.3) with UUCP id SAA25216 for freefall.cdrom.com!freebsd-hackers; Fri, 15 Nov 1996 18:57:48 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA15605; Fri, 15 Nov 1996 14:45:10 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA13097; Fri, 15 Nov 96 14:45:01 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA13003; Fri, 15 Nov 96 14:37:06 -0500 Received: from robin.mcnc.org (robin.mcnc.org [128.109.130.29]) by ncnoc.ncren.net (8.7.4/8.7.3) with SMTP id NAA02331; Fri, 15 Nov 1996 13:28:29 -0500 (EST) Received: from ns.mcnc.org by robin.mcnc.org (8.6.9/MCNC/8-10-92) id NAA13139; Fri, 15 Nov 1996 13:26:36 -0500 for Received: from robin.mcnc.org by ns.mcnc.org (SMI-8.6/SAM 100194 13:34:37) id SAA05197; Fri, 15 Nov 1996 18:27:39 GMT Received: from ns.mcnc.org by robin.mcnc.org (8.6.9/MCNC/8-10-92) id NAA13006; Fri, 15 Nov 1996 13:24:48 -0500 for Received: from relay6.UU.NET by ns.mcnc.org (SMI-8.6/SAM 100194 13:34:37) id SAA05194; Fri, 15 Nov 1996 18:25:51 GMT Received: from coyote.Artisoft.COM by relay6.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQbpyv25294; Fri, 15 Nov 1996 13:24:40 -0500 (EST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by coyote.Artisoft.COM (8.7.6/8.7.3) with SMTP id LAA15327; Fri, 15 Nov 1996 11:22:55 -0700 (MST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26498; Fri, 15 Nov 1996 11:09:36 -0700 Posted-Date: Fri, 15 Nov 1996 18:25:51 GMT From: Terry Lambert Message-Id: <199611151809.LAA26498@phaeton.artisoft.com> Subject: Re: daily panics - the saga continues... To: ponds!ponds!rivers (Thomas David Rivers) Date: Fri, 15 Nov 1996 11:09:36 -0700 (MST) Cc: ponds!lambert.org!terry, ponds!Artisoft.COM!ponds!rivers, ponds!Artisoft.COM!ponds!freefall.cdrom.com!freebsd-hackers In-Reply-To: <199611150156.UAA20755@lakes.water.net> from "Thomas David Rivers" at Nov 14, 96 08:56:14 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Sounds like a reasonable explanation.... but... > > In the 2.1.5R and 2.1.5-STABLE code, there is no call to > simple_unlock(&vnode_free_list_slock) - in fact, there is no > simple_unlock() in the entire kern sub-directory... > > I think there's some 2.1.5 vs. -current confusion? Shit. My local machine has BSD4.4-Lite2 integrated... sorry. 8-(. Which code, exactly, are you running? > if (freevnodes < (numvnodes >> 2) || > numvnodes < desiredvnodes || > ! vp == NULL || /* list empty */ > ! vp->v_usecount) /* queue wrapped */ > ! { For your code, this might need to be: > if (freevnodes < (numvnodes >> 2) || > numvnodes < desiredvnodes || > ! vp == NULL || /* list empty */ > ! (vp->v_usecount && vp->v_usage == 0)) /* queue wrapped */ > ! { Damn, I'm getting old. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 19:20:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06343 for hackers-outgoing; Fri, 15 Nov 1996 19:20:54 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06308 for ; Fri, 15 Nov 1996 19:20:39 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA20830; Fri, 15 Nov 1996 22:20:07 -0500 Received: from lambert.org by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Nov 1996 22:20 EST Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.7.5/8.7.3) with UUCP id SAA25238 for FreeBSD.org!Hackers; Fri, 15 Nov 1996 18:58:25 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA17604; Fri, 15 Nov 1996 15:06:13 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA13106; Fri, 15 Nov 96 14:45:03 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA13061; Fri, 15 Nov 96 14:42:44 -0500 Received: from robin.mcnc.org (robin.mcnc.org [128.109.130.29]) by ncnoc.ncren.net (8.7.4/8.7.3) with SMTP id NAA02245; Fri, 15 Nov 1996 13:16:55 -0500 (EST) Received: from ns.mcnc.org by robin.mcnc.org (8.6.9/MCNC/8-10-92) id NAA12403; Fri, 15 Nov 1996 13:15:08 -0500 for Received: from robin.mcnc.org by ns.mcnc.org (SMI-8.6/SAM 100194 13:34:37) id SAA05175; Fri, 15 Nov 1996 18:16:10 GMT Received: from ns.mcnc.org by robin.mcnc.org (8.6.9/MCNC/8-10-92) id NAA12300; Fri, 15 Nov 1996 13:13:20 -0500 for Received: from relay6.UU.NET by ns.mcnc.org (SMI-8.6/SAM 100194 13:34:37) id SAA05172; Fri, 15 Nov 1996 18:14:22 GMT Received: from coyote.Artisoft.COM by relay6.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQbpyu22814; Fri, 15 Nov 1996 13:13:01 -0500 (EST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by coyote.Artisoft.COM (8.7.6/8.7.3) with SMTP id LAA15115; Fri, 15 Nov 1996 11:11:24 -0700 (MST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26436; Fri, 15 Nov 1996 11:00:09 -0700 Posted-Date: Fri, 15 Nov 1996 18:14:22 GMT From: Terry Lambert Message-Id: <199611151800.LAA26436@phaeton.artisoft.com> Subject: Re: Even more info on daily panics... To: ponds!ponds!rivers (Thomas David Rivers) Date: Fri, 15 Nov 1996 11:00:09 -0700 (MST) Cc: ponds!lambert.org!terry, ponds!Artisoft.COM!ponds!root.com!dg, ponds!Artisoft.COM!ponds!FreeBSD.org!Hackers, ponds!Artisoft.COM!ponds!cet.co.jp!michaelh, ponds!Artisoft.COM!ponds!rivers, ponds!Artisoft.COM!ponds!lambert.org!terry In-Reply-To: <199611150139.UAA20669@lakes.water.net> from "Thomas David Rivers" at Nov 14, 96 08:39:12 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If you look at the BSD4.4-Lite2 code, you will see they cleaned this > > up (using a fix just as kludgy as my one liner) by using kern_lock.c > > functions instead of smearing the lock state. > > Err, umm, I had to be a naysayer - but I've gotten two examples > of the one-liner fix that didn't address my particular problem. > > Granted, I could have messed something up; I'd be happy to retry > it all... You said it was fixed. Then you put in the printf, but removed the unlock, and it (understandably) blew up. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Nov 15 19:21:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06384 for hackers-outgoing; Fri, 15 Nov 1996 19:21:00 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06339 for ; Fri, 15 Nov 1996 19:20:52 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA21289; Fri, 15 Nov 1996 22:20:19 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Nov 1996 22:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id UAA27006 for ; Fri, 15 Nov 1996 20:22:59 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id UAA23098 for freebsd-hackers@freefall.cdrom.com; Fri, 15 Nov 1996 20:24:33 -0500 (EST) Date: Fri, 15 Nov 1996 20:24:33 -0500 (EST) From: Thomas David Rivers Message-Id: <199611160124.UAA23098@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Hacker's digest??? Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk For some reason, I was subscribed to the hackers-digest list. While I appreciate this service; I didn't subscribe to it... I can readily remove myself; but I was wondering if other people experienced this spontaneous subscription... - Dave Rivers - From owner-freebsd-hackers Fri Nov 15 19:21:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06385 for hackers-outgoing; Fri, 15 Nov 1996 19:21:01 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA06344 for ; Fri, 15 Nov 1996 19:20:54 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA21350; Fri, 15 Nov 1996 22:20:21 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 15 Nov 1996 22:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id VAA29778; Fri, 15 Nov 1996 21:42:00 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id VAA24034; Fri, 15 Nov 1996 21:43:35 -0500 (EST) Date: Fri, 15 Nov 1996 21:43:35 -0500 (EST) From: Thomas David Rivers Message-Id: <199611160243.VAA24034@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers, ponds!lambert.org!terry Subject: Another possible explanation about my daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've been staring at/reading through ffs_valloc.c and think I might have a potential explanation about the daily panics... In ffs_nodealloccg(), we look for an free inode. When one is found; the cg_inosused() bit is set "allocating" it. However; if you look at the for() loop (just before the "gotit" label) you'll see it marches "ipref" up as it looks for a free inode. But - and here's the crux of this - that calculated "ipref" value does not take into account fs_ipg (inodes per group). All the other calculations that set the allocated bit do take into account fs->fs_ipg. For the sake of this scenario, let's assume that this calulated ipref is larger than fs->fs_ipg (i.e. ipref != ipref & fs->fs_ipg). We set the wrong bit in the bitstring; and more importantly, we don't set the right bit... Now, in ffs_vfree(), we redetermine the index to check the allocated bit again - *but* when doing that we do account for fs->fs_ipg... so, the bit we check isn't the one we set. This would seem to be quite consistent with the panic's I'm seeing... What do you think? I'm going to put a new panic message in ffs_nodealloccg() just after the "gotit:" label: if(ipref != (ipref % fs->fs_ipg)) { panic("ffs_nodealloccg: ipref != ipref & fs->fs_ipg\n"); } If I trip over that one - I think I may have this figured out... - Dave Rivers - From owner-freebsd-hackers Fri Nov 15 20:12:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10178 for hackers-outgoing; Fri, 15 Nov 1996 20:12:53 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA10171 for ; Fri, 15 Nov 1996 20:12:46 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id UAA23915; Fri, 15 Nov 1996 20:12:33 -0800 (PST) Message-Id: <199611160412.UAA23915@austin.polstra.com> To: dgy@rtd.com Subject: Re: CVS Attic... Newsgroups: polstra.freebsd.hackers In-Reply-To: <199611160304.UAA07230@seagull.rtd.com> References: <199611160304.UAA07230@seagull.rtd.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Fri, 15 Nov 1996 20:12:33 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199611160304.UAA07230@seagull.rtd.com> dgy@rtd.com writes: > Greetings! > It's my understanding that a "cvs remove " should put > into the Attic subdirectory in the repository. Are there > conditions when this is *not* true? (i.e. *my* removes aren't > going to the Attic). Remember, the file in the CVS repository doesn't get changed until you do a "cvs commit" too. I suspect that is the cause of what you're (not) seeing. Also (I think this is right): Whether a file in the repository is in the Attic or not depends on the state of the head revision on the main (or default) branch. If you are working in another branch and do a remove, the file won't go into the Attic. In other words, a file can be "live" on some branches and "dead" on others. Attic residency is determined only by the state of the latest version on the main (or default) branch. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Fri Nov 15 20:57:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA11431 for hackers-outgoing; Fri, 15 Nov 1996 20:57:22 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA11425; Fri, 15 Nov 1996 20:57:12 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id PAA10718; Sat, 16 Nov 1996 15:27:08 +1030 (CST) From: Michael Smith Message-Id: <199611160457.PAA10718@genesis.atrad.adelaide.edu.au> Subject: Re: Q: system specific binaries In-Reply-To: <199611151543.KAA01199@dyson.iquest.net> from "John S. Dyson" at "Nov 15, 96 10:43:10 am" To: dyson@FreeBSD.org Date: Sat, 16 Nov 1996 15:27:07 +1030 (CST) Cc: rob@xs1.simplex.nl, hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk John S. Dyson stands accused of saying: > > > > If this is too easy to break, is there perhaps a way to specify > > from which directories binaries may be executed ? look at /sys/kern/imgact* for starters. Depending on what you're actually worried about, you might want to look at the source for the shells, perl, tcl, remove the debugger (gdb) etc. > Perhaps, formulate a system whereby the flags bits on a file are used > in some way... Note that I am not talking about the "protection" bits, > but there is another group of interesting things called flags bits that > can be placed only under the control of the kernel. Just a thought. > > (Perhaps an "annoint" command???) A "secure" flag, only settable by root and cleared when the file is written to might be vaguely useful. It might give a false sense of confidence though. > John -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Fri Nov 15 21:47:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA13237 for hackers-outgoing; Fri, 15 Nov 1996 21:47:28 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA13232 for ; Fri, 15 Nov 1996 21:47:22 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id VAA24341; Fri, 15 Nov 1996 21:47:19 -0800 (PST) Message-Id: <199611160547.VAA24341@austin.polstra.com> To: julian@whistle.com Subject: Re: cvsup not even hinted at on web pages Newsgroups: polstra.freebsd.hackers In-Reply-To: <328CCA0F.2781E494@whistle.com> References: <328CCA0F.2781E494@whistle.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Fri, 15 Nov 1996 21:47:18 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <328CCA0F.2781E494@whistle.com> you write: > there are plenty of mentions of SUP > but none for cvsup.. > I think we should conver them over and have a special cvsup > page. > > (I'm trying to convert but the info isn't easy to find from the web) > (next I'm going to search the mail archives) There is a brief mention of CVSup as an option in the FreeBSD handbook, section "17. Synchronizing source trees over the Internet", thanks to Jordan. I told him I'd flesh it out a long time ago, but I just haven't gotten around to it. If anybody is willing to put this together, I'll be very grateful, and I'll do my best to provide whatever answers you need. The cvsup(1) man page might be a reasonable place to start. With a little reformatting into SGML, it could fit into the web pages reasonably. A FAQ is also desperately needed, hint hint. :-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Fri Nov 15 22:43:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA14425 for hackers-outgoing; Fri, 15 Nov 1996 22:43:02 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA14406 for ; Fri, 15 Nov 1996 22:42:48 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15280(7)>; Fri, 15 Nov 1996 22:42:07 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Fri, 15 Nov 1996 22:41:55 -0800 To: Thomas David Rivers cc: freebsd-hackers@freefall.freebsd.org Subject: Re: Hacker's digest??? In-reply-to: Your message of "Fri, 15 Nov 96 17:24:33 PST." <199611160124.UAA23098@lakes.water.net> Date: Fri, 15 Nov 1996 22:41:45 PST From: Bill Fenner Message-Id: <96Nov15.224155pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199611160124.UAA23098@lakes.water.net> you write: >For some reason, I was subscribed to the hackers-digest list. freebsd-questions got accidentally subscribed to hackers-digest today; are you sure you didn't just see the welcome message that it sent to -questions? Or did you get subscribed individually? Bill From owner-freebsd-hackers Fri Nov 15 22:53:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA14644 for hackers-outgoing; Fri, 15 Nov 1996 22:53:32 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA14639 for ; Fri, 15 Nov 1996 22:53:30 -0800 (PST) Received: from suburbia.net (suburbia.net [198.142.2.24]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id WAA23706; Fri, 15 Nov 1996 22:53:30 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id RAA01354; Sat, 16 Nov 1996 17:53:06 +1100 From: Julian Assange Message-Id: <199611160653.RAA01354@suburbia.net> Subject: Re: earlier "holographic shell" in 2.2-ALPHA install procedure To: haertel@incognito.intel.com (Mike Haertel) Date: Sat, 16 Nov 1996 17:53:05 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611152104.NAA09906@incognito.intel.com> from "Mike Haertel" at Nov 15, 96 01:04:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I would like the ability to launch the "emergency > holographic shell" earlier in the install process, > say from a menu entry somewhere. Mainly I would > like to be able to launch it before "ifconfig" > is called in network installs. > This one annoyed me also. Infact, when first installing FreeBSD, I had to force various errors, just to get to it. It would be nice if one could launch it at any time. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | C7F81C2AA32D7D4E4D360A2ED2098E0D | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Fri Nov 15 23:56:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA16179 for hackers-outgoing; Fri, 15 Nov 1996 23:56:36 -0800 (PST) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA16174 for ; Fri, 15 Nov 1996 23:56:31 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.7.6/8.7.3) id RAA12202; Sat, 16 Nov 1996 17:56:24 +1000 Received: from pandora.devetir.qld.gov.au by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id RAA05013; Sat, 16 Nov 1996 17:40:05 +1000 (EST) Received: from netfl15a.devetir.qld.gov.au (netfl15a.devetir.qld.gov.au [167.123.24.12]) by pandora.devetir.qld.gov.au (8.6.10/8.6.12) with ESMTP id RAA06599; Sat, 16 Nov 1996 17:37:54 +1000 Received: by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA11037; Sat, 16 Nov 1996 07:36:39 GMT Date: Sat, 16 Nov 1996 07:36:39 GMT Message-Id: <199611160736.HAA11037@netfl15a.devetir.qld.gov.au> MIME-Version: 1.0 X-Mailer: exmh version 1.6.5 12/11/95 X-Newsreader: knews 0.9.7 References: In-Reply-To: From: sysseh@devetir.qld.gov.au (Stephen Hocking) Subject: Re: Maelstrom patch? X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org, spaz@u.washington.edu Content-Type: text/plain Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , John Utz writes: > Hello All; > > I recall somebody posting a patch to Maestroom to get it to > compile on freebsd. I thought i had saved it, but i cant find it. What's > even more frrustrating is that i used the archive search at > www.freebsd.org with the keyord Maelstrom and got totally unrelated mail > entries back concering somebody's ethernet card patches... what is up with > that? > > if somebody could send it to me i would appreciate it, i find that > i have entirely too much valuable study time on my hands :-)! > > tnx! > Yup, that was me. Bear in mind that the sound goes via the NAS soundserver, I was to busy to backport the sound code. Linux (where it originated) has a more upto date version of the OSS drivers. CAN WE PLEASE URGE HANNU TO GET THE PORT FINISHED!!!!. Anyways, here are the patches begin 777 Maelstrom.patches.gz M'XL("(YNC3(" TUA96QS=')O;2YP871C:&5S -57^V_B1A#^F?P5$R=*@.-E M7B&DM.)PFB#E ,4A3=2>?(Z]#JN8M;5>)]"J_WMG_0B&D-RENK:J!7AW/+O[ MS7SS,,5B$70B-.*8H2LJP:SB<7J?NPH)C"T!T(%ZO5OK=%O'H!X?MW?*Y?*Z M?NX78L>JJ%'KUE&U%:L6UR\YAV:CU.Q -)4[X?2H#3@J[P#D\%JHJDO9@TUY M3RE?5,. 5V]4];)==>F=$NLX-+Z?G.Q\P/O/G)"/NE;(X(!# MS8.E%\*3R03@\:!13M#",V[Z,VH%T+?CI,4&EG_01+[($[U"F[-PNGT[;O34B&CW/83QXG MVNB+KUN@?>J#&=K4@R#T?8^++<"7;P*/5AMD(7J*/3>3LXD;D#<-ZT^UX=A0 MVQ^'5^^!.^KKWP\N,U-7Y0(O9';BVHW(0@?')Z*C5?4[V5>V0=D(8/A\ AF< M;P?[LPYEEAO:!'6&&9U$NG$R)H5,#CUD8QU3 MZ=$BB;7/1O#>WTVH@,E%FW M!83G$_9$V0K&MFQOMTI'M56V'S=*:KV>IKNU6/24P4#N[_F"SNGOW8LHT/7DO%G+$FGF@#,'VV*& !^8]P0R_PL,89@Z]1XJB"-\/ MEH$@\Q+F$>?+2M)$R8(*4*,DO:."!&11V=KY&XUNL[GJ_,^Z&UU?;7?5SNM= MOZZ6ZD>K.H#31BLM WO4L8D#1G]X$\T2Y_V L*MST\+$(Y79C_)1PDNZP$@Z MOV%$PG1=LJ9*F$U-)I=^R"X%7(N/[;QA!(^\:1B%M=7RU+NE(!ZW"<\NEN=S M[O'#!;XGH.=WHW6(P($JOE]=7S:A6%V3)>"E M&#)B],*F2#L=;(K.)]-(3?IV3A>$E[$MIP1FF,'WMB9RF"$PH[U!8?,(67R= MPN.2VLI4\E*]D1(8?Q#5,'%B'' 0^,2B#M;4.+AGQ$27@D-=+!VQ,];8>&:S ML)7.*'*MNV6C#PD.%R_5) &K063X7GP:&)/^U7G4 M-C5]DE.J-GFLVH$O\RW#$Q;7BF5MS;1FMZYN$A6KO]1LUEYGZJA5ZJ@Q59CJ MR +2W -5K=5;)S'D')(EL"V:S);%@LEW6ZP;6)=A--#23D+X(_*%3.V"+.?Y MW;P9QL)>/QQC^]>C27[-\!+42C":7EQD!O*W4"C 'U'ID5OAJ7/?-2F#5)KS MH^S**Y^DW5T8F(QY(HMN$YE2B$OAGY&[8J/3/Q+_O-$;)OYKMOX%XV\I@J\- " #* end -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Sat Nov 16 00:11:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA16524 for hackers-outgoing; Sat, 16 Nov 1996 00:11:49 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA16519 for ; Sat, 16 Nov 1996 00:11:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id AAA16074; Sat, 16 Nov 1996 00:11:00 -0800 (PST) Message-Id: <199611160811.AAA16074@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Jaye Mathisen cc: hackers@freebsd.org Subject: Re: IRQ sharing on PCI? In-reply-to: Your message of "Fri, 15 Nov 1996 16:38:56 PST." From: David Greenman Reply-To: dg@root.com Date: Sat, 16 Nov 1996 00:10:59 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Do we support this? > >I noticed on 1 of my boxes when I rebooted it the following: > >tible display device> rev 76 int a irq 11 on pci0:8 >de0 rev 18 int a irq 11 on pci0:9 >de0: DC21140 [10-100Mb/s] pass 1.2 Ethernet address 00:00:c0:4b:10:ed >de0: enabling 10baseT UTP port >ahc0 rev 0 int a irq 11 on pci0:11 > > >Notice that they're all IRQ11, which I thought seemed odd. > >None of my other Pentiums do it, they all get different IRQ's. > >Anyway, any idea appreciated, I suppose it's entirely possible that it's >just a reporting problem, as opposed to anything actually wrong. Yes, it is supported, and yes it's really happening. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sat Nov 16 02:39:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA20323 for hackers-outgoing; Sat, 16 Nov 1996 02:39:35 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA20317 for ; Sat, 16 Nov 1996 02:39:29 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-44.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA05042 (5.67b/IDA-1.5 for ); Sat, 16 Nov 1996 11:39:19 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id LAA00640; Sat, 16 Nov 1996 11:39:06 +0100 (MET) Message-Id: <199611161039.LAA00640@x14.mi.uni-koeln.de> Date: Sat, 16 Nov 1996 11:39:05 +0100 From: se@freebsd.org (Stefan Esser) To: mrcpu@cdsnet.net (Jaye Mathisen) Cc: hackers@freebsd.org Subject: Re: IRQ sharing on PCI? References: X-Mailer: Mutt 0.49-PL10 Mime-Version: 1.0 In-Reply-To: ; from Jaye Mathisen on Nov 15, 1996 16:38:56 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 15, mrcpu@cdsnet.net (Jaye Mathisen) wrote: > > > Do we support this? > > I noticed on 1 of my boxes when I rebooted it the following: > > tible display device> rev 76 int a irq 11 on pci0:8 > de0 rev 18 int a irq 11 on pci0:9 > de0: DC21140 [10-100Mb/s] pass 1.2 Ethernet address 00:00:c0:4b:10:ed > de0: enabling 10baseT UTP port > ahc0 rev 0 int a irq 11 on pci0:11 > > > Notice that they're all IRQ11, which I thought seemed odd. Why ? > None of my other Pentiums do it, they all get different IRQ's. This depends on the PCI BIOS, which is free to assign any IRQ to any PCI Int line. PCI requires shared interrupts to work, since there are far less real interrupt request inputs in a typical system, than independent PCI Int lines. > Anyway, any idea appreciated, I suppose it's entirely possible that it's > just a reporting problem, as opposed to anything actually wrong. If it really bothers you (there is in fact some overhead caused by the polling of both the EThernet and SCSI chip, if one of them signaled an interrupt), then you'll have to look into your PCI BIOS setup. That is where the PCI interrupts are assigned to IRQs. The chip set will activate the PCI Int to ISA IRQ routing at POST, and will put the IRQ choosen in some PCI config space register of each PCI chip. That is the place where the driver finds it. The driver has to accept whatever is there, since the interrupt routing is different for each chip set, and only the BIOS knows how to do it right :) Regards, STefan > > From owner-freebsd-hackers Sat Nov 16 04:36:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27240 for hackers-outgoing; Sat, 16 Nov 1996 04:36:19 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA27231 for ; Sat, 16 Nov 1996 04:36:08 -0800 (PST) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.2/8.6.12) with SMTP id OAA08233; Sat, 16 Nov 1996 14:37:04 +0200 (EET) Date: Sat, 16 Nov 1996 14:37:04 +0200 (EET) From: Narvi To: "Eric J. Chet" cc: Hal Snyder , hackers@FreeBSD.ORG Subject: Re: Programming technique for non-forking servers? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 15 Nov 1996, Eric J. Chet wrote: > On Fri, 15 Nov 1996, Hal Snyder wrote: > > > Not exactly on subject, but does anyone know of a C++ class library for > > network servers? Or is C++ still mainly for cooking application-level > > code? > > > > I've looked as socket++, but it seems to have been abandoned, not sure > > why. > > > > Hello > How about the mother load. ACE(ADAPTIVE Communication > Environment) An Object-Oriented Network Programming Toolkit in C++. > > http://www.cs.wustl.edu/%7Eschmidt/ACE.html > > Has anybody tried to make this into a port? I have included the overview > below. > I have thought of doing this - but I still have the code packed in a compressed tar file. And I do have an unsubmitted-as-of-yet port of socket++ Sander > > Eric J. Chet > - ejc@bazzle.com > > Overview > -------- > The ADAPTIVE Communication Environment is an object-oriented toolkit that [snip] > ACE has been ported to a wide range of uni-processor and multi-process OS > platforms including Win32 (i.e., WinNT and Win95), most versions of UNIX > (e.g., SunOS 4.x and 5.x, SGI IRIX, HP-UX, OSF/1, AIX, Linux, > and SCO), VxWorks, and MVS OpenEdition. It is currently used in commercial > products by dozens of companies. > > ----- > > From owner-freebsd-hackers Sat Nov 16 04:46:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27804 for hackers-outgoing; Sat, 16 Nov 1996 04:46:57 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA27799; Sat, 16 Nov 1996 04:46:41 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id XAA17993; Sat, 16 Nov 1996 23:42:50 +1100 Date: Sat, 16 Nov 1996 23:42:50 +1100 From: Bruce Evans Message-Id: <199611161242.XAA17993@godzilla.zeta.org.au> To: mrcpu@cdsnet.net, se@FreeBSD.org Subject: Re: IRQ sharing on PCI? Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> None of my other Pentiums do it, they all get different IRQ's. > >This depends on the PCI BIOS, which is free >to assign any IRQ to any PCI Int line. >PCI requires shared interrupts to work, since >there are far less real interrupt request >inputs in a typical system, than independent >PCI Int lines. Doesn't a typical system have only 3 or 4 PCI slots and many more than 3 or 4 IRQs, so it is hard to run out of IRQs? Mine has 3 PCI slots, all full (:-(), and they get assigned irqs 10, 11 and 12 (one wasted for vga0). Bruce From owner-freebsd-hackers Sat Nov 16 05:11:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA28862 for hackers-outgoing; Sat, 16 Nov 1996 05:11:02 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA28856 for ; Sat, 16 Nov 1996 05:11:00 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.7.6/8.7.3) with ESMTP id HAA18900; Sat, 16 Nov 1996 07:10:57 -0600 (CST) Message-Id: <199611161310.HAA18900@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Doug Rabson cc: hackers@freebsd.org Subject: Re: vnode_pager_input errors... In-reply-to: Your message of Fri, 08 Nov 1996 11:59:44 +0000. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Nov 1996 07:10:57 -0600 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I just changed the implementation of NFS' asynchronous i/o which might >affect this. I think these changes were post 10/4/96; could you update >and see if it happens again? It just happened again. Same error. This is using a 3.0-CURRENT kernel as of Nov 9. It hasn't happened for a really long time--I thought that it may have been fixed. It would be nice if we had a fix for 2.2.. but I wouldn't even know where to begin diagnosing a problem such as this. Id be willing to help if anyone has any ideas.. Chris Csanady nfs server q:/scratch/local/FreeBSD-CVS: not responding vnode_pager_getpages: I/O read error vm_fault: pager input (probably hardware) error, PID 364 failure pid 364 (cvsup), uid 0: exited on signal 6 > >-- >Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com > Phone: +44 171 734 3761 > FAX: +44 171 734 6426 > From owner-freebsd-hackers Sat Nov 16 05:21:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA29122 for hackers-outgoing; Sat, 16 Nov 1996 05:21:51 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA29105 for ; Sat, 16 Nov 1996 05:21:46 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id OAA13753 for ; Sat, 16 Nov 1996 14:21:30 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA04955 for freebsd-hackers@freebsd.org; Sat, 16 Nov 1996 14:21:29 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id OAA07702 for freebsd-hackers@freebsd.org; Sat, 16 Nov 1996 14:12:15 +0100 (MET) From: J Wunsch Message-Id: <199611161312.OAA07702@uriah.heep.sax.de> Subject: Re: earlier "holographic shell" in 2.2-ALPHA install procedure To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 16 Nov 1996 14:12:15 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <6143.848096377@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 15, 96 02:19:37 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > I would like the ability to launch the "emergency > > holographic shell" earlier in the install process, > > So would I. :-) > > Unfortunately, if you do that before the chroot is done then it's > impossible to unmount the floppy and use the drive again for fixit or > floppy installation. Have you ever tried to simply umount() it with MNT_FORCE set? (The equivalent of ``umount -f''.) I assume it's only busy since there are device nodes on the fixit floppy that are currently in use by the kernel, even though they have not been opened using the pathnames from the fixit /dev. I've noticed earlier that the kernel gets confused in this situation. umount(..., MNT_FORCE) works around this. Another plea for DEVFS... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Nov 16 05:53:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA29968 for hackers-outgoing; Sat, 16 Nov 1996 05:53:58 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA29963; Sat, 16 Nov 1996 05:53:54 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id AAA11442; Sun, 17 Nov 1996 00:23:43 +1030 (CST) From: Michael Smith Message-Id: <199611161353.AAA11442@genesis.atrad.adelaide.edu.au> Subject: Re: IRQ sharing on PCI? In-Reply-To: <199611161242.XAA17993@godzilla.zeta.org.au> from Bruce Evans at "Nov 16, 96 11:42:50 pm" To: bde@zeta.org.au (Bruce Evans) Date: Sun, 17 Nov 1996 00:23:42 +1030 (CST) Cc: mrcpu@cdsnet.net, se@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans stands accused of saying: > > Doesn't a typical system have only 3 or 4 PCI slots and many more > than 3 or 4 IRQs, so it is hard to run out of IRQs? Mine has 3 > PCI slots, all full (:-(), and they get assigned irqs 10, 11 and > 12 (one wasted for vga0). You obviously don't have a sound card, or serial ports, or network cards. Only you do, and I think you're being stubborn 8) A "typically" configured PC has enough interrupt resources, but there are cards like the GUS PnP that can consume 2 or 3 or 4 interrupts themselves (being poorly designed) which cause major grief. My notebook has "just enough" interrupts, with two PCCARDs inserted there are none free, if I had the docking station for it, I would be short (and cross 8( ). > Bruce -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat Nov 16 06:40:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA01295 for hackers-outgoing; Sat, 16 Nov 1996 06:40:56 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA01283 for ; Sat, 16 Nov 1996 06:40:51 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id BAA20370; Sun, 17 Nov 1996 01:33:26 +1100 Date: Sun, 17 Nov 1996 01:33:26 +1100 From: Bruce Evans Message-Id: <199611161433.BAA20370@godzilla.zeta.org.au> To: ccsanady@friley216.res.iastate.edu, dfr@render.com Subject: Re: vnode_pager_input errors... Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >It just happened again. Same error. This is using a 3.0-CURRENT kernel as >of Nov 9. It hasn't happened for a really long time--I thought that it may >have been fixed. It would be nice if we had a fix for 2.2.. but I wouldn't >even know where to begin diagnosing a problem such as this. Id be willing to >help if anyone has any ideas.. > >Chris Csanady > >nfs server q:/scratch/local/FreeBSD-CVS: not responding >vnode_pager_getpages: I/O read error >vm_fault: pager input (probably hardware) error, PID 364 failure >pid 364 (cvsup), uid 0: exited on signal 6 I get reproducible errors like this when I turn off my nfs server. /usr is nfs mounted and shared libraries are in /lib. Cron forks a zillion times until runs out and can't exec because /usr isn't there. Bruce Nov 12 02:56:43 gamplex login: login from besplex.bde.org as bde Nov 12 03:25:41 gamplex /kernel: nfs server alphplex:/usr: not responding Nov 12 03:25:41 gamplex /kernel: nfs server alphplex:/usr: is alive again Nov 12 07:30:41 gamplex /kernel: nfs server alphplex:/usr: not responding Nov 12 07:31:06 gamplex /kernel: nfs server alphplex:/usr: is alive again Nov 13 02:00:14 gamplex /kernel: vnode_pager_getpages: I/O read error Nov 13 02:00:14 gamplex /kernel: vm_fault: pager input (probably hardware) error, PID 124 failure Nov 13 02:00:14 gamplex /kernel: pid 124 (inetd), uid 0: exited on signal 11 (core dumped) Nov 13 02:15:41 gamplex /kernel: nfs server alphplex:/usr: not responding Nov 13 02:16:12 gamplex /kernel: nfs server alphplex:/usr: is alive again Nov 13 02:24:23 gamplex /kernel: vnode_pager_getpages: I/O read error Nov 13 02:24:23 gamplex /kernel: vm_fault: pager input (probably hardware) error, PID 130 failure Nov 13 02:24:24 gamplex /kernel: pid 130 (sendmail), uid 0: exited on signal 11 (core dumped) Nov 13 02:30:41 gamplex /kernel: nfs server alphplex:/usr: not responding Nov 13 02:30:51 gamplex /kernel: nfs server alphplex:/usr: is alive again Nov 13 21:44:21 gamplex syslogd: exiting on signal 15 From owner-freebsd-hackers Sat Nov 16 07:15:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA02100 for hackers-outgoing; Sat, 16 Nov 1996 07:15:06 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA02088; Sat, 16 Nov 1996 07:14:55 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-18.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA08803 (5.67b/IDA-1.5); Sat, 16 Nov 1996 16:14:50 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id QAA00434; Sat, 16 Nov 1996 16:14:47 +0100 (MET) Message-Id: <199611161514.QAA00434@x14.mi.uni-koeln.de> Date: Sat, 16 Nov 1996 16:14:47 +0100 From: se@FreeBSD.org (Stefan Esser) To: bde@zeta.org.au (Bruce Evans) Cc: mrcpu@cdsnet.net, se@FreeBSD.org, hackers@FreeBSD.org Subject: Re: IRQ sharing on PCI? References: <199611161242.XAA17993@godzilla.zeta.org.au> X-Mailer: Mutt 0.49-PL10 Mime-Version: 1.0 In-Reply-To: <199611161242.XAA17993@godzilla.zeta.org.au>; from Bruce Evans on Nov 16, 1996 23:42:50 +1100 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Nov 16, bde@zeta.org.au (Bruce Evans) wrote: > >> None of my other Pentiums do it, they all get different IRQ's. > > > >This depends on the PCI BIOS, which is free > >to assign any IRQ to any PCI Int line. > >PCI requires shared interrupts to work, since > >there are far less real interrupt request > >inputs in a typical system, than independent > >PCI Int lines. > > Doesn't a typical system have only 3 or 4 PCI slots and many more > than 3 or 4 IRQs, so it is hard to run out of IRQs? Mine has 3 > PCI slots, all full (:-(), and they get assigned irqs 10, 11 and > 12 (one wasted for vga0). No, PCI supports 4 individual interrupt lines per slot, so you'd need 12 IRQs to cover all of them. Your VGA card most probably got an IRQ assigned, because it announced to be using Int A. A current PCI BIOS will assign IRQs to all slots that are occupied by a device, which has a non-zero value in its interrupt pin config PCI space register. (Try the following sequence of commands on a -current system: # pciconf -l pci0:0:0: class=0x000000 card=0x00000000 chip=0x04838086 rev=0x04 hdr=0x00 pci0:1:0: class=0x000000 card=0x00000000 chip=0x00011000 rev=0x01 hdr=0x00 pci0:2:0: class=0x000000 card=0x00000000 chip=0x04848086 rev=0x03 hdr=0x00 pci0:4:0: class=0x010000 card=0x00000000 chip=0x000f1000 rev=0x01 hdr=0x00 pci0:5:0: class=0x000100 card=0x00000000 chip=0x88c15333 rev=0x00 hdr=0x00 pci0:6:0: class=0x020000 card=0x00000000 chip=0x802910ec rev=0x00 hdr=0x00 # pciconf -r pci0:5:0 0x3c # my VGA doesn't have an int pin 0x00000000 # pciconf -r pci0:4:0 0x3c # but my NCR SCSI chip does ... :) 0x4008010c ^^ A 01 means Int A, 02 Int B, and so on ...) Most PCI chips only use Int A, but a multi-function chip will use B for the second "function" (identical to a LUN in SCSI terms), C to the third, ... , A again to the fifth, and so on. A PCI to PCI bridge will connect Int A to D of secondary bus slot 0 to Int A to D on its slot on the primary bus, Int A to D of slot 1 to Int B to D and then wrap around to Int A, and so on. (BTW: for cascaded PCI to PCI bridges apply resursively ;) This means that there are in fact four PCI Int lines, but most PCI cards will only use Int A. multi-function devices will use Int A and Int B, if two functions are implemented (see the AMD SCSI+Ethernet Combo chip), or all four lines if there are four functions on a chip (announced 4 channel Ethernet cards). And if you are using a PCI to PCI bridge (current 4 channel Ethernet cards and the AH3940 or PCI bus extender boxes, for example), then the PCI Int lines used will depend on the slots used on the secondary side of the PCI bridge. (The scheme used is meant to randomize PCI Int lines used and to reduce the probability of shared interrupt lines. But those must be supported anyway ...) Regards, STefan From owner-freebsd-hackers Sat Nov 16 08:23:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA05339 for hackers-outgoing; Sat, 16 Nov 1996 08:23:26 -0800 (PST) Received: from central.picker.com (central.picker.com [144.54.31.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA05330 for ; Sat, 16 Nov 1996 08:23:20 -0800 (PST) Received: from ct.picker.com by central.picker.com with smtp (Smail3.1.28.1 #3) id m0vOnOU-0004s3C; Sat, 16 Nov 96 11:14 EST Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA26961; Sat, 16 Nov 96 11:12:29 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id LAA08941; Sat, 16 Nov 1996 11:11:57 -0500 Message-Id: Date: Sat, 16 Nov 1996 11:11:56 -0500 From: rhh@ct.picker.com (Randall Hopper) To: hackers@freebsd.org Subject: Sharing SWAP between FreeBSD versions X-Mailer: Mutt 0.50 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm fixing to repartition my disks and wondering if I can share my 32M swap between any two FreeBSD versions I might have installed at the same time. Anybody know? A related questions is, is swap a "raw" partition in the sense that FreeBSD doesn't rely on it having any structure to use it? Thanks, Randall Hopper rhh@ct.picker.com From owner-freebsd-hackers Sat Nov 16 08:43:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA06569 for hackers-outgoing; Sat, 16 Nov 1996 08:43:32 -0800 (PST) Received: from zeus.gel.usherb.ca (zeus.gel.usherb.ca [132.210.70.7]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA06542; Sat, 16 Nov 1996 08:43:24 -0800 (PST) Received: from castor.gel.usherb.ca by zeus.gel.usherb.ca (4.1/SMI-4.1) id AA01145; Sat, 16 Nov 96 11:43:20 EST Received: by castor.gel.usherb.ca (SMI-8.6/SMI-SVR4) id LAA29031; Sat, 16 Nov 1996 11:43:19 -0500 Date: Sat, 16 Nov 1996 11:43:19 -0500 (EST) From: "Alex.Boisvert" To: Mark Mayo Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: userland PPP giving weird load numbers In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I've had this problem since 2.1x, and it appaears to still happen > occasionally in 2.2-ALPHA: > > mark:{105}/home/mark % w > 8:14AM up 46 mins, 3 users, load averages: 0.99, 0.97, 0.88 > USER TTY FROM LOGIN@ IDLE WHAT > mark p1 :0.0 7:28AM 45 -tcsh (tcsh) > mark p2 :0.0 7:28AM - w > mark p3 :0.0 7:32AM 37 ppp > > the ppp process causes the high load (which isn't real, BTW). Top shows it > as not doing a thing. As soon as I kill ppp off, the load drops right back > down. > I've noticed the same thing in 2.2-ALPHA since my installation. The load goes between .80 to 1.1 when doing (moderate) FTP transmissions with userland PPP. I don't know if the load is real or not because I have not verified that impact on performance it made. Alex Boisvert From owner-freebsd-hackers Sat Nov 16 08:53:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA07470 for hackers-outgoing; Sat, 16 Nov 1996 08:53:21 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA07415 for ; Sat, 16 Nov 1996 08:52:39 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA21146; Sat, 16 Nov 1996 17:51:46 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA07978; Sat, 16 Nov 1996 17:51:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id RAA04961; Sat, 16 Nov 1996 17:49:56 +0100 (MET) From: J Wunsch Message-Id: <199611161649.RAA04961@uriah.heep.sax.de> Subject: Re: PPP Question - help! To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 16 Nov 1996 17:49:56 +0100 (MET) Cc: sysseh@devetir.qld.gov.au (Stephen Hocking) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611120631.GAA27134@netfl15a.devetir.qld.gov.au> from Stephen Hocking at "Nov 12, 96 04:31:29 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Stephen Hocking wrote: > 11-12 16:22:08 [259] Phase: Network > 11-12 16:22:11 [259] myaddr = 203.12.164.198 hisaddr = 0.0.0.0 > 11-12 16:22:11 [259] OsLinkup: 0.0.0.0 > > & I ge the message SIOCAIFADDR: Destination address required, clearly because > this person (for some reason) isn't supplying the address at their end. What > do I need to set up at my end to make this work? My ppp.conf file has the set ifaddr 203.12.164.198 203.12.164.1 ^^^^^^^^^^^^ ...or whatever might be appropriate for the remote end -- he gives you free choice of the IP address you wanna use? How stupid! I think you can also specify your side as 0.0.0.0, it will be negotiated anyway. Watch out the log for whether his side rejects the address your side is proposing. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Nov 16 09:01:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07928 for hackers-outgoing; Sat, 16 Nov 1996 09:01:12 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA07919; Sat, 16 Nov 1996 09:01:04 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id DAA23158; Sun, 17 Nov 1996 03:57:21 +1100 Date: Sun, 17 Nov 1996 03:57:21 +1100 From: Bruce Evans Message-Id: <199611161657.DAA23158@godzilla.zeta.org.au> To: bde@zeta.org.au, se@freebsd.org Subject: Re: IRQ sharing on PCI? Cc: hackers@freebsd.org, mrcpu@cdsnet.net Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >This depends on the PCI BIOS, which is free >> >to assign any IRQ to any PCI Int line. >> >PCI requires shared interrupts to work, since >> >there are far less real interrupt request >> >inputs in a typical system, than independent >> >PCI Int lines. >... >This means that there are in fact four PCI Int lines, but >most PCI cards will only use Int A. multi-function devices >will use Int A and Int B, if two functions are implemented >(see the AMD SCSI+Ethernet Combo chip), or all four lines >if there are four functions on a chip (announced 4 channel >Ethernet cards). And if you are using a PCI to PCI bridge >(current 4 channel Ethernet cards and the AH3940 or PCI bus >extender boxes, for example), then the PCI Int lines used >will depend on the slots used on the secondary side of the >PCI bridge. (The scheme used is meant to randomize PCI Int But these aren't typical :-). Now that Pentiums and PCI are common in typical (cheap) systems, I guess that a typical PCI system has 0 or 1 (unused) PCI interrupts depending on whether vga0 has one :-]. Why aren't PCI interrupts used for motherboard i/o, at least optionally? BTW, `pciconf -r' dumps core after printing the usage message. Bruce Bruce From owner-freebsd-hackers Sat Nov 16 09:20:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08559 for hackers-outgoing; Sat, 16 Nov 1996 09:20:40 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA08543 for ; Sat, 16 Nov 1996 09:20:35 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA11210; Sat, 16 Nov 1996 12:20:04 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 16 Nov 1996 12:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id HAA10860; Sat, 16 Nov 1996 07:52:38 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id HAA26592; Sat, 16 Nov 1996 07:54:14 -0500 (EST) Date: Sat, 16 Nov 1996 07:54:14 -0500 (EST) From: Thomas David Rivers Message-Id: <199611161254.HAA26592@lakes.water.net> To: fenner@parc.xerox.com, ponds!ponds!rivers Subject: Re: Hacker's digest??? Cc: ponds!freefall.freebsd.org!freebsd-hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In message <199611160124.UAA23098@lakes.water.net> you write: > >For some reason, I was subscribed to the hackers-digest list. > > freebsd-questions got accidentally subscribed to hackers-digest > today; are you sure you didn't just see the welcome message that it > sent to -questions? Or did you get subscribed individually? > > Bill > It seems to be all fixed up now... I got a few digest posts, and then the unsubscribe post.. - Dave R. - From owner-freebsd-hackers Sat Nov 16 09:20:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08572 for hackers-outgoing; Sat, 16 Nov 1996 09:20:41 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA08549 for ; Sat, 16 Nov 1996 09:20:37 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA11229; Sat, 16 Nov 1996 12:20:06 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 16 Nov 1996 12:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id HAA11177; Sat, 16 Nov 1996 07:57:11 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id HAA26617; Sat, 16 Nov 1996 07:58:47 -0500 (EST) Date: Sat, 16 Nov 1996 07:58:47 -0500 (EST) From: Thomas David Rivers Message-Id: <199611161258.HAA26617@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.freebsd.org!freebsd-hackers, ponds!lambert.org!terry Subject: Re: Another possible explanation about my daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - I guess my theory about the modulus operation and turning on the "is allocated" bit in ffs_valloc.c didn't work out. I got one of my typical panics (at 1:15am this time).. - Dave Rivers - --------------------------------------------------------------------- Script started on Sat Nov 16 07:54:16 1996 [ponds.water.net]$ gdb -k kernel.10 vmcore.10 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 1e4000 current pcb at 1d5484 panic: ffs_valloc: dup alloc #0 0xf0193d7b in boot () (kgdb) where #0 0xf0193d7b in boot () #1 0xf0112b83 in panic () #2 0xf01751f3 in ffs_valloc () #3 0xf0181486 in ufs_makeinode () #4 0xf017ee45 in ufs_create () #5 0xf012cc07 in vn_open () #6 0xf012a43f in open () #7 0xf019c0f6 in syscall () #8 0xf01915bb in Xsyscall () #9 0x33c0 in ?? () #10 0x32cd in ?? () #11 0x327d in ?? () #12 0x31d7 in ?? () #13 0x2f7b in ?? () #14 0x2e76 in ?? () #15 0x3b87 in ?? () #16 0x4854 in ?? () #17 0x474e in ?? () #18 0x467a in ?? () #19 0x1ffe in ?? () #20 0x1e6b in ?? () #21 0x1d21 in ?? () #22 0x16a7 in ?? () #23 0x10d3 in ?? () (kgdb) [ponds.water.net]$ ^D Script done on Sat Nov 16 07:54:38 1996 From owner-freebsd-hackers Sat Nov 16 09:20:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08589 for hackers-outgoing; Sat, 16 Nov 1996 09:20:42 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA08566 for ; Sat, 16 Nov 1996 09:20:40 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA11199; Sat, 16 Nov 1996 12:20:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 16 Nov 1996 12:20 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id HAA10853; Sat, 16 Nov 1996 07:51:48 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id HAA26583; Sat, 16 Nov 1996 07:53:24 -0500 (EST) Date: Sat, 16 Nov 1996 07:53:24 -0500 (EST) From: Thomas David Rivers Message-Id: <199611161253.HAA26583@lakes.water.net> To: gpalmer@freebsd.org, ponds!freebsd.org!freebsd-stable Subject: Re: panic: ffs_valloc: dup alloc Cc: ponds!freebsd.org!freebsd-hackers Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Hi > > Our mail box just died with: > > root@mail:/var/crash> gdb -k kernel vmcore.2 > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.13 (i386-unknown-freebsd), > Copyright 1994 Free Software Foundation, Inc... > IdlePTD 1d5000 > current pcb at 1abd64 > panic: ffs_valloc: dup alloc > #0 boot (howto=260) at ../../i386/i386/machdep.c:912 > 912 } else { > (kgdb) bt Welcome to the club :-) This is the panic that I have had for several months, which is duplicated almost every night. Rest assured that several people are investigating this at this time... I believe it has something to do with the inode allocation bits in ffs_valloc(). Others believe some race conditions in vnode allocation are to blaim, etc... David Greene is investigating other avenues. It seems to me that we are closing in on the issue, if only by eliminating everything else :-) - Dave Rivers - p.s. I've moved this from freebsd-bugs to freebsd-hackers, where we have been discussing the problem for some time. From owner-freebsd-hackers Sat Nov 16 09:23:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08783 for hackers-outgoing; Sat, 16 Nov 1996 09:23:03 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA08765 for ; Sat, 16 Nov 1996 09:22:48 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA21761; Sat, 16 Nov 1996 18:21:43 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA08281; Sat, 16 Nov 1996 18:21:42 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id RAA05994; Sat, 16 Nov 1996 17:54:22 +0100 (MET) From: J Wunsch Message-Id: <199611161654.RAA05994@uriah.heep.sax.de> Subject: Re: Q: How to read hardware port ? *HELP* To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 16 Nov 1996 17:54:22 +0100 (MET) Cc: ts@polynet.lviv.ua (Slavik Terletsky) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <328C9983.41C6@polynet.lviv.ua> from Slavik Terletsky at "Nov 15, 96 06:25:40 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Slavik Terletsky wrote: > Say, if i am using port 0x443 and have no driver compiled for it - > can i read this port at all? (without driver!) Yes, by keeping a descriptor to the /dev/io security hole device open in your program. Hopefully, you must have EUID == 0 in order to do this. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Nov 16 09:23:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08861 for hackers-outgoing; Sat, 16 Nov 1996 09:23:42 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA08766 for ; Sat, 16 Nov 1996 09:22:50 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA21765; Sat, 16 Nov 1996 18:21:48 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA08282; Sat, 16 Nov 1996 18:21:48 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id SAA11299; Sat, 16 Nov 1996 18:09:07 +0100 (MET) From: J Wunsch Message-Id: <199611161709.SAA11299@uriah.heep.sax.de> Subject: Re: Sharing SWAP between FreeBSD versions To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 16 Nov 1996 18:09:07 +0100 (MET) Cc: rhh@ct.picker.com (Randall Hopper) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Randall Hopper at "Nov 16, 96 11:11:56 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Randall Hopper wrote: > I'm fixing to repartition my disks and wondering if I can share my > 32M swap between any two FreeBSD versions I might have installed at the > same time. Anybody know? You gotta put it into a slice of its own. You'll run into more problems with booting different FreeBSD versions however. > A related questions is, is swap a "raw" partition in the sense that > FreeBSD doesn't rely on it having any structure to use it? The slice needs a disklabel, and a `b' partition therein. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Nov 16 10:17:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA10837 for hackers-outgoing; Sat, 16 Nov 1996 10:17:00 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA10832 for ; Sat, 16 Nov 1996 10:16:59 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16638(5)>; Sat, 16 Nov 1996 10:16:26 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Sat, 16 Nov 1996 10:16:20 -0800 To: Chris Shenton cc: hackers@freebsd.org Subject: Re: 2.1.5-stable build fails in gdb, mrouted, named, nslookup In-reply-to: Your message of "Fri, 15 Nov 96 12:37:02 PST." <199611152037.UAA29055@wirehead.it.hq.nasa.gov> Date: Sat, 16 Nov 1996 10:16:15 PST From: Bill Fenner Message-Id: <96Nov16.101620pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611152037.UAA29055@wirehead.it.hq.nasa.gov> you write: >I'm running 2.1.5-RELEASE and recently supped -stable. I do a "make >world" from /usr/src, and get a few compilation errors that I probably >shouldn't. Nothing fatal, but gdb, mroute, named, and nslookup >*should* build. I just checked mrouted on streamer, and it builds fine. Perhaps you could try supping again, maybe you managed to hit an inconsitent tree. Bill From owner-freebsd-hackers Sat Nov 16 11:40:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA14930 for hackers-outgoing; Sat, 16 Nov 1996 11:40:52 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA14924 for ; Sat, 16 Nov 1996 11:40:45 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id GAA25929; Sun, 17 Nov 1996 06:36:29 +1100 Date: Sun, 17 Nov 1996 06:36:29 +1100 From: Bruce Evans Message-Id: <199611161936.GAA25929@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: Sharing SWAP between FreeBSD versions Cc: rhh@ct.picker.com Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> I'm fixing to repartition my disks and wondering if I can share my >> 32M swap between any two FreeBSD versions I might have installed at the >> same time. Anybody know? > >You gotta put it into a slice of its own. You'll run into more >problems with booting different FreeBSD versions however. A separate slice is only necessary if you want more than 6 mountable partitions altogether. You only need 2 more for the second version of FreeBSD, e.g., a: version 1 root b: swap c: special d: spare e: version 1 usr f: spare g: version 2 root h: version 2 usr >> A related questions is, is swap a "raw" partition in the sense that >> FreeBSD doesn't rely on it having any structure to use it? Yes. >The slice needs a disklabel, and a `b' partition therein. Nope. After `swapon /dev/wd0s4' (a spare partition), swapinfo says: Device 1024-blocks Used Avail Capacity Type /dev/sd0b 65536 8216 57256 13% Interleaved /dev/wd0s4 687456 0 687392 0% Interleaved Total 752864 8216 744648 1% The slice happens to be labelled, but I don't think this is important, and it doesn't have a 'b' partition. disklabel says: # /dev/rwd0s4: ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 1374912 0 unused 0 0 # (Cyl. 0 - 340) Bruce From owner-freebsd-hackers Sat Nov 16 12:13:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16240 for hackers-outgoing; Sat, 16 Nov 1996 12:13:05 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA16235 for ; Sat, 16 Nov 1996 12:13:01 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id PAA07301 for ; Sat, 16 Nov 1996 15:13:05 -0500 (EST) Date: Sat, 16 Nov 1996 15:13:04 -0500 (EST) From: "Marc G. Fournier" To: hackers@freebsd.org Subject: Hate to ask more about sockets...but... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After the ... discussion(?) I started with my last question, I kind of hate to ask another one...but what the hell, here goes...:) I've taken most of the suggestions that were given at the beginning of the last discussion and improved (I think?) my code accordingly. But I'm still getting what seems to be a strange result, possibly because I've missed something...again. First off, the server opens a .jpg file, mmap's it, and sends it out through the socket: ----------------- if( (fd = open(TESTFILE, O_RDONLY)) != -1) { fstat(fd, &fi); fp = mmap(NULL, fi.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if(fp == (caddr_t) -1) { fprintf(stderr, "MMAP() failed\n"); exit(1); } close(fd); while(cnt-- != 0) { /* set to 1 for initial test */ start = time(0); nwritten = write(newsockfd, START, strlen(START)); if(nwritten < 0) { fprintf(stderr, "failed to write to socket: [%d bytes]\n", nwritten); exit(1); } nwritten = writen(newsockfd, fp, fi.st_size); if(nwritten < 0) { fprintf(stderr, "failed to write data to socket\n"); exit(1); } } } ----------------- On the client side, it reads the buffer until there is no data left: ----------------- char ptr[8192]; while(1) { n = read(sockfd, ptr, sizeof(ptr) - 1); if(n < 0) { fprintf(stderr, "error reading socket\n"); exit(0); } else if(n == 0) break; fprintf(stderr, "read %d(%d) bytes\n", bytes, n); write(STDOUT_FILENO, ptr, n); } ----------------- The 'fprintf' in client produces: read 46(46) bytes read 1486(1440) bytes read 9677(8191) bytes read 17868(8191) bytes read 26059(8191) bytes read 27340(1281) bytes And the server reports having written: 0= START: wrote [46] to socket WRITEN: bytes left to write == 27294 WRITEN: wrote 27294 bytes And the file being read in is: -rw-r--r-- 1 scrappy wheel 27294 Nov 9 00:23 ../public_html/POST4.JPG Great, this works...sort of. For some reason, the program reports that the read completed correctly, with the exact number of bytes read as I wrote to the socket, but I'm missing several lines out of the graphic when I view it. (check out http://www.ki.net/~scrappy/test.html, if you want to see what I mean by "missing several lines") If I change 'cnt' in the server to be 2 instead of 1, the graphic will come out completely...as if, for some reason, the last read didn't get written to the screen if it only 'scans' the file once. The other thing I found was weird was that if I changed the 'break' in the client side to a 'continue', so that it continued to scan the input socket for data (ie. await the next image to be send down the socket), I lost even more data from the image. I don't know if this makes any sense, or if there is enough data, but from everything I've been able to read, this *should* work...shouldn't it? Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Sat Nov 16 12:31:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA16852 for hackers-outgoing; Sat, 16 Nov 1996 12:31:03 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA16832; Sat, 16 Nov 1996 12:31:00 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.7.6/8.7.3) with SMTP id MAA25863; Sat, 16 Nov 1996 12:30:59 -0800 (PST) Date: Sat, 16 Nov 1996 12:30:58 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org cc: current@freebsd.org Subject: I think our fsck is still funky. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 2.2-current, supped this morning. P120, 2940, Conner 4GB disk. Copy lots of small files to the disk in lots of directories (like news). Begin an rm while copying. Simulate failure by pulling plug. Unsimulate failure by re-inerting power cord. Reboot, fsck disk. Mount, and try again. I get crashes in dup_inode, and some ffs_alloc stuff. newfs the disk and it's fine. Me thinks that fsck is still missing some sanity checks. From owner-freebsd-hackers Sat Nov 16 12:52:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA17838 for hackers-outgoing; Sat, 16 Nov 1996 12:52:06 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA17832 for ; Sat, 16 Nov 1996 12:52:03 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA25959; Sat, 16 Nov 1996 21:51:51 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA14205; Sat, 16 Nov 1996 21:51:50 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id VAA28016; Sat, 16 Nov 1996 21:41:22 +0100 (MET) From: J Wunsch Message-Id: <199611162041.VAA28016@uriah.heep.sax.de> Subject: Re: Sharing SWAP between FreeBSD versions To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 16 Nov 1996 21:41:22 +0100 (MET) Cc: rhh@ct.picker.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611161936.GAA25929@godzilla.zeta.org.au> from Bruce Evans at "Nov 17, 96 06:36:29 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >You gotta put it into a slice of its own. You'll run into more > >problems with booting different FreeBSD versions however. > > A separate slice is only necessary if you want more than 6 mountable > partitions altogether. > a: version 1 root > b: swap > c: special > d: spare > e: version 1 usr > f: spare > g: version 2 root > h: version 2 usr Hmm, i forgot about the possibility to specify a partition to boot from. > >The slice needs a disklabel, and a `b' partition therein. > > Nope. After `swapon /dev/wd0s4' (a spare partition), swapinfo says: > > Device 1024-blocks Used Avail Capacity Type > /dev/sd0b 65536 8216 57256 13% Interleaved > /dev/wd0s4 687456 0 687392 0% Interleaved > Total 752864 8216 744648 1% This didn't use to work all the time. I've tried it back in 2.0.5 or 2.1 days. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Nov 16 13:38:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA21804 for hackers-outgoing; Sat, 16 Nov 1996 13:38:41 -0800 (PST) Received: from kaori.communique.net (kaori.Communique.Net [204.27.65.55]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA21799; Sat, 16 Nov 1996 13:38:36 -0800 (PST) Received: by kaori.communique.net with Microsoft Exchange (IMC 4.0.837.3) id <01BBD3D3.E9063940@kaori.communique.net>; Sat, 16 Nov 1996 15:36:18 -0600 Message-ID: From: Raul Zighelboim To: "'freebsd-hackers@freefall.freebsd.org'" Cc: "'freebsd-hardware@freefall.freebsd.org'" Subject: kernel optimization and PCI ... Date: Sat, 16 Nov 1996 15:36:17 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk My system has two serial ports, using IRQ 3 and 4. I do not need those ports at all. I would like to set the system so that the PCI cards (adaptec 2940 - ahc0) and the SMC ethernet card (de0) would use those IRQs. Is this possible? Otherwise, what are the requirment/conditions that would allowed me to set # AUTO_EOI_2 on the kernel in a safe way ? Finnaly, my PPro 200 with 256Megs of ram seems to be unresponsive some times. It is specially slow to respond to the command (df). Is there somethin I should look into in particular ? System is FreeBSD 2.1.5 Thanks ------------------------ ------------------------ Raul Zighelboim Communique Inc. mailto:mango@communique.net http://www.communique.net From owner-freebsd-hackers Sat Nov 16 13:39:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA21865 for hackers-outgoing; Sat, 16 Nov 1996 13:39:32 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA21852; Sat, 16 Nov 1996 13:39:22 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-13.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA13806 (5.67b/IDA-1.5); Sat, 16 Nov 1996 22:39:16 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id WAA00542; Sat, 16 Nov 1996 22:38:33 +0100 (MET) Message-Id: <199611162138.WAA00542@x14.mi.uni-koeln.de> Date: Sat, 16 Nov 1996 22:37:13 +0100 From: se@freebsd.org (Stefan Esser) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, se@freebsd.org, hackers@freebsd.org, mrcpu@cdsnet.net Subject: Re: IRQ sharing on PCI? References: <199611161657.DAA23158@godzilla.zeta.org.au> X-Mailer: Mutt 0.49-PL10 Mime-Version: 1.0 In-Reply-To: <199611161657.DAA23158@godzilla.zeta.org.au>; from Bruce Evans on Nov 17, 1996 03:57:21 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 17, bde@zeta.org.au (Bruce Evans) wrote: > >This means that there are in fact four PCI Int lines, but > >most PCI cards will only use Int A. multi-function devices > >will use Int A and Int B, if two functions are implemented > >(see the AMD SCSI+Ethernet Combo chip), or all four lines > >if there are four functions on a chip (announced 4 channel > >Ethernet cards). And if you are using a PCI to PCI bridge > >(current 4 channel Ethernet cards and the AH3940 or PCI bus > >extender boxes, for example), then the PCI Int lines used > >will depend on the slots used on the secondary side of the > >PCI bridge. (The scheme used is meant to randomize PCI Int > > But these aren't typical :-). Now that Pentiums and PCI are Well, we are lucky that the PCI-SIG didn't decide to only support the "typical" PC ... I wasn't interested in the result, if they had ... :) > common in typical (cheap) systems, I guess that a typical > PCI system has 0 or 1 (unused) PCI interrupts depending on I assume you mean IRQs, not PCI interrupts ? > whether vga0 has one :-]. Why aren't PCI interrupts used > for motherboard i/o, at least optionally? Hmmm, I don't quite understand this question. I surely would prefer, if PCI was defined to use a reasonable interrupt controller, seperate from the ISA PIC. But in order to support fully ISA compatible PCI cards (for example some BusLogic SCSI controllers and some Eternet cards, well and all the VGA cards ...) they didn't say anything about interrupts, except that they must be shareable. > BTW, `pciconf -r' dumps core after printing the usage message. Really ? It was supposed to panic your system :) The following patch fixes this (and adds printing of the header type register, which will be required for yet to be released PCI chips). Regards, STefan Index: /usr/src/usr.sbin/pciconf/pciconf.c =================================================================== RCS file: /usr/cvs/src/usr.sbin/pciconf/pciconf.c,v retrieving revision 1.1.1.1 diff -C2 -r1.1.1.1 pciconf.c *** pciconf.c 1996/10/22 20:27:47 1.1.1.1 --- pciconf.c 1996/11/16 21:23:14 *************** *** 54,57 **** --- 54,58 ---- "\t%s [-r|-w] [-bh] sel addr [value]\n", argv0, argv0); + exit (1); } *************** *** 132,139 **** for (p = conf; p < &conf[pc.pci_len / sizeof conf[0]]; p++) { ! printf("pci%d:%d:%d:\tclass=0x%06x card=0x%08lx chip=0x%08lx rev=0x%02x\n", p->pc_sel.pc_bus, p->pc_sel.pc_dev, p->pc_sel.pc_func, p->pc_class >> 8, p->pc_subid, ! p->pc_devid, p->pc_class & 0xff); } } --- 133,140 ---- for (p = conf; p < &conf[pc.pci_len / sizeof conf[0]]; p++) { ! printf("pci%d:%d:%d:\tclass=0x%06x card=0x%08lx chip=0x%08lx rev=0x%02x hdr=0x%02x\n", p->pc_sel.pc_bus, p->pc_sel.pc_dev, p->pc_sel.pc_func, p->pc_class >> 8, p->pc_subid, ! p->pc_devid, p->pc_class & 0xff, p->pc_hdr); } } From owner-freebsd-hackers Sat Nov 16 14:13:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA23706 for hackers-outgoing; Sat, 16 Nov 1996 14:13:55 -0800 (PST) Received: from sumatra.americantv.com (sumatra.americantv.com [199.184.181.250]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA23701 for ; Sat, 16 Nov 1996 14:13:37 -0800 (PST) Received: from right.PCS (right.pcs. [148.105.10.31]) by sumatra.americantv.com (8.7.6/8.7.3) with ESMTP id PAA14278; Sat, 16 Nov 1996 15:34:13 -0600 (CST) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id WAA05401; Sat, 16 Nov 1996 22:11:37 GMT Message-Id: <199611162211.WAA05401@right.PCS> Date: Sat, 16 Nov 1996 16:11:36 -0600 From: jlemon@americantv.com (Jonathan Lemon) To: scrappy@ki.net (Marc G. Fournier) Cc: hackers@FreeBSD.org Subject: Re: Hate to ask more about sockets...but... References: X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 In-Reply-To: ; from Marc G. Fournier on Nov 16, 1996 15:13:04 -0500 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Great, this works...sort of. For some reason, the program reports that the > read completed correctly, with the exact number of bytes read as I wrote to > the socket, but I'm missing several lines out of the graphic when I view it. > (check out http://www.ki.net/~scrappy/test.html, if you want to see what I > mean by "missing several lines") > > If I change 'cnt' in the server to be 2 instead of 1, the graphic will come > out completely...as if, for some reason, the last read didn't get written to > the screen if it only 'scans' the file once. > > The other thing I found was weird was that if I changed the 'break' in > the client side to a 'continue', so that it continued to scan the input > socket for data (ie. await the next image to be send down the socket), I > lost even more data from the image. It sounds almost if your client is buffering it's output writes, and that you aren't flushing the buffer before the client exits. I cobbled up a quick client/server example with the above code, and it doesn't seem to have any problems transferring data back and forth. (e-mail me if you want the code). -- Jonathan From owner-freebsd-hackers Sat Nov 16 14:44:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24974 for hackers-outgoing; Sat, 16 Nov 1996 14:44:38 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA24940 for ; Sat, 16 Nov 1996 14:44:24 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id RAA08720; Sat, 16 Nov 1996 17:44:27 -0500 (EST) Date: Sat, 16 Nov 1996 17:44:27 -0500 (EST) From: "Marc G. Fournier" To: Jonathan Lemon cc: hackers@FreeBSD.org Subject: Re: Hate to ask more about sockets...but... In-Reply-To: <199611162211.WAA05401@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 16 Nov 1996, Jonathan Lemon wrote: > > Great, this works...sort of. For some reason, the program reports that the > > read completed correctly, with the exact number of bytes read as I wrote to > > the socket, but I'm missing several lines out of the graphic when I view it. > > (check out http://www.ki.net/~scrappy/test.html, if you want to see what I > > mean by "missing several lines") > > > > If I change 'cnt' in the server to be 2 instead of 1, the graphic will come > > out completely...as if, for some reason, the last read didn't get written to > > the screen if it only 'scans' the file once. > > > > The other thing I found was weird was that if I changed the 'break' in > > the client side to a 'continue', so that it continued to scan the input > > socket for data (ie. await the next image to be send down the socket), I > > lost even more data from the image. > > It sounds almost if your client is buffering it's output writes, and that > you aren't flushing the buffer before the client exits. I cobbled up a quick > client/server example with the above code, and it doesn't seem to have any > problems transferring data back and forth. (e-mail me if you want the code). One of the things I thought about after sending out the original is that since it is a blocked read, that the last packet, which is <4096, is taking too long to return...I'm going to attempt making it a non-blocking read instead, and see if that fixes the problem. It always seems to be the last read that goes missing... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Sat Nov 16 14:52:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25665 for hackers-outgoing; Sat, 16 Nov 1996 14:52:17 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA25618; Sat, 16 Nov 1996 14:52:01 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id JAA30382; Sun, 17 Nov 1996 09:45:37 +1100 Date: Sun, 17 Nov 1996 09:45:37 +1100 From: Bruce Evans Message-Id: <199611162245.JAA30382@godzilla.zeta.org.au> To: freebsd-hackers@freefall.freebsd.org, mango@staff.communique.net Subject: Re: kernel optimization and PCI ... Cc: freebsd-hardware@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >My system has two serial ports, using IRQ 3 and 4. >I do not need those ports at all. > >I would like to set the system so that the PCI cards (adaptec 2940 - >ahc0) and the SMC ethernet card (de0) would use those IRQs. Is this >possible? Don't know. >Otherwise, what are the requirment/conditions that would allowed me to >set # AUTO_EOI_2 on the kernel in a safe way ? Hardware that supports it. I think most does. Bruce From owner-freebsd-hackers Sat Nov 16 15:29:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27274 for hackers-outgoing; Sat, 16 Nov 1996 15:29:08 -0800 (PST) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA27265 for ; Sat, 16 Nov 1996 15:29:06 -0800 (PST) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id AAA29225; Sun, 17 Nov 1996 00:34:42 +0100 (MET) From: Mikael Karpberg Message-Id: <199611162334.AAA29225@ocean.campus.luth.se> Subject: Re: earlier "holographic shell" in 2.2-ALPHA install procedure To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 17 Nov 1996 00:34:42 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <6143.848096377@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 15, 96 02:19:37 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I would like the ability to launch the "emergency > > holographic shell" earlier in the install process, > > So would I. :-) > > Unfortunately, if you do that before the chroot is done then it's > impossible to unmount the floppy and use the drive again for fixit or > floppy installation. The EHS is started just as soon as it's possible > for me to start it, I'm afraid. Umm... How is this? If you read his post, he said "or as a menu alternative". Why not have one? You choose it, it throws you an "ok/cancel" requester which says: This option disables the fixit floppy and floppy installation menu alternatives. Are you sure you want to continue with opening the shell? And if confirmed, go ahead... Throw up a shell at vty3 and disable the apropriate options. Later when you intend to throw up the shell, just check if it's allready there, and don't, if it is. That should create no problems, should it? /Mikael (Who's also been frustrated by the abscence of the EHS at an early stage.) From owner-freebsd-hackers Sat Nov 16 15:59:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA28650 for hackers-outgoing; Sat, 16 Nov 1996 15:59:33 -0800 (PST) Received: from uruk.org (root@ns.uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA28640 for ; Sat, 16 Nov 1996 15:59:28 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vOuiz-00047c-00; Sat, 16 Nov 1996 16:04:37 -0800 To: hackers@freebsd.org Subject: Memory probe(s) in FreeBSD Date: Sat, 16 Nov 1996 16:04:37 -0800 From: Erich Boleyn Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all. I'm not on the freebsd-hackers e-mail list, and I'm not set up to do CVS patches, and last of all, I don't know who is in charge of the memory probe stuff in FreeBSD. The situation is that FreeBSD does some weird stuff in "i386/i386/machdep.c" which interferes with correct autodetection of the amount of RAM installed. The existing bootloader checks the BIOS interfaces for lower and upper memory, and pass that to the kernel. The kernel checks the RTC values and used to always ignore the values passed by the bootloader. Currently, it does use the BIOS value passed by the bootloader for lower memory, because it was discovered that this was necessary to get APM and SMP code to work right. It still ignores the BIOS values for upper memory, though. I would argue that the BIOS values should always be used, and the RTC values simply ignored unless something specific (like the SMP probe) needs them. The reasons are: (1) RTC lower memory is physical installed RAM. Using all of it might overwrite data used by APM or SMP BIOS structures. (2) RTC upper memory is only a compatibility value, it isn't guaranteed to have all memory, and cannot represent more than 64MB of RAM. (3) New BIOS interfaces exist (in most machines newer than 3 years old, and in some older as well) which can report as much RAM as can be physically installed and supported by the hardware. At least one bootloader (GRUB, see my web pages below for details) can report it in a way that FreeBSD could use if the value passed by the bootloader wasn't ignored. Thanks for your time. -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-hackers Sat Nov 16 16:04:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA28855 for hackers-outgoing; Sat, 16 Nov 1996 16:04:55 -0800 (PST) Received: from super-g.inch.com (spork@super-g.com [204.178.32.161]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA28849; Sat, 16 Nov 1996 16:04:48 -0800 (PST) Received: from localhost (spork@localhost) by super-g.inch.com (8.7.6/8.6.9) with SMTP id SAA12948; Sat, 16 Nov 1996 18:03:13 -0500 Date: Sat, 16 Nov 1996 17:03:13 -0600 (CST) From: "S(pork)" X-Sender: spork@super-g.inch.com To: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: New sendmail bug... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's nasty and easy... If you're on Bugtraq, you saw it. If anyone with more knowledge on this issue can check it out, please post to the list so everyone can free themselves of this vulnerability. Root in under 15 seconds with an account on the machine. If you need the 'sploit, please mail me here and I'll send it to you. I verified it on FBSD, NetBSD, Linux so far... TIA Charles From owner-freebsd-hackers Sat Nov 16 16:17:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA29282 for hackers-outgoing; Sat, 16 Nov 1996 16:17:29 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA29277; Sat, 16 Nov 1996 16:17:26 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id SAA26299; Sat, 16 Nov 1996 18:17:25 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id SAA01993; Sat, 16 Nov 1996 18:17:24 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id SAA16884; Sat, 16 Nov 1996 18:17:23 -0600 (CST) From: Karl Denninger Message-Id: <199611170017.SAA16884@Jupiter.Mcs.Net> Subject: Re: New sendmail bug... To: spork@super-g.com (S) Date: Sat, 16 Nov 1996 18:17:23 -0600 (CST) Cc: freebsd-security@FreeBSD.org, freebsd-hackers@FreeBSD.org In-Reply-To: from "S" at Nov 16, 96 05:03:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > It's nasty and easy... If you're on Bugtraq, you saw it. If anyone with > more knowledge on this issue can check it out, please post to the list so > everyone can free themselves of this vulnerability. Root in under 15 > seconds with an account on the machine. If you need the 'sploit, please > mail me here and I'll send it to you. I verified it on FBSD, NetBSD, > Linux so far... > > TIA > > Charles Its real - and the fix is two lines inserted in the sighup() handler: setgid(RealGid); setuid(RealUid); prior to the exec call. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-hackers Sat Nov 16 16:26:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA29823 for hackers-outgoing; Sat, 16 Nov 1996 16:26:34 -0800 (PST) Received: from super-g.inch.com (spork@super-g.com [204.178.32.161]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA29817; Sat, 16 Nov 1996 16:26:32 -0800 (PST) Received: from localhost (spork@localhost) by super-g.inch.com (8.7.6/8.6.9) with SMTP id SAA13138; Sat, 16 Nov 1996 18:24:55 -0500 Date: Sat, 16 Nov 1996 17:24:55 -0600 (CST) From: "S(pork)" X-Sender: spork@super-g.inch.com To: Karl Denninger cc: freebsd-security@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: New sendmail bug... In-Reply-To: <199611170017.SAA16884@Jupiter.Mcs.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Thanks, also I just installed smrsh on a whim (I'm definetly not a C expert, very very novice here) and smrsh (included in the sendmail dist) takes care of the problem as well... Exploit to follow... Charles On Sat, 16 Nov 1996, Karl Denninger wrote: > > > > It's nasty and easy... If you're on Bugtraq, you saw it. If anyone with > > more knowledge on this issue can check it out, please post to the list so > > everyone can free themselves of this vulnerability. Root in under 15 > > seconds with an account on the machine. If you need the 'sploit, please > > mail me here and I'll send it to you. I verified it on FBSD, NetBSD, > > Linux so far... > > > > TIA > > > > Charles > > Its real - and the fix is two lines inserted in the sighup() handler: > > setgid(RealGid); > setuid(RealUid); > > prior to the exec call. > > -- > -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > From owner-freebsd-hackers Sat Nov 16 16:32:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA00303 for hackers-outgoing; Sat, 16 Nov 1996 16:32:39 -0800 (PST) Received: from virginia.edu (mars.itc.Virginia.EDU [128.143.2.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA00284 for ; Sat, 16 Nov 1996 16:32:33 -0800 (PST) Received: from mail.cs.virginia.edu by mail.virginia.edu id ab12815; 16 Nov 96 19:32 EST Received: from stretch.cs.Virginia.edu (atf3r@stretch-fo.cs.Virginia.EDU [128.143.136.14]) by archive.cs.Virginia.EDU (8.7.5/8.7.3) with SMTP id TAA03411; Sat, 16 Nov 1996 19:32:12 -0500 (EST) Received: by stretch.cs.Virginia.edu (4.1/SMI-2.0) id AA19183; Sat, 16 Nov 96 19:32:09 EST Date: Sat, 16 Nov 1996 19:32:09 -0500 (EST) From: "Adrian T. Filipi-Martin" Reply-To: adrian@virginia.edu To: "Jordan K. Hubbard" Cc: Mike Haertel , hackers@freebsd.org Subject: Re: earlier "holographic shell" in 2.2-ALPHA install procedure In-Reply-To: <6143.848096377@time.cdrom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 15 Nov 1996, Jordan K. Hubbard wrote: > > I would like the ability to launch the "emergency > > holographic shell" earlier in the install process, > > So would I. :-) > > Unfortunately, if you do that before the chroot is done then it's > impossible to unmount the floppy and use the drive again for fixit or > floppy installation. The EHS is started just as soon as it's possible > for me to start it, I'm afraid. > I too have found this frustrating when dealing with a problem/tricky install, e.g. an ibm thinkpad. The EHS was a long-term shell. How about an option for a short-term EHS before the chroot? You could even require that sysinstall refuse to continue until the shell has exited. Adrian adrian@virginia.edu ---->>>>| Support your local programmer, System Administrator --->>>| STOP Software Patent Abuses NOW! NVL, NIIMS and Telemedicine Labs -->>| For an application and information Member: League for Programming Freedom ->| see: http://www.lpf.org/ From owner-freebsd-hackers Sat Nov 16 16:55:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA01232 for hackers-outgoing; Sat, 16 Nov 1996 16:55:29 -0800 (PST) Received: from chaos.ecpnet.com (raistlin@chaos.ecpnet.com [204.246.64.13]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA01227; Sat, 16 Nov 1996 16:55:26 -0800 (PST) Received: from localhost (raistlin@localhost) by chaos.ecpnet.com (8.8.2/8.7.3) with SMTP id SAA01881; Sat, 16 Nov 1996 18:56:48 -0600 Date: Sat, 16 Nov 1996 18:56:47 -0600 (CST) From: Justen Stepka To: "S(pork)" cc: freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: New sendmail bug... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 16 Nov 1996, S(pork) wrote: > It's nasty and easy... If you're on Bugtraq, you saw it. If anyone with > more knowledge on this issue can check it out, please post to the list so > everyone can free themselves of this vulnerability. Root in under 15 > seconds with an account on the machine. If you need the 'sploit, please > mail me here and I'll send it to you. I verified it on FBSD, NetBSD, > Linux so far... > > TIA > > Charles > I tested this on FBSD and I couldn't get it to work. Though when I tried it on Linux it worked in about 10 second :(, currently I have disabled accounts on my machines until I fix the problem. ------------------------------------------------------------------------------ Justen Stepka | http://www.ecpnet.com/~raistlin Network Administrator | "This space for rent" raistlin@ecpnet.com | 3.0-CURRENT FreeBSD 3.0-CURRENT ------------------------------------------------------------------------------ From owner-freebsd-hackers Sat Nov 16 17:05:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA01825 for hackers-outgoing; Sat, 16 Nov 1996 17:05:54 -0800 (PST) Received: from procert.cert.dfn.de (root@procert.cert.dfn.de [134.100.14.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA01805; Sat, 16 Nov 1996 17:05:43 -0800 (PST) Received: from tiger.cert.dfn.de (ley@tiger.cert.dfn.de [134.100.14.11]) by procert.cert.dfn.de (8.8.3/8.8.3) with ESMTP id CAA16908; Sun, 17 Nov 1996 02:06:57 +0100 (MET) From: Wolfgang Ley Received: (from ley@localhost) by tiger.cert.dfn.de (8.8.3/8.8.3) id CAA10374; Sun, 17 Nov 1996 02:06:56 +0100 (MET) Message-Id: <199611170106.CAA10374@tiger.cert.dfn.de> Subject: Re: New sendmail bug... To: spork@super-g.com (S) Date: Sun, 17 Nov 1996 02:06:55 +0100 (MET) Cc: karl@Mcs.Net, freebsd-security@FreeBSD.org, freebsd-hackers@FreeBSD.org In-Reply-To: from "S" at Nov 16, 96 05:24:55 pm Organization: DFN-CERT (Computer Emergency Response Team, Germany) Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- S wrote: > > Thanks, also I just installed smrsh on a whim (I'm definetly not a C > expert, very very novice here) and smrsh (included in the sendmail dist) > takes care of the problem as well... Exploit to follow... smrsh won't help you protecting against the new problem (restarting sendmail via sighup and modified argv[0]). sendmail 8.8.3 (which is currently being tested) will fix the problem. Or are you talking about another (new?) problem? Bye, Wolfgang. - -- Wolfgang Ley, DFN-CERT, Vogt-Koelln-Str. 30, 22527 Hamburg, Germany Email: ley@cert.dfn.de Phone: +49 40 5494-2262 Fax: +49 40 5494-2241 PGP-Key available via finger ley@ftp.cert.dfn.de any key-server or via WWW from http://www.cert.dfn.de/~ley/ ...have a nice day -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMo5lIgQmfXmOCknRAQG4tAP/Vv1+68RYqZpYc1c5G9l3fl1a0g2KB1gY 5fhyighSNXv+CBhyMseQbL4rawSnR2ipDW1BW1MEgo3iGGpFsDIFUKIu5uk26km6 s88V80Pmc9L3AYE6p1JVH97+OpEKU3BVlRDR2g8Ya1ecxDujQF5G/fVhmwpejyvd viG7NXDFPvM= =paMe -----END PGP SIGNATURE----- From owner-freebsd-hackers Sat Nov 16 17:25:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA02717 for hackers-outgoing; Sat, 16 Nov 1996 17:25:10 -0800 (PST) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA02712 for ; Sat, 16 Nov 1996 17:25:07 -0800 (PST) Received: (from tony@localhost) by nlanr.net (8.7.3/8.7.3) id RAA22826 for freebsd-hackers@FreeBSD.org; Sat, 16 Nov 1996 17:25:07 -0800 (PST) From: Tony Sterrett Message-Id: <199611170125.RAA22826@nlanr.net> Subject: Help with cache To: freebsd-hackers@FreeBSD.org Date: Sat, 16 Nov 1996 17:25:06 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello, I am having a difficult time with a little research project. I am trying to study the effects of caching (Pentum caching that is). I need to be able to turn off the cache. This can be done at boot time I know, but I have a need to do it during execution. Many systems I have worked with have some means of disabling the cache. Does anybody have any ideas? Even an negtive answer would help Cheers, Tony From owner-freebsd-hackers Sat Nov 16 17:27:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA02866 for hackers-outgoing; Sat, 16 Nov 1996 17:27:23 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA02845; Sat, 16 Nov 1996 17:27:19 -0800 (PST) Received: from super-g.inch.com (super-g.com) by mail.crl.com with SMTP id AA14134 (5.65c/IDA-1.5); Sat, 16 Nov 1996 17:28:16 -0800 Received: from localhost (spork@localhost) by super-g.inch.com (8.7.6/8.6.9) with SMTP id TAA13300; Sat, 16 Nov 1996 19:25:48 -0500 Date: Sat, 16 Nov 1996 18:25:48 -0600 (CST) From: "S(pork)" X-Sender: spork@super-g.inch.com To: freebsd-security@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: New sendmail bug... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk And even though it looked like it did not work with smrsh installed, it does... Can anyone with a public UNIX box say "sitting duck"? And on the weekend I have to find out about this. If only I were a programmer instead of a lowly SA with few C skills... Charles On Sat, 16 Nov 1996, S(pork) wrote: > It's nasty and easy... If you're on Bugtraq, you saw it. If anyone with > more knowledge on this issue can check it out, please post to the list so > everyone can free themselves of this vulnerability. Root in under 15 > seconds with an account on the machine. If you need the 'sploit, please > mail me here and I'll send it to you. I verified it on FBSD, NetBSD, > Linux so far... > > TIA > > Charles > From owner-freebsd-hackers Sat Nov 16 17:35:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA04059 for hackers-outgoing; Sat, 16 Nov 1996 17:35:33 -0800 (PST) Received: from mail.id.net (mail.id.net [199.125.1.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA04033; Sat, 16 Nov 1996 17:35:25 -0800 (PST) Received: from server.id.net (server.id.net [199.125.1.10]) by mail.id.net (8.7.5/ID-Net) with ESMTP id UAA02467; Sat, 16 Nov 1996 20:39:44 -0500 (EST) Received: (from rls@localhost) by server.id.net (8.7.5/8.7.3) id UAA06048; Sat, 16 Nov 1996 20:35:34 -0500 (EST) From: Robert Shady Message-Id: <199611170135.UAA06048@server.id.net> Subject: Re: New sendmail bug... In-Reply-To: from Justen Stepka at "Nov 16, 96 06:56:47 pm" To: raistlin@chaos.ecpnet.com (Justen Stepka) Date: Sat, 16 Nov 1996 20:35:34 -0500 (EST) Cc: spork@super-g.com, freebsd-security@freebsd.org, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It's nasty and easy... If you're on Bugtraq, you saw it. If anyone with > > more knowledge on this issue can check it out, please post to the list so > > everyone can free themselves of this vulnerability. Root in under 15 > > seconds with an account on the machine. If you need the 'sploit, please > > mail me here and I'll send it to you. I verified it on FBSD, NetBSD, > > Linux so far... Please send me this one, I have several shell servers here I'd like to test & plug... -- Rob === _/_/_/_/_/ _/_/_/_/ _/_/ _/ _/_/_/_/_/ _/_/_/_/_/ _/ _/ _/ _/_/_/ _/ _/ _/ _/_/_/_/ _/ _/_/_/_/_/ _/_/_/_/ _/ _/ _/_/_/_/_/ _/ Innovative Data Services Serving South-Eastern Michigan Internet Service Provider / Hardware Sales / Consulting Services Voice: (810)855-0404 / Fax: (810)855-3268 / Web: http://www.id.net From owner-freebsd-hackers Sat Nov 16 17:45:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA05788 for hackers-outgoing; Sat, 16 Nov 1996 17:45:48 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA05769 for ; Sat, 16 Nov 1996 17:45:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id RAA17595; Sat, 16 Nov 1996 17:44:50 -0800 (PST) Message-Id: <199611170144.RAA17595@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Erich Boleyn cc: hackers@FreeBSD.org Subject: Re: Memory probe(s) in FreeBSD In-reply-to: Your message of "Sat, 16 Nov 1996 16:04:37 PST." From: David Greenman Reply-To: dg@root.com Date: Sat, 16 Nov 1996 17:44:50 -0800 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >The situation is that FreeBSD does some weird stuff in >"i386/i386/machdep.c" which interferes with correct autodetection of >the amount of RAM installed. > >The existing bootloader checks the BIOS interfaces for lower and upper >memory, and pass that to the kernel. > >The kernel checks the RTC values and used to always ignore the values >passed by the bootloader. > >Currently, it does use the BIOS value passed by the bootloader for lower >memory, because it was discovered that this was necessary to get APM and >SMP code to work right. It still ignores the BIOS values for upper memory, >though. > >I would argue that the BIOS values should always be used, and the RTC >values simply ignored unless something specific (like the SMP probe) needs >them. I seem to recall that there was a problem with doing this on some systems, but since my memory is so vague, I'm inclined to agree with you. :-) It's probably that old FreeBSD bootblocks didn't pass in the BIOS information (via the bootinfo struct)...but this was so long ago that I don't think it matters anymore. Perhaps it should use the RTC numbers if the passed-in BIOS numbers are zero? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sat Nov 16 18:03:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10780 for hackers-outgoing; Sat, 16 Nov 1996 18:03:38 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10768 for ; Sat, 16 Nov 1996 18:03:33 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id VAA01808; Sat, 16 Nov 1996 21:03:24 -0500 (EST) From: "John S. Dyson" Message-Id: <199611170203.VAA01808@dyson.iquest.net> Subject: Re: Help with cache To: tony@nlanr.net (Tony Sterrett) Date: Sat, 16 Nov 1996 21:03:23 -0500 (EST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199611170125.RAA22826@nlanr.net> from "Tony Sterrett" at Nov 16, 96 05:25:06 pm Reply-To: dyson@FreeBSD.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Hello, > > I am having a difficult time with a little research project. > I am trying to study the effects of caching (Pentum caching > that is). > > I need to be able to turn off the cache. This can be done at > boot time I know, but I have a need to do it during execution. > Many systems I have worked with have some means of disabling > the cache. Does anybody have any ideas? Even an negtive answer > would help > Tell me *exactly* what you want to do, I might be able to fashion a hack for you. John From owner-freebsd-hackers Sat Nov 16 20:57:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA26392 for hackers-outgoing; Sat, 16 Nov 1996 20:57:56 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA26386; Sat, 16 Nov 1996 20:57:46 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id XAA13291; Sat, 16 Nov 1996 23:57:40 -0500 (EST) Date: Sat, 16 Nov 1996 23:57:40 -0500 (EST) From: "Marc G. Fournier" To: "S(pork)" cc: freebsd-security@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: New sendmail bug... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 16 Nov 1996, S(pork) wrote: > It's nasty and easy... If you're on Bugtraq, you saw it. If anyone with > more knowledge on this issue can check it out, please post to the list so > everyone can free themselves of this vulnerability. Root in under 15 > seconds with an account on the machine. If you need the 'sploit, please > mail me here and I'll send it to you. I verified it on FBSD, NetBSD, > Linux so far... > Please send details on 'sploit...would like to test on my Solaris 2.5.1 box as well... Thanks... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Sat Nov 16 22:28:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA29433 for hackers-outgoing; Sat, 16 Nov 1996 22:28:17 -0800 (PST) Received: from uruk.org (root@ns.uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA29426 for ; Sat, 16 Nov 1996 22:28:14 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vP0nA-0004qS-00; Sat, 16 Nov 1996 22:33:20 -0800 To: dg@root.com cc: hackers@freebsd.org Subject: Re: Memory probe(s) in FreeBSD In-reply-to: Your message of "Sat, 16 Nov 1996 17:44:50 PST." <199611170144.RAA17595@root.com> Date: Sat, 16 Nov 1996 22:33:19 -0800 From: Erich Boleyn Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman writes: > >I would argue that the BIOS values should always be used, and the RTC > >values simply ignored unless something specific (like the SMP probe) needs > >them. > > I seem to recall that there was a problem with doing this on some systems, > but since my memory is so vague, I'm inclined to agree with you. :-) It's > probably that old FreeBSD bootblocks didn't pass in the BIOS information (via > the bootinfo struct)...but this was so long ago that I don't think it matters > anymore. Perhaps it should use the RTC numbers if the passed-in BIOS numbers > are zero? There is a "valid" flag set in the info passed by the bootloader. You'll see it if you look in "i386/i386/machdep.c". What I'd suggest is to use the values from the bootloader if they are "valid", or otherwise use the RTC values. Just take out the current parts where it complains if the RTC values are different from the BIOS values. It is confusing and on many modern machines they are usually different anyway, so you'll see it all the time for no good reason. As to there being a problem a while ago... the problem was that the FreeBSD bootblocks read the return value from the EAX register for the upper memory BIOS call, where it is only valid for the AX register. Some machines return garbage in the high bits of EAX. The proper thing to do is to zero the top 16 bits of EAX after the INT 0x15 AH=0x88 call in the bootloader, not in the kernel proper (again, because some bootloaders might pass valid information from other BIOS interfaces). -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying"