From owner-freebsd-hackers Sun Nov 3 00:34:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA06416 for hackers-outgoing; Sun, 3 Nov 1996 00:34:01 -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 AAA06301; Sun, 3 Nov 1996 00:32:08 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id TAA24597; Sun, 3 Nov 1996 19:29:10 +1100 Date: Sun, 3 Nov 1996 19:29:10 +1100 From: Bruce Evans Message-Id: <199611030829.TAA24597@godzilla.zeta.org.au> To: dg@Root.COM, smp@csn.net Subject: Re: ed0 timeouts Cc: hackers@freefall.freebsd.org, smp@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Is it possible for a new INT to be asserted by the if_ed driver WHILE >it is currently being serviced by the edintr() routine? Probably. It is certainly possibly for other ISA devices. The IRQ tends to go low when you read the status register and then there can be another edge when another event occurs. >What I have discovered is that unlike the 8259, the IO APIC will ignore >(ie NOT delivered or held pending) an edge level INT if it currently is >masked. The routine in vector.s masks the INT, calls edintr(), then after >edintr() returns it unmasks the INT. If another INT fired as a result >of ed_start() being called in edintr() BEFORE the INT was unmasked it >would be LOST. It seems to be more braindamaged than an 8259 :-(. (The main 8259 braindamage is that you can't see the state of the IRQ lines directly except while interrupts are masked and not in service.) Bruce From owner-freebsd-hackers Sun Nov 3 00:46:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA07310 for hackers-outgoing; Sun, 3 Nov 1996 00:46:42 -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 AAA07206; Sun, 3 Nov 1996 00:44:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id AAA23866; Sun, 3 Nov 1996 00:43:51 -0800 (PST) Message-Id: <199611030843.AAA23866@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Steve Passe cc: hackers@freefall.freebsd.org, smp@freefall.freebsd.org Subject: Re: ed0 timeouts In-reply-to: Your message of "Sat, 02 Nov 1996 23:43:56 MST." <199611030643.XAA25052@clem.systemsix.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 03 Nov 1996 00:43:51 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Question: > >Is it possible for a new INT to be asserted by the if_ed driver WHILE >it is currently being serviced by the edintr() routine? > >What I have discovered is that unlike the 8259, the IO APIC will ignore >(ie NOT delivered or held pending) an edge level INT if it currently is >masked. The routine in vector.s masks the INT, calls edintr(), then after >edintr() returns it unmasks the INT. If another INT fired as a result >of ed_start() being called in edintr() BEFORE the INT was unmasked it >would be LOST. Yes, you can get another interrupt while servicing one. The driver loops until all interrupts are serviced, but there would be a window between when it thinks there are no more interrupts to service and returning to vector.s to unmask the interrupts. This window will exist in all ISA drivers. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Nov 3 01:03:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA08240 for hackers-outgoing; Sun, 3 Nov 1996 01:03:06 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA08170; Sun, 3 Nov 1996 01:01:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id CAA25770; Sun, 3 Nov 1996 02:00:45 -0700 Message-Id: <199611030900.CAA25770@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: dg@root.com cc: hackers@freefall.freebsd.org, smp@freefall.freebsd.org, bde@zeta.org.au Subject: Re: ed0 timeouts In-reply-to: Your message of "Sun, 03 Nov 1996 00:43:51 PST." <199611030843.AAA23866@root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Nov 1996 02:00:44 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Yes, you can get another interrupt while servicing one. The driver loops >until all interrupts are serviced, but there would be a window between when it >thinks there are no more interrupts to service and returning to vector.s to >unmask the interrupts. This window will exist in all ISA drivers. bummer... Intel says: It is strongly recommended that first 82489 (ie APIC) should be unmasked and then the device interrupt should be enabled. By this sequence software can ensure that always an edge will occur at the APIC input only after the interrupt is unmasked. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Sun Nov 3 01:55:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA11482 for hackers-outgoing; Sun, 3 Nov 1996 01:55: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 BAA11395; Sun, 3 Nov 1996 01:53:53 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id UAA28658; Sun, 3 Nov 1996 20:47:03 +1100 Date: Sun, 3 Nov 1996 20:47:03 +1100 From: Bruce Evans Message-Id: <199611030947.UAA28658@godzilla.zeta.org.au> To: dg@root.com, smp@csn.net Subject: Re: ed0 timeouts Cc: bde@zeta.org.au, hackers@freefall.freebsd.org, smp@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >bummer... > >Intel says: > >It is strongly recommended that first 82489 (ie APIC) should be unmasked >and then the device interrupt should be enabled. By this sequence software >can ensure that always an edge will occur at the APIC input only after >the interrupt is unmasked. My version of -current does lazy 8259-masking so that the 8259 doesn't have to be masked unless the device interrupt repeats. It would probably work to never mask it for edge triggered interrupts, but I'm worried about noise, and level sensitive interrupts need to be handled somehow. Is the APIC also braindamaged for interrupts masked at the CPU level? Bruce Warning: these diffs contain unrelated things (mostly undefined macros) that won't compile. diff -c2 icu.s~ icu.s *** icu.s~ Thu Oct 31 22:48:25 1996 --- icu.s Thu Oct 31 22:48:27 1996 *************** *** 106,109 **** --- 106,110 ---- jne doreti_unpend doreti_exit: + CPL_CHANGE_3(%eax) movl %eax,_cpl decb _intr_nesting_level *************** *** 154,157 **** --- 155,159 ---- jae doreti_swi cli + CPL_CHANGE_3(%eax) movl %eax,_cpl MEXITCOUNT *************** *** 171,175 **** --- 173,179 ---- */ orl imasks(,%ecx,4),%eax + CPL_CHANGE_4(%eax) movl %eax,_cpl + CPL_CHANGE_4_DONE call %edx popl %eax *************** *** 256,263 **** --- 260,271 ---- pushl %eax orl imasks(,%ecx,4),%eax + CPL_CHANGE_4(%eax) movl %eax,_cpl + CPL_CHANGE_4_DONE call %edx popl %eax + CPL_CHANGE_4(%eax) movl %eax,_cpl + CPL_CHANGE_4_DONE jmp splz_next *************** *** 276,279 **** --- 284,291 ---- pushl %eax cli + #define irq_num 0 + andb $~IRQ_BIT(irq_num),iactive + IRQ_BYTE(irq_num) + incl inotactive_counts + (irq_num) * 4 + #undef irq_num MEXITCOUNT jmp _Xintr0 /* XXX might need _Xfastintr0 */ *************** *** 287,290 **** --- 299,306 ---- pushl %eax cli + #define irq_num 8 + andb $~IRQ_BIT(irq_num),iactive + IRQ_BYTE(irq_num) + incl inotactive_counts + (irq_num) * 4 + #undef irq_num MEXITCOUNT jmp _Xintr8 /* XXX might need _Xfastintr8 */ *************** *** 294,299 **** --- 310,327 ---- ALIGN_TEXT ; \ __CONCAT(vec,irq_num): ; \ + popl %eax ; \ + pushfl ; \ + pushl $KCSEL ; \ + pushl %eax ; \ + cli ; \ + andb $~IRQ_BIT(irq_num),iactive + IRQ_BYTE(irq_num) ; \ + incl inotactive_counts + (irq_num) * 4 ; \ + MEXITCOUNT ; \ + jmp __CONCAT(_Xintr,irq_num) + + #if 0 int $ICU_OFFSET + (irq_num) ; \ ret + #endif BUILD_VEC(1) diff -c2 vector.s~ vector.s *** vector.s~ Thu Oct 31 22:44:16 1996 --- vector.s Thu Oct 31 22:45:20 1996 *************** *** 128,131 **** --- 128,132 ---- pushl _intr_unit + (irq_num) * 4 ; \ call *_intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ + INTR_ARG_ADJUST ; \ enable_icus ; /* (re)enable ASAP (helps edge trigger?) */ \ addl $4,%esp ; \ *************** *** 136,140 **** notl %eax ; \ andl _ipending,%eax ; \ ! jne 1f ; /* yes, handle them */ \ MEXITCOUNT ; \ MAYBE_POPL_ES ; \ --- 137,142 ---- notl %eax ; \ andl _ipending,%eax ; \ ! jne 3f ; /* yes, maybe handle them */ \ ! 2: ; \ MEXITCOUNT ; \ MAYBE_POPL_ES ; \ *************** *** 145,152 **** --- 147,162 ---- iret ; \ ; \ + 3: ; \ + cmpb $3,_intr_nesting_level ; /* is there enough stack? */ \ + jb 1f ; /* yes, handle unmasked interrupts */ \ + jmp 2b ; /* no, return */ \ + ; \ ALIGN_TEXT ; \ 1: ; \ + CPL_CHANGE($HWI_MASK|SWI_MASK) ; \ movl _cpl,%eax ; \ + /* XXX next line is probably unnecessary now. */ \ movl $HWI_MASK|SWI_MASK,_cpl ; /* limit nesting ... */ \ + incb _intr_nesting_level ; /* ... really limit it ... */ \ sti ; /* ... to do this as early as possible */ \ MAYBE_POPL_ES ; /* discard most of thin frame ... */ \ *************** *** 164,168 **** pushl %eax ; \ subl $4,%esp ; /* junk for unit number */ \ - incb _intr_nesting_level ; \ MEXITCOUNT ; \ jmp _doreti --- 174,177 ---- *************** *** 180,189 **** movl %ax,%ds ; /* ... early for obsolete reasons */ \ movl %ax,%es ; \ movb _imen + IRQ_BYTE(irq_num),%al ; \ orb $IRQ_BIT(irq_num),%al ; \ movb %al,_imen + IRQ_BYTE(irq_num) ; \ outb %al,$icu+ICU_IMR_OFFSET ; \ enable_icus ; \ - incl _cnt+V_INTR ; /* tally interrupts */ \ movl _cpl,%eax ; \ testb $IRQ_BIT(irq_num),%reg ; \ --- 189,215 ---- movl %ax,%ds ; /* ... early for obsolete reasons */ \ movl %ax,%es ; \ + movb iactive + IRQ_BYTE(irq_num),%al ; \ + testb $IRQ_BIT(irq_num),%al ; \ + je 1f ; \ + /* XXX skip mcounting here to avoid double count */ \ movb _imen + IRQ_BYTE(irq_num),%al ; \ orb $IRQ_BIT(irq_num),%al ; \ movb %al,_imen + IRQ_BYTE(irq_num) ; \ outb %al,$icu+ICU_IMR_OFFSET ; \ + incl imen_counts + (irq_num) * 4 ; \ + enable_icus ; \ + orb $IRQ_BIT(irq_num),_ipending + IRQ_BYTE(irq_num) ; \ + popl %es ; \ + popl %ds ; \ + popal ; \ + addl $4+4,%esp ; \ + iret ; \ + ; \ + ALIGN_TEXT ; \ + 1: ; \ + orb $IRQ_BIT(irq_num),%al ; \ + movb %al,iactive + IRQ_BYTE(irq_num) ; \ + incl iactive_counts + (irq_num) * 4 ; \ enable_icus ; \ movl _cpl,%eax ; \ testb $IRQ_BIT(irq_num),%reg ; \ *************** *** 192,195 **** --- 218,222 ---- __CONCAT(Xresume,irq_num): ; \ FAKE_MCOUNT(12*4(%esp)) ; /* XXX late to avoid double count */ \ + incl _cnt+V_INTR ; /* tally interrupts */ \ movl _intr_countp + (irq_num) * 4,%eax ; \ incl (%eax) ; \ *************** *** 198,209 **** pushl _intr_unit + (irq_num) * 4 ; \ orl _intr_mask + (irq_num) * 4,%eax ; \ movl %eax,_cpl ; \ sti ; \ call *_intr_handler + (irq_num) * 4 ; \ ! cli ; /* must unmask _imen and icu atomically */ \ movb _imen + IRQ_BYTE(irq_num),%al ; \ andb $~IRQ_BIT(irq_num),%al ; \ movb %al,_imen + IRQ_BYTE(irq_num) ; \ outb %al,$icu+ICU_IMR_OFFSET ; \ sti ; /* XXX _doreti repeats the cli/sti */ \ MEXITCOUNT ; \ --- 225,244 ---- pushl _intr_unit + (irq_num) * 4 ; \ orl _intr_mask + (irq_num) * 4,%eax ; \ + CPL_CHANGE_1(%eax, irq_num) ; \ movl %eax,_cpl ; \ sti ; \ call *_intr_handler + (irq_num) * 4 ; \ ! INTR_ARG_ADJUST ; \ ! cli ; /* unmask iactive, _imen and icu atomically */ \ ! andb $~IRQ_BIT(irq_num),iactive + IRQ_BYTE(irq_num) ; \ ! incl inotactive_counts + (irq_num) * 4 ; \ movb _imen + IRQ_BYTE(irq_num),%al ; \ + testb $IRQ_BIT(irq_num),%al ; \ + je 3f ; \ andb $~IRQ_BIT(irq_num),%al ; \ movb %al,_imen + IRQ_BYTE(irq_num) ; \ outb %al,$icu+ICU_IMR_OFFSET ; \ + incl inotmen_counts + (irq_num) * 4 ; \ + 3: ; \ sti ; /* XXX _doreti repeats the cli/sti */ \ MEXITCOUNT ; \ *************** *** 258,261 **** --- 293,306 ---- .data + iactive: + .long 0 + iactive_counts: + .space NHWI*4 + inotactive_counts: + .space NHWI*4 + imen_counts: + .space NHWI*4 + inotmen_counts: + .space NHWI*4 ihandlers: /* addresses of interrupt handlers */ /* actually resumption addresses for HWI's */ From owner-freebsd-hackers Sun Nov 3 02:01:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA11900 for hackers-outgoing; Sun, 3 Nov 1996 02:01:25 -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 CAA11892 for ; Sun, 3 Nov 1996 02:01:20 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id UAA29293; Sun, 3 Nov 1996 20:59:16 +1100 Date: Sun, 3 Nov 1996 20:59:16 +1100 From: Bruce Evans Message-Id: <199611030959.UAA29293@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: Verbose babble in if_fddisubr.c Cc: freebsd-hackers@freebsd.org, j@ida.interface-business.de Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >The idea was for it to be a flag that you could set so early that you >could catch boot-related stuff (to which I consider the slice but >not the FDDI messages). As soon as you have single user running >you can tweak a sysctl variable, and things that can use that, >should use that instead. The slice code already has a variable to tweak (dsi_debug), but I think there shouldn't be many such variables. The ones that exist should be grouped together and initially set to the value of bootverbose. bootverbose should be a sysctl variable and tweaking it should tweak all the related variables. Bruce From owner-freebsd-hackers Sun Nov 3 02:22:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA13052 for hackers-outgoing; Sun, 3 Nov 1996 02:22:18 -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 CAA13044 for ; Sun, 3 Nov 1996 02:22:11 -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 LAA13290; Sun, 3 Nov 1996 11:21:25 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA25123; Sun, 3 Nov 1996 11:21:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id LAA17194; Sun, 3 Nov 1996 11:16:50 +0100 (MET) From: J Wunsch Message-Id: <199611031016.LAA17194@uriah.heep.sax.de> Subject: Re: 2.2-961006-SNAP keyboard lockup To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 3 Nov 1996 11:16:50 +0100 (MET) Cc: handy@sag.space.lockheed.com (Brian N. Handy) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Brian N. Handy" at "Nov 2, 96 11:34:08 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 Brian N. Handy wrote: > Based on the harrassment I've gotten for an > suid script, and *no* reponse on the problem itself...do I safely assume > this is probably still a problem? Seems so. -- 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 Sun Nov 3 03:03:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA14884 for hackers-outgoing; Sun, 3 Nov 1996 03:03:20 -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 DAA14877 for ; Sun, 3 Nov 1996 03:03:15 -0800 (PST) Message-Id: <199611031103.DAA14877@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA042758993; Sun, 3 Nov 1996 22:03:13 +1100 From: Darren Reed Subject: Re: "Thrashing" index To: julian@whistle.com (Julian Elischer) Date: Sun, 3 Nov 1996 22:03:13 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <3278025C.41C67EA6@whistle.com> from "Julian Elischer" at Oct 30, 96 05:35:24 pm 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 Julian Elischer, sie said: > > Does anyone have any ideas on how to describe or detirmine the > amount of thrashing going on on a machine? > > one thing I can think of would be to count the number of processes > sitting in 'vmwait' state, or to look at teh page-in and page-out > numbers, but hte problem with the second approach is that > you need to look twice separated by a time period, to detirmine if the > system is doing a lot of work and should not be asked to do more... > > basically I'm trying to make the system self limit when memory starts > to become in short supply, in combination with a few other events. > > for example.. If the cpu idle time is high, but there is not much > memory free, and there are processes in vmwait, then it's probably > not a good idea to launch more processes, as the system is probably > thrashing.. > > another index might be to find out how long it takes to allocate an 8K > region or similar.. > > but I think I'd like to find some way that you can look at (say) > 3 or 4 static indeces instantly available (e.g. through /proc or sysctl) > and munge them into a go/no-go decision for launching more work. So how do you, as the sys admin login or if logged in do anything about it ? From owner-freebsd-hackers Sun Nov 3 08:52:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA05931 for hackers-outgoing; Sun, 3 Nov 1996 08:52:09 -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 IAA05921 for ; Sun, 3 Nov 1996 08:52:02 -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 RAA25843; Sun, 3 Nov 1996 17:51:35 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA03223; Sun, 3 Nov 1996 17:51:29 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id RAA03607; Sun, 3 Nov 1996 17:37:39 +0100 (MET) From: J Wunsch Message-Id: <199611031637.RAA03607@uriah.heep.sax.de> Subject: Re: IDE CDROM support To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sun, 3 Nov 1996 17:37:39 +0100 (MET) Cc: rhoward@kryten.WOC.ATINC.COM (Robert Howard) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Robert Howard at "Nov 2, 96 10:46:05 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 Robert Howard wrote: (Please, break up your long lines to a reasonable length.) > First, I could not find either the atapi.flp or the atapiflp.bat > files on the CDROM. I performed a search of the entire CDROM after They are no longer there. They were a kludge just for 2.1R only. > I have rebuilt the kerrnel half a dozen times or more following both > the directions in the "handbook" and variations that I got when I > enlisted local experts. I have the CDROM board on IRQ 15. The > CDROM drive has is in the slave configuration When I attempt to > mount it using either "mount" or "mount_9660" I receive the error > message: > "device not configured" Seems your CDROM drive was not recognized. The 2.1.5 ATAPI CDROM code wasn't really good, some improvements have been made meanwhile. So you might want to give the bootfloppy of one of the newer SNAPs a try. I'm not an ATAPI expert, but just FYI, i found this in Usenet today: Subject: Re: ATAPI CDROM Help needed: "atapi0.1: unknown phase" Newsgroups: comp.unix.bsd.freebsd.misc Date: 28 Oct 1996 19:22:44 GMT Organization: University at Buffalo Message-ID: <553164$18@prometheus.acsu.buffalo.edu> From: pleung@cs.buffalo.edu (Patrick Leung) Burton Sampley (bsampley@best.com) wrote: : message "unknown phase" he said FBSD could not "read/use" my cdrom. I : had a cheap 2X IDE (generic brand) cdrom. My solution was to purchase a That's because not all IDE drives are fully ATAPI compatible, even if it says ATAPI, especially drives that are below 4X. The newer IDE CD roms, 4X and 8X tend to follow to ATAPI standard more closely than the old ones. That's why you will have a better chance of getting a new CD drive to work than an old one. : new IDE cdrom. I found a Sony CDU311 8X EIDE cdrom for about $105.00 : USD at a local computer shop. That solved the problem. I hope this : helps. Oh, one other thing, make sure the cdrom drive is the slave : drive. I've heard this is the only way FBSD can use an IDE cdrom (don't I also have my cdrom mounted as slave. From owner-freebsd-hackers Sun Nov 3 12:09:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA18995 for hackers-outgoing; Sun, 3 Nov 1996 12:09:04 -0800 (PST) Received: from gvr.win.tue.nl (gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA18966 for ; Sun, 3 Nov 1996 12:08:49 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id VAA24228; Sun, 3 Nov 1996 21:07:08 +0100 (MET) From: Guido van Rooij Message-Id: <199611032007.VAA24228@gvr.win.tue.nl> Subject: Re: vx driver(s) - bad powerup behaviour In-Reply-To: from Hellmuth Michaelis at "Nov 1, 96 10:46:20 am" To: hm@kts.org Date: Sun, 3 Nov 1996 21:07:08 +0100 (MET) 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 > Just got some 3Com 590 ethernet PCI boards (because they were the cause of > some severe troubles under Gates-OS'es :-) ). Under 2.1.5, with the supplied > driver, with Guido's new driver from freefall and with another driver from > Fred Gray this card does not run after a cold reset or powerup on the > machine in question. > > Another warm boot is required to make this card run with all three drivers. > > Has anybody an idea what to try or where to look ? > > Is technical documentation available for this card somewhere ? Yes. Use the 3com fax service. It's handy. -Guido From owner-freebsd-hackers Sun Nov 3 12:10:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA19093 for hackers-outgoing; Sun, 3 Nov 1996 12:10:04 -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 MAA19087; Sun, 3 Nov 1996 12:10:02 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id MAA08146 ; Sun, 3 Nov 1996 12:08:32 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id VAA24219; Sun, 3 Nov 1996 21:06:37 +0100 (MET) From: Guido van Rooij Message-Id: <199611032006.VAA24219@gvr.win.tue.nl> Subject: Re: vx driver(s) - bad powerup behaviour In-Reply-To: from Hellmuth Michaelis at "Nov 1, 96 11:42:36 am" To: hm@kts.org Date: Sun, 3 Nov 1996 21:06:36 +0100 (MET) Cc: sos@freebsd.org, hm@kts.org, 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 Hellmuth Michaelis wrote: > sos@FreeBSD.org wrote: > > > > Just got some 3Com 590 ethernet PCI boards (because they were the cause of > > > some severe troubles under Gates-OS'es :-) ). Under 2.1.5, with the supplied > > > driver, with Guido's new driver from freefall and with another driver from > > > Fred Gray this card does not run after a cold reset or powerup on the > > > machine in question. > > > > Hmm, I see no such problems, are you sure the card in question is > > not one of those first defective ones ?? that would explain why > > billyboys os'es has trouble too. > > Probably it is one of those defective ones - the coldboot probe says its > an early revision adaptor and the warmboot probe does not say it. That is impossible. I think you are using the old driver where the test for the error was done wrong. -Guido From owner-freebsd-hackers Sun Nov 3 12:16:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA19404 for hackers-outgoing; Sun, 3 Nov 1996 12:16:47 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA19166; Sun, 3 Nov 1996 12:11:34 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id VAA24264; Sun, 3 Nov 1996 21:11:07 +0100 (MET) From: Guido van Rooij Message-Id: <199611032011.VAA24264@gvr.win.tue.nl> Subject: Re: vx driver(s) - bad powerup behaviour In-Reply-To: <199611030507.OAA29066@sirius.sbl.cl.nec.co.jp> from Naoki Hamada at "Nov 3, 96 02:07:20 pm" To: nao@sbl.cl.nec.co.jp (Naoki Hamada) Date: Sun, 3 Nov 1996 21:11:06 +0100 (MET) Cc: sos@freebsd.org, sos@ravenock.cybercity.dk, joerg_wunsch@uriah.heep.sax.de, j@uriah.heep.sax.de, gena@NetVision.net.il, terry@lambert.org, hm@kts.org, 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 Naoki Hamada wrote: > I wrote: > >http://jp.freebsd.org/pub/FreeBSD/incoming/vx.tar.gz. > > Sorry, not http but ftp. Patches for 2.1.5-RELEASE and 2.2-961014-SNAP > (applicable to FreeBSD-current with subtle change) are available. > > >The new vx driver supports 3C590 Etherlink III PCI, 3C595 Fast > >Etherlink PCI, 3C592 Etherlink III EISA and 3C597 Fast Etherlink > >EISA. Early support for 3C900 Etherlink XL PCI and 3C905 Fast > >Etherlink XL PCI is also incorporated. > > After intensive tests by several testers, this driver is quite stable > and should replace current vx driver, which is a font of > troubles. Could someone commit it to FreeBSD-2.2-RELEASE and > FreeBSD-stable branches? > Send the latest version to me and I'll commit all of it. -Guido From owner-freebsd-hackers Sun Nov 3 12:19:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA19516 for hackers-outgoing; Sun, 3 Nov 1996 12:19:19 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA19263; Sun, 3 Nov 1996 12:13:53 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id VAA24248; Sun, 3 Nov 1996 21:09:42 +0100 (MET) From: Guido van Rooij Message-Id: <199611032009.VAA24248@gvr.win.tue.nl> Subject: Re: vx driver(s) - bad powerup behaviour In-Reply-To: <199611011833.LAA28106@phaeton.artisoft.com> from Terry Lambert at "Nov 1, 96 11:33:05 am" To: terry@lambert.org (Terry Lambert) Date: Sun, 3 Nov 1996 21:09:41 +0100 (MET) Cc: sos@FreeBSD.org, gena@NetVision.net.il, freebsd-hackers@FreeBSD.org, hm@kts.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 Terry Lambert wrote: > > > vx0 <3Com 3c590 EtherLink III PCI> rev 0 int a irq 9 on pci0:11 > > > utp[*UTP*] address 0:20:af:f7:f2:dd > > > Warning! Defective early revision adapter! > > > > I'm afraid that you have on of the early defective cards then :( > > Try to see if you can get this verified with the dealer, they > > should exchange it for a new one (at least here in DK they _should_) > > Is it utterly impossible to send or receive packets with the early > revision adapters? > No it isn;t. There is an overflow when receiving packets if memory serves me right. > Or is the driver just insufficient to the task? > Yep. I do have a description of what can be done to work around the bug though. No intention of doing it. If someone wnats to, I can send hime the stuff. Btw: did anyone try the driver on -current? If it works, then I want to commit the thing. -Guido From owner-freebsd-hackers Sun Nov 3 13:10:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24474 for hackers-outgoing; Sun, 3 Nov 1996 13:10:05 -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 NAA23116; Sun, 3 Nov 1996 13:07:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03152; Sun, 3 Nov 1996 14:00:34 -0700 From: Terry Lambert Message-Id: <199611032100.OAA03152@phaeton.artisoft.com> Subject: Re: ed0 timeouts To: smp@csn.net (Steve Passe) Date: Sun, 3 Nov 1996 14:00:34 -0700 (MST) Cc: dg@Root.COM, hackers@freefall.freebsd.org, smp@freefall.freebsd.org, bde@zeta.org.au In-Reply-To: <199611030900.CAA25770@clem.systemsix.com> from "Steve Passe" at Nov 3, 96 02:00:44 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 > > Yes, you can get another interrupt while servicing one. The driver loops > >until all interrupts are serviced, but there would be a window between when it > >thinks there are no more interrupts to service and returning to vector.s to > >unmask the interrupts. This window will exist in all ISA drivers. > > bummer... > > Intel says: > > It is strongly recommended that first 82489 (ie APIC) should be unmasked > and then the device interrupt should be enabled. By this sequence software > can ensure that always an edge will occur at the APIC input only after > the interrupt is unmasked. Or: "Don't ack the thing until fater it's unmasked". 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 3 13:11:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA25332 for hackers-outgoing; Sun, 3 Nov 1996 13:11:53 -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 NAA25305 for ; Sun, 3 Nov 1996 13:11:33 -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 NAA10511 for ; Sun, 3 Nov 1996 13:11:20 -0800 (PST) Message-Id: <199611032111.NAA10511@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: Geomview, Mbone and FreeBSD... Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="===_0_Sun_Nov__3_13:11:14_PST_1996" Date: Sun, 03 Nov 1996 13:11:20 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multipart MIME message. --===_0_Sun_Nov__3_13:11:14_PST_1996 Content-Type: text/plain; charset=us-ascii Are there any stdio experts which can lend a hand in porting Geomview? Bill and a couple of people have develop a cool interface to track mbone traffic using a 3d map of the world showing off the tunnels as ballistic trajectories. At any rate, the file giving us a problem is futil.c . It likes to manipulate the stdio data structures and does seeks on stdio. Here is the file and if requested I can give out a pointer to the Geomview tar file: --===_0_Sun_Nov__3_13:11:14_PST_1996 Content-Type: application/octet-stream Content-Description: futil.c Content-Transfer-Encoding: base64 LyogQ29weXJpZ2h0IChjKSAxOTkyIFRoZSBHZW9tZXRyeSBDZW50ZXI7IFVuaXZlcnNpdHkg b2YgTWlubmVzb3RhCiAgIDEzMDAgU291dGggU2Vjb25kIFN0cmVldDsgIE1pbm5lYXBvbGlz LCBNTiAgNTU0NTQsIFVTQTsKICAgClRoaXMgZmlsZSBpcyBwYXJ0IG9mIGdlb212aWV3L09P R0wuIGdlb212aWV3L09PR0wgaXMgZnJlZSBzb2Z0d2FyZTsKeW91IGNhbiByZWRpc3RyaWJ1 dGUgaXQgYW5kL29yIG1vZGlmeSBpdCBvbmx5IHVuZGVyIHRoZSB0ZXJtcyBnaXZlbiBpbgp0 aGUgZmlsZSBDT1BZSU5HLCB3aGljaCB5b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYWxvbmcg d2l0aCB0aGlzIGZpbGUuClRoaXMgYW5kIG90aGVyIHJlbGF0ZWQgc29mdHdhcmUgbWF5IGJl IG9idGFpbmVkIHZpYSBhbm9ueW1vdXMgZnRwIGZyb20KZ2VvbS51bW4uZWR1OyBlbWFpbDog c29mdHdhcmVAZ2VvbS51bW4uZWR1LiAqLwpzdGF0aWMgY2hhciAqY29weXJpZ2h0ID0gIkNv cHlyaWdodCAoQykgMTk5MiBUaGUgR2VvbWV0cnkgQ2VudGVyIjsKCi8qIEF1dGhvcnM6IENo YXJsaWUgR3VubiwgU3R1YXJ0IExldnksIFRhbWFyYSBNdW56bmVyLCBNYXJrIFBoaWxsaXBz ICovCgovKiAkSGVhZGVyOiAvdS9nY2cvbmdyYXAvc3JjL2xpYi9vb2dsL3V0aWwvUkNTL2Z1 dGlsLmMsdiAxLjMyIDE5OTQvMDgvMjYgMDQ6MTE6Mjcgc2xldnkgRXhwICQgKi8KCi8qCiAq IEdlb21ldHJ5IG9iamVjdCByb3V0aW5lcwogKgogKiBVdGlsaXR5IHJvdXRpbmVzLCB1c2Vm dWwgZm9yIG1hbnkgb2JqZWN0cwogKgogKiBpbnQKICogZmdldG5mKGZpbGUsIG5mbG9hdHMs IGZsb2F0cCwgYmluYXJ5KQogKglSZWFkIGFuIGFycmF5IG9mIGZsb2F0cyBmcm9tIGEgZmls ZSBpbiAiYXNjaWkiIG9yICJiaW5hcnkiIGZvcm1hdC4KICoJUmV0dXJucyBudW1iZXIgb2Yg ZmxvYXRzIHN1Y2Nlc3NmdWxseSByZWFkLCBzaG91bGQgPSBuZmxvYXRzLgogKgkiQmluYXJ5 IiBtZWFucyAiSUVFRSAzMi1iaXQgZmxvYXRpbmctcG9pbnQiIGZvcm1hdC4KICoKICogaW50 CiAqIGZnZXRuaShGSUxFICpmaWxlLCBpbnQgbmludHMsIGludCAqaW50c3AsIGludCBiaW5h cnkpCiAqCVJlYWQgYW4gYXJyYXkgb2YgaW50cyBmcm9tIGEgZmlsZSBpbiAiYXNjaWkiIG9y ICJiaW5hcnkiIGZvcm1hdC4KICoJUmV0dXJucyBudW1iZXIgb2YgaW50cyBzdWNjZXNzZnVs bHkgcmVhZCwgc2hvdWxkID0gbmludHMuCiAqCSJCaW5hcnkiIG1lYW5zICIzMi1iaXQgYmln LWVuZGlhbiIgaW50ZWdlciBmb3JtYXQuCiAqCiAqIGludAogKiBmZ2V0bnMoRklMRSAqZmls ZSwgaW50IG5zaG9ydHMsIHNob3J0ICppbnRzcCwgaW50IGJpbmFyeSkKICoJUmVhZCBhbiBh cnJheSBvZiBzaG9ydHMgZnJvbSBhIGZpbGUgaW4gImFzY2lpIiBvciAiYmluYXJ5IiBmb3Jt YXQuCiAqCVJldHVybnMgbnVtYmVyIG9mIHNob3J0cyBzdWNjZXNzZnVsbHkgcmVhZCwgc2hv dWxkID0gbmludHMuCiAqCSJCaW5hcnkiIG1lYW5zICIxNi1iaXQgYmlnLWVuZGlhbiIgaW50 ZWdlciBmb3JtYXQuCiAqCiAqIGludAogKiBmZXhwZWN0c3RyKEZJTEUgKmZpbGUsIGNoYXIg KnN0cmluZykKICoJRXhwZWN0IHRoZSBnaXZlbiBzdHJpbmcgdG8gYXBwZWFyIGltbWVkaWF0 ZWx5IG9uIGZpbGUuCiAqCVJldHVybiAwIGlmIHRoZSBjb21wbGV0ZSBzdHJpbmcgaXMgZm91 bmQsCiAqCWVsc2UgdGhlIG9mZnNldCsxIG9mIHRoZSBsYXN0IG1hdGNoZWQgY2hhciB3aXRo aW4gc3RyaW5nLgogKglUaGUgZmlyc3QgdW5tYXRjaGVkIGNoYXIgaXMgdW5nZXRjJ2QuCiAq CiAqIGludAogKiBmZXhwZWN0dG9rZW4oRklMRSAqZmlsZSwgY2hhciAqc3RyaW5nKQogKglF eHBlY3QgdGhlIGdpdmVuIHN0cmluZyB0byBhcHBlYXIgb24gdGhlIGZpbGUsIHBvc3NpYmx5 IGFmdGVyCiAqCXNraXBwaW5nIHNvbWUgd2hpdGUgc3BhY2UgYW5kIGNvbW1lbnRzLgogKglS ZXR1cm4gMCBpZiBmb3VuZCwgZWxzZSB0aGUgb2Zmc2V0KzEgb2YgbGFzdCBtYXRjaGVkIGNo YXIgaW4gc3RyaW5nLgogKglUaGUgZmlyc3QgdW5tYXRjaGVkIGNoYXIgaXMgdW5nZXRjJ2Qu CiAqCiAqIGludCBmbmV4dGMoRklMRSAqZiwgaW50IGZsYWdzKQogKglBZHZhbmNlcyBmIHRv IHRoZSBuZXh0ICJpbnRlcmVzdGluZyIgY2hhcmFjdGVyIGFuZAogKglyZXR1cm5zIGl0LiAg VGhlIHJldHVybmVkIGNoYXIgaXMgdW5nZXRjJ2VkIHNvIHRoZSBuZXh0IGdldGMoKQogKgl3 aWxsIHlpZWxkIHRoZSBzYW1lIHZhbHVlLgogKglJbnRlcmVzdGluZyBkZXBlbmRzIG9uIGZs YWdzOgogKgkgIDAgOiBTa2lwIGJsYW5rcywgdGFicywgbmV3bGluZXMsIGFuZCBjb21tZW50 cyAoIy4uLlxuKS4KICoJICAxIDogU2tpcCBibGFua3MsIHRhYnMsIGFuZCBjb21tZW50cywg YnV0IG5ld2xpbmVzIGFyZSBpbnRlcmVzdGluZwogKgkJKGluY2x1ZGluZyB0aGUgXG4gdGhh dCB0ZXJtaW5hdGVzIGEgY29tbWVudCkuCiAqCSAgMiA6IFNraXAgYmxhbmtzLCB0YWJzLCBh bmQgbmV3bGluZXMsIGJ1dCBzdG9wIGF0ICMuCiAqCSAgMyA6IFNraXAgYmxhbmtzIGFuZCB0 YWJzIGJ1dCBzdG9wIGF0ICMgb3IgXG4uCiAqCiAqIGludCBhc3luY19mbmV4dGMoRklMRSAq ZiwgaW50IGZsYWdzKQogKglMaWtlIGZuZXh0YygpIGFib3ZlLCBidXQgZ3VhcmFudGVlcyBu b3QgdG8gYmxvY2sgaWYgbm8gZGF0YSBpcwogKglpbW1lZGlhdGVseSBhdmFpbGFibGUuICBJ dCByZXR1cm5zIGVpdGhlciBhbiBpbnRlcmVzdGluZyBjaGFyYWN0ZXIsCiAqCUVPRiwgb3Ig dGhlIHNwZWNpYWwgY29kZSBOT0RBVEEgKD09IC0yKS4KICoKICogaW50IGFzeW5jX2dldGMo RklMRSAqZikKICoJTGlrZSBnZXRjKCksIGJ1dCBndWFyYW50ZWVzIG5vdCB0byBibG9jay4g IFJldHVybnMgTk9EQVRBIGlmCiAqCW5vdGhpbmcgaXMgaW1tZWRpYXRlbHkgYXZhaWxhYmxl LgogKgogKiBjaGFyICpmdG9rZW4oRklMRSAqZiwgaW50IGZsYWdzKQogKglTa2lwcyB1bmlu dGVyZXN0aW5nIGNoYXJhY3RlcnMgd2l0aCBmbmV4dGMoZiwgZmxhZ3MpLAogKgl0aGVuIHJl dHVybnMgYSAidG9rZW4iIC0gc3RyaW5nIG9mIGNvbnNlY3V0aXZlIGludGVyZXN0aW5nIGNo YXJhY3RlcnMuCiAqCVJldHVybnMgTlVMTCBpZiBFT0YgaXMgcmVhY2hlZCB3aXRoIG5vIHRv a2VuLCBvciBpZgogKglmbGFncyBzcGVjaWZpZXMgc3RvcHBpbmcgYXQgZW5kLW9mLWxpbmUg YW5kIHRoaXMgaXMgZW5jb3VudGVyZWQgd2l0aAogKglubyB0b2tlbiBmb3VuZC4KICoJVGhl IHRva2VuIGlzIGVmZmVjdGl2ZWx5IHN0YXRpY2FsbHkgYWxsb2NhdGVkIGFuZCB3aWxsIGJl CiAqCW92ZXJ3cml0dGVuIGJ5IHRoZSBuZXh0IGZ0b2tlbigpIGNhbGwuCiAqCiAqIGNoYXIg KmZkZWxpbXRvayhjaGFyICpkZWxpbXMsIEZJTEUgKmYsIGludCBmbGFncykKICoJTGlrZSBm dG9rZW4oKSwgYnV0IHNwZWNpYWxseSBoYW5kbGVzIHRoZSBjaGFyYWN0ZXJzIGluIGRlbGlt c1tdLgogKglJZiBvbmUgYXBwZWFycyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSB0b2tlbiwg aXQncyByZXR1cm5lZCBhcyAKICoJYSBzaW5nbGUtY2hhcmFjdGVyIHRva2VuLgogKglJZiBh IG1lbWJlciBvZiBkZWxpbXNbXSBhcHBlYXJzIGFmdGVyIG90aGVyIGNoYXJhY3RlcnMgaGF2 ZSBiZWVuCiAqCWFjY3VtdWxhdGVkLCBpdCdzIGNvbnNpZGVyZWQgdG8gdGVybWluYXRlIHRo ZSB0b2tlbi4KICoJU28gc3VjY2Vzc2l2ZSBjYWxscyB0byBmZGVsaW10b2soIigpIiwgZiwg MCkKICoJb24gYSBmaWxlIGNvbnRhaW5pbmcgIChmcmVkIHNtaXRoKQogKgl3b3VsZCByZXR1 cm4gIigiLCAiZnJlZCIsICJzbWl0aCIsIGFuZCAiKSIuCiAqCUJlaGF2aW9yIGlzIHVuZGVm aW5lZCBpZiBvbmUgb2YgdGhlIHByZWRlZmluZWQgZGVsaW1pdGVycwogKgkod2hpdGUgc3Bh Y2Ugb3IgIykgYXBwZWFycyBpbiBkZWxpbXNbXS4gIEV4cGxpY2l0IHF1b3RpbmcKICoJKHdp dGggIiwgJyBvciBcKSBvdmVycmlkZXMgZGV0ZWN0aW9uIG9mIGRlbGltaXRlcnMuCiAqCiAq IGludCBmZ2V0dHJhbnNmb3JtKEZJTEUgKmYsIGludCBudHJhbnNmb3JtcywgZmxvYXQgKnRy YW5zZm9ybXMsIGludCBiaW5hcnkpCiAqCVJlYWRzIDR4NCBtYXRyaWNlcyBmcm9tIEZJTEUu ICBSZXR1cm5zIHRoZSBudW1iZXIgb2YgbWF0cmljZXMgZm91bmQsCiAqCXVwIHRvIG50cmFu c2Zvcm1zLiAgUmV0dXJucyAwIGlmIG5vIG51bWJlcnMgYXJlIGZvdW5kLgogKglPbiBmaW5k aW5nIGluY29tcGxldGUgbWF0cmljZXMgKG5vdCBhIG11bHRpcGxlIG9mIDE2IGZsb2F0cykK ICoJcmV0dXJucyAtMSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFueSB3aG9sZSBtYXRyaWNl cyB3ZXJlIGZvdW5kLgogKglNYXRyaWNlcyBhcmUgZXhwZWN0ZWQgaW4gdGhlIGZvcm0gdXNl ZCB0byB0cmFuc2Zvcm0gYSByb3cgdmVjdG9yCiAqCW11bHRpcGxpZWQgb24gdGhlIGxlZnQs IGkuZS4gIHAgKiBUIC0+IHAnOyB0aHVzIEV1Y2xpZGVhbiB0cmFuc2xhdGlvbnMKICoJYXBw ZWFyIGluIHRoZSBsYXN0IHJvdy4KICoKICogaW50IGZwdXR0cmFuc2Zvcm0oRklMRSAqZiwg aW50IG50cmFuc2Zvcm1zLCBmbG9hdCAqdHJhbnNmb3JtcywgaW50IGJpbmFyeSkKICoJV3Jp dGVzIDR4NCBtYXRyaWNlcyB0byBGSUxFLiAgUmV0dXJucyB0aGUgbnVtYmVyIHdyaXR0ZW4s IGkuZS4KICoJbnRyYW5zZm9ybXMgdW5sZXNzIGFuIGVycm9yIG9jY3Vycy4KICoKICogaW50 IGZwdXRuZihGSUxFICpmLCBpbnQgbmZsb2F0cywgZmxvYXQgKmZ2LCBpbnQgYmluYXJ5KQog KglXcml0ZXMgJ25mbG9hdHMnIGZsb2F0cyB0byB0aGUgZ2l2ZW4gZmlsZS4gIEFTQ0lJIGlz IGluICVnIGZvcm1hdCwKICoJc2VwYXJhdGVkIGJ5IGJsYW5rcy4KICoKICogRklMRSAqZnN0 cm9wZW4oc3RyLCBsZW4sIG1vZGUpCiAqCU9wZW5zIGEgc3RyaW5nIChidWZmZXIpIGFzIGEg ImZpbGUiLgogKglNb2RlIGlzICJyIiBvciAidyIgYXMgdXN1YWwuCiAqCVJlYWRzIHNob3Vs ZCByZXR1cm4gRU9GIG9uIGVuY291bnRlcmluZyBlbmQtb2Ytc3RyaW5nLAogKgl3cml0ZXMg cGFzdCBlbmQtb2Ytc3RyaW5nIHNob3VsZCBhbHNvIHlpZWxkIGFuIGVycm9yIHJldHVybi4K ICoJZmNsb3NlKCkgc2hvdWxkIGJlIHVzZWQgdG8gZnJlZSB0aGUgRklMRSBhZnRlciB1c2Uu CiAqLwoKCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CiNpbmNs dWRlIDxzeXMvdGltZS5oPgojaW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxzdHJpbmcu aD4KI2lmbmRlZiBOZVhUCiNpbmNsdWRlIDx1bmlzdGQuaD4KI2VuZGlmCiNpZmRlZiBBSVgK I2luY2x1ZGUgPHN5cy9zZWxlY3QuaD4KI2VuZGlmCiNpbmNsdWRlIDxjdHlwZS5oPgojaW5j bHVkZSAib29nbHV0aWwuaCIKCiAgIC8qIFNwZWVkeSBiaW5hcnkgSS9PIGlmIHRoZSBtYWNo aW5lIGlzIGtub3duIHRvIGJlIGJpZy1lbmRpYW4gKi8KI2lmIG02OGsgfHwgbWM2ODAwMCB8 fCBtaXBzIHx8IHNwYXJjIHx8IGhwdXggfHwgQUlYCiMgZGVmaW5lIEJJR19FTkRJQU4gMQoj ZW5kaWYKCiNpZm5kZWYgQklHX0VORElBTgojIGluY2x1ZGUgPG5ldGluZXQvaW4uaD4JLyog Zm9yIG50b2hsKCksIGV0Yy4gKi8KI2VuZGlmCgojaWZkZWYgaHB1eAkvKiBIYWNrIG5hbWVz IG9mIHN0ZGlvIGJ1ZmZlciBmaWVsZHMgKi8KI2RlZmluZSBfY250IF9fY250CiNkZWZpbmUg X2Jhc2UgX19iYXNlCiNkZWZpbmUgX3B0ciBfX3B0cgojZW5kaWYgCgojaWZkZWYgX19GcmVl QlNEX18JLyogWFhYIHdjZiBhY3R1YWxseSA0LjQgQlNELCB0aGlzIGlzIGp1c3QgYSBndWVz cyAqLwojZGVmaW5lIF9jbnQJX2JmLl9zaXplCiNkZWZpbmUgX2Jhc2UJX2JmLl9iYXNlCiNk ZWZpbmUJX3B0cglfcAojZGVmaW5lIF9mbGFnCV9mbGFncwojZGVmaW5lIF9JT01ZQlVGCTAK I2RlZmluZSBfSU9FT0YJX19TRU9GCiNkZWZpbmUgX0lPRVJSCV9fU0VSUgojZW5kaWYKCiNp ZiBkZWZpbmVkKF9fbGludXhfXykgJiYgIWRlZmluZWQoX0lPX1NURElPX0gpCgkvKiBIYW5k bGUgb2xkZXIgKHByZS0xLjApIExpbnV4IHN0ZGlvIGZpZWxkcywKCSAqIG1ha2luZyB0aGVt IGxvb2sgbGlrZSBsYXRlciBvbmVzLgoJICovCiNkZWZpbmUJIF9JT19yZWFkX2Jhc2UJX2Jh c2UKI2RlZmluZSAgX0lPX3JlYWRfcHRyCV9ncHRyCiNkZWZpbmUJIF9JT19yZWFkX2VuZAlf ZWdwdHIKI2VuZGlmCgoJLyogUGVlciBpbnRvIGEgc3RkaW8gYnVmZmVyLCBjaGVjayB3aGV0 aGVyIGl0IGhhcyBkYXRhIGF2YWlsYWJsZQoJICogZm9yIHJlYWRpbmcuICBBbG1vc3QgcG9y dGFibGUgZ2l2ZW4gdGhlIGNvbW1vbiBzdGRpbyBhbmNlc3RyeS4KCSAqLwojaWZkZWYgX19s aW51eF9fCiNkZWZpbmUgRl9IQVNEQVRBKGYpICAoKGYpLT5fSU9fcmVhZF9wdHIgPCAoZikt Pl9JT19yZWFkX2VuZCkKI2Vsc2UKI2RlZmluZSBGX0hBU0RBVEEoZikgICgoZiktPl9jbnQg PiAwKQojZW5kaWYKCgppbnQKZm5leHRjKEZJTEUgKmYsIGludCBmbGFncykKewoJcmVnaXN0 ZXIgaW50IGM7CgoJYyA9IGdldGMoZik7Cglmb3IoOzspIHsKCSAgICBzd2l0Y2goYykgewoJ ICAgIGNhc2UgRU9GOgoJCXJldHVybihFT0YpOwoKCSAgICBjYXNlICcgJzoKCSAgICBjYXNl ICdcdCc6CgkJYnJlYWs7CQkJLyogQWx3YXlzIHNraXAgYmxhbmtzIGFuZCB0YWJzICovCgoJ ICAgIGNhc2UgJyMnOgoJCWlmKGZsYWdzICYgMikJCS8qIDI6IHN0b3Agb24gY29tbWVudHMs IGVsc2Ugc2tpcCAqLwoJCSAgICBnb3RvIGZpbTsKCgkJd2hpbGUoKGMgPSBnZXRjKGYpKSAh PSAnXG4nICYmIGMgIT0gRU9GKQoJCSAgICA7CgkJY29udGludWU7CQkvKiBSZXNjYW4gdGhp cyBjICovCgoJICAgIGNhc2UgJ1xuJzoKCQlpZighKGZsYWdzICYgMSkpCS8qIDE6IHN0b3Ag b24gXG4ncywgZWxzZSBza2lwIHRoZW0gKi8KCQkgICAgYnJlYWs7CgkJCQkJLyogZmxhZ3Mm MSA9PiBmYWxsIGludG8gZGVmYXVsdCAqLwoKCSAgICBkZWZhdWx0OgoJICAgICBmaW06CgkJ dW5nZXRjKGMsIGYpOwoJCXJldHVybihjKTsKCSAgICB9CgoJICAgIGMgPSBnZXRjKGYpOwoJ fQp9CgoKZmxvYXQgZl9wb3cxMFsxMV0gPSB7IDFlMCwgMWUxLCAxZTIsIDFlMywgMWU0LCAx ZTUsIDFlNiwgMWU3LCAxZTgsIDFlOSwgMWUxMCB9OwoKI2RlZmluZSBmUG93MTAobikgICgo dW5zaWduZWQpKG4pID4gMTAgPyBmcG93MTAobikgOiBmX3BvdzEwW25dKQoKZmxvYXQKZnBv dzEwKGludCBuKQp7CglyZWdpc3RlciBpbnQgazsKCXJlZ2lzdGVyIGZsb2F0IHY7CgoJaWYo KGsgPSBuKSA8IDApCgkJayA9IC1rOwoJdiA9IGZfcG93MTBbayAmIDddOwoJaWYoayA+PSA4 KSB7CgkJZmxvYXQgdW5pdCA9IDFlODsKCgkJayA+Pj0gMzsKCQlmb3IoOzspIHsKCQkJaWYo ayAmIDEpCgkJCQl2ICo9IHVuaXQ7CgkJCWlmKChrID4+PSAxKSA9PSAwKQoJCQkJYnJlYWs7 CgkJCXVuaXQgKj0gdW5pdDsKCQl9Cgl9CglyZXR1cm4obiA8IDAgPyAxLjAvdiA6IHYpOwp9 CgovKgogKiBSZWFkIGFuIGFycmF5IG9mIHdoaXRlLXNwYWNlLXNlcGFyYXRlZCBmbG9hdHMg ZnJvbSBmaWxlICdmJyBpbiBBU0NJSSwgZmFzdC4KICogUmV0dXJucyB0aGUgbnVtYmVyIHN1 Y2Nlc3NmdWxseSByZWFkLgogKi8KaW50CmZnZXRuZihyZWdpc3RlciBGSUxFICpmLCBpbnQg bWF4ZiwgZmxvYXQgKmZ2LCBpbnQgYmluYXJ5KQp7CglpbnQgbmdvdDsKCWZsb2F0IHY7Cgly ZWdpc3RlciBpbnQgYyA9IEVPRjsKCXJlZ2lzdGVyIGxvbmcgbjsKCWxvbmcgdzsKCWludCBz LCBlcywgbmQsIGFueTsKCglpZihiaW5hcnkpIHsKI2lmIEJJR19FTkRJQU4KCQkvKiBFYXN5 IC0tIG91ciBuYXRpdmUgZmxvYXRpbmcgcG9pbnQgPT0gYmlnLWVuZGlhbiBJRUVFICovCgkJ cmV0dXJuIGZyZWFkKChjaGFyICopZnYsIHNpemVvZihmbG9hdCksIG1heGYsIGYpOwojZWxz ZSAvKiBub3QgbmF0aXZlIGJpZy1lbmRpYW4gSUVFRSAqLwoJCWZvcihuPTA7IG48bWF4ZiAm JiBmcmVhZCgoY2hhciAqKSZ3LHNpemVvZihsb25nKSwxLGYpID4gMDsgbisrKQoJCSAgICAq KGxvbmcgKikmZnZbbl0gPSBudG9obCh3KTsKCQlyZXR1cm4gbjsKI2VuZGlmIC8qIG5vdCBu YXRpdmUgYmlnLWVuZGlhbiBJRUVFICovCgl9CgoJLyogUmVhZCBBU0NJSSBmb3JtYXQgZmxv YXRzICovCglmb3IobmdvdCA9IDA7IG5nb3QgPCBtYXhmOyBuZ290KyspIHsKCQlpZihmbmV4 dGMoZiwgMCkgPT0gRU9GKQoJCQlyZXR1cm4obmdvdCk7CgkJbiA9IDA7CgkJcyA9IDA7CgkJ bmQgPSAwOwoJCWFueSA9IDA7CgkJaWYoKGMgPSBnZXRjKGYpKSA9PSAnLScpIHsKCQkJcyA9 IDE7CgkJCWMgPSBnZXRjKGYpOwoJCX0KCQl3aGlsZShjID49ICcwJyAmJiBjIDw9ICc5Jykg ewoJCQluID0gbioxMCArIGMgLSAnMCc7CgkJCW5kKys7CgkJCWlmKG4gPj0gMjE0NzQ4MzY0 KSB7CS8qIDJeMzEgLyAxMCAqLwoJCQkJdiA9IGFueSA/IHYqZlBvdzEwKG5kKSArIChmbG9h dCluIDogKGZsb2F0KW47CgkJCQluZCA9IG4gPSAwOwoJCQkJYW55ID0gMTsKCQkJfQoJCQlj ID0gZ2V0YyhmKTsKCQl9CgkJdiA9IGFueSA/IHYqZlBvdzEwKG5kKSArIChmbG9hdCluIDog KGZsb2F0KW47CgkJYW55ICs9IG5kOwoJCWlmKGMgPT0gJy4nKSB7CgkJCW5kID0gbiA9IDA7 CgkJCXdoaWxlKChjID0gZ2V0YyhmKSkgPj0gJzAnICYmIGMgPD0gJzknKSB7CgkJCQluID0g bioxMCArIGMgLSAnMCc7CgkJCQluZCsrOwoJCQkJaWYobiA+PSAyMTQ3NDgzNjQpIHsKCQkJ CQl2ICs9IChmbG9hdCluIC8gZlBvdzEwKG5kKTsKCQkJCQluID0gMDsKCQkJCX0KCQkJfQoJ CQl2ICs9IChmbG9hdCluIC8gZlBvdzEwKG5kKTsKCQl9CgkJaWYoYW55ID09IDAgJiYgbmQg PT0gMCkKCQkJYnJlYWs7CgkJaWYoYyA9PSAnZScgfHwgYyA9PSAnRScpIHsKCQkJZXMgPSBu ZCA9IDA7CgkJCXN3aXRjaChjID0gZ2V0YyhmKSkgewoJCQljYXNlICctJzoKCQkJCWVzID0g MTsJLyogQW5kIGZhbGwgdGhyb3VnaCAqLwoJCQljYXNlICcrJzoKCQkJCWMgPSBnZXRjKGYp OwoJCQl9CgkJCW4gPSAwOwoJCQl3aGlsZShjID49ICcwJyAmJiBjIDw9ICc5JykgewoJCQkJ biA9IG4qMTAgKyBjIC0gJzAnOwoJCQkJbmQrKzsKCQkJCWMgPSBnZXRjKGYpOwoJCQl9CgkJ CWlmKG5kID09IDApCgkJCQlicmVhazsKCQkJaWYoZXMpIHYgLz0gZlBvdzEwKG4pOwoJCQll bHNlIHYgKj0gZlBvdzEwKG4pOwoJCX0KCQlmdltuZ290XSA9IHMgPyAtdiA6IHY7Cgl9Cglp ZihjIT1FT0YpIHVuZ2V0YyhjLCBmKTsKCXJldHVybihuZ290KTsKfQoKCmludApmZ2V0bmko cmVnaXN0ZXIgRklMRSAqZiwgaW50IG1heGksIGludCAqaXYsIGludCBiaW5hcnkpCnsKCWlu dCBuZ290OwoJcmVnaXN0ZXIgaW50IGMgPSBFT0Y7CglyZWdpc3RlciBsb25nIG47Cglsb25n IHc7CglpbnQgcywgYW55OwoKCWlmKGJpbmFyeSkgewojaWYgQklHX0VORElBTgoJCS8qIEVh c3kgLS0gb3VyIG5hdGl2ZSBmbG9hdGluZyBwb2ludCA9PSBiaWctZW5kaWFuIElFRUUgKi8K CQlyZXR1cm4gZnJlYWQoKGNoYXIgKilpdiwgc2l6ZW9mKGludCksIG1heGksIGYpOwojZWxz ZSAvKiBub3QgbmF0aXZlIGJpZy1lbmRpYW4gaW50J3MgKi8KCQlmb3IobiA9IDA7IG4gPCBt YXhpICYmIGZyZWFkKCZ3LDQsMSxmKSA+IDA7IG4rKykKCQkgICAgaXZbbl0gPSBudG9obCh3 KTsKCQlyZXR1cm4gbjsKI2VuZGlmIC8qIG5vdCBuYXRpdmUgYmlnLWVuZGlhbiBpbnQncyAq LwoJfQoKCS8qIFJlYWQgQVNDSUkgZm9ybWF0IGZsb2F0cyAqLwoJZm9yKG5nb3QgPSAwOyBu Z290IDwgbWF4aTsgbmdvdCsrKSB7CgkJaWYoZm5leHRjKGYsIDApID09IEVPRikKCQkJcmV0 dXJuKG5nb3QpOwoJCW4gPSAwOwoJCXMgPSAwOwoJCWFueSA9IDA7CgkJaWYoKGMgPSBnZXRj KGYpKSA9PSAnLScpIHsKCQkJcyA9IDE7CgkJCWMgPSBnZXRjKGYpOwoJCX0KCQl3aGlsZShj ID49ICcwJyAmJiBjIDw9ICc5JykgewoJCQluID0gbioxMCArIGMgLSAnMCc7CgkJCWFueSA9 IDE7CgkJCWMgPSBnZXRjKGYpOwoJCX0KCQlpZighYW55KQoJCQlicmVhazsKCQlpdltuZ290 XSA9IHMgPyAtbiA6IG47Cgl9CglpZihjIT1FT0YpIHVuZ2V0YyhjLCBmKTsKCXJldHVybihu Z290KTsKfQoKaW50CmZnZXRucyhyZWdpc3RlciBGSUxFICpmLCBpbnQgbWF4cywgc2hvcnQg KnN2LCBpbnQgYmluYXJ5KQp7CglpbnQgbmdvdDsKCXJlZ2lzdGVyIGludCBjID0gRU9GOwoJ cmVnaXN0ZXIgbG9uZyBuOwoJc2hvcnQgdzsKCWludCBzLCBhbnk7CgoJaWYoYmluYXJ5KSB7 CiNpZiBCSUdfRU5ESUFOCgkJLyogRWFzeSAtLSBvdXIgbmF0aXZlIGZsb2F0aW5nIHBvaW50 ID09IGJpZy1lbmRpYW4gSUVFRSAqLwoJCXJldHVybiBmcmVhZCgoY2hhciAqKXN2LCBzaXpl b2Yoc2hvcnQpLCBtYXhzLCBmKTsKI2Vsc2UgLyogbm90IG5hdGl2ZSBiaWctZW5kaWFuIGlu dCdzICovCgkJZm9yKG4gPSAwOyBuIDwgbWF4cyAmJiBmcmVhZCgmdywyLDEsZikgPiAwOyBu KyspCgkJICAgIHN2W25dID0gbnRvaHModyk7CgkJcmV0dXJuIG47CiNlbmRpZiAvKiBub3Qg bmF0aXZlIGJpZy1lbmRpYW4gaW50J3MgKi8KCX0KCgkvKiBSZWFkIEFTQ0lJIGZvcm1hdCBm bG9hdHMgKi8KCWZvcihuZ290ID0gMDsgbmdvdCA8IG1heHM7IG5nb3QrKykgewoJCWlmKGZu ZXh0YyhmLCAwKSA9PSBFT0YpCgkJCXJldHVybihuZ290KTsKCQluID0gcyA9IGFueSA9IDA7 CgkJaWYoKGMgPSBnZXRjKGYpKSA9PSAnLScpIHsKCQkJcyA9IDE7CgkJCWMgPSBnZXRjKGYp OwoJCX0KCQl3aGlsZShjID49ICcwJyAmJiBjIDw9ICc5JykgewoJCQluID0gbioxMCArIGMg LSAnMCc7CgkJCWFueSA9IDE7CgkJCWMgPSBnZXRjKGYpOwoJCX0KCQlpZighYW55KQoJCQli cmVhazsKCQlzdltuZ290XSA9IHMgPyAtbiA6IG47Cgl9CglpZihjIT1FT0YpIHVuZ2V0Yyhj LCBmKTsKCXJldHVybihuZ290KTsKfQoKLyoKICogQ2hlY2sgZm9yIGEgc3RyaW5nIG9uIGEg ZmlsZS4KICogSWYgZm91bmQsIHJldHVybiAwLgogKiBJZiBub3QsIHJldHVybiB0aGUgb2Zm c2V0IG9mIHRoZSBsYXN0IG1hdGNoZWQgY2hhciArMQogKiBhbmQgdW5nZXRjIHRoZSBmYWls ZWQgY2hhciBzbyB0aGUgY2FsbGVyIGNhbiBzZWUgaXQuCiAqLwppbnQKZmV4cGVjdHN0cihy ZWdpc3RlciBGSUxFICpmaWxlLCBjaGFyICpzdHIpCnsKCXJlZ2lzdGVyIGNoYXIgKnAgPSBz dHI7CglyZWdpc3RlciBpbnQgYzsKCgl3aGlsZSgqcCAhPSAnXDAnKSB7CgkgICAgaWYoKGMg PSBnZXRjKGZpbGUpKSAhPSAqcCsrKSB7CgkJaWYoYyAhPSBFT0YpCgkJICAgIHVuZ2V0Yyhj LCBmaWxlKTsKCQlyZXR1cm4ocCAtIHN0cik7CgkgICAgfQoJfQoJcmV0dXJuIDA7Cn0KCi8q CiAqIENoZWNrIGZvciBhIHN0cmluZyBvbiBhIGZpbGUsIHNraXBwaW5nIGxlYWRpbmcgYmxh bmtzLgogKi8KaW50CmZleHBlY3R0b2tlbihyZWdpc3RlciBGSUxFICpmaWxlLCBjaGFyICpz dHIpCnsKCSh2b2lkKSBmbmV4dGMoZmlsZSwgMCk7CglyZXR1cm4gZmV4cGVjdHN0cihmaWxl LCBzdHIpOwp9CgppbnQgZmVzY2FwZShGSUxFICpmKQp7CiAgICBpbnQgbiwgaywgYyA9IGZn ZXRjKGYpOwoKICAgIHN3aXRjaChjKSB7CgljYXNlICduJzogcmV0dXJuICdcbic7CgljYXNl ICdiJzogcmV0dXJuICdcYic7CgljYXNlICd0JzogcmV0dXJuICdcdCc7CgljYXNlICdyJzog cmV0dXJuICdccic7CiAgICB9CiAgICBpZihjIDwgJzAnIHx8IGMgPiAnNycpCglyZXR1cm4g YzsKICAgIAogICAgbiA9IGMtJzAnOyAgayA9IDI7CiAgICB3aGlsZSgoYyA9IGZnZXRjKGYp KSA+PSAnMCcgJiYgYyA8PSAnNycpIHsKCW4gPSBuKjggfCBjLScwJzsKCWlmKC0tayA8PSAw KQoJICAgIHJldHVybiBuOwogICAgfQogICAgaWYoYyAhPSBFT0YpIHVuZ2V0YyhjLCBmKTsK ICAgIHJldHVybiBuOwp9CgovKgogKiBHZXQgYSB0b2tlbiwgcmV0dXJuIGEgc3RyaW5nIG9y IE5VTEwuCiAqIFRva2VucyBtYXkgYmUgInF1b3RlZCIgb3IgJ3F1b3RlZCc7IGJhY2tzbGFz aGVzIGFjY2VwdGVkLgogKiBUaGUgc3RyaW5nIGlzIHN0YXRpY2FsbHkgYWxsb2NhdGVkIGFu ZCBzaG91bGQgYmUgY29waWVkIGlmCiAqIG5lZWRlZCBiZWZvcmUgdGhlIG5leHQgY2FsbCB0 byBmdG9rZW4oKS4KICovCmNoYXIgKgpmdG9rZW4oRklMRSAqZmlsZSwgaW50IGZsYWdzKQp7 CglzdGF0aWMgY2hhciAqdG9rZW4gPSBOVUxMOwoJc3RhdGljIGludCB0cm9vbSA9IDA7Cgly ZWdpc3RlciBpbnQgYzsKCXJlZ2lzdGVyIGNoYXIgKnA7CglyZWdpc3RlciBpbnQgdGVybTsK CglpZigodGVybSA9IGZuZXh0YyhmaWxlLCBmbGFncykpID09IEVPRikKCSAgICByZXR1cm4g TlVMTDsKCglpZih0b2tlbiA9PSBOVUxMKSB7CgkgICAgdHJvb20gPSA1MDsKCSAgICB0b2tl biA9IG1hbGxvYyh0cm9vbSAqIHNpemVvZihjaGFyKSk7CgkgICAgaWYodG9rZW4gPT0gTlVM TCkKCQlyZXR1cm4gTlVMTDsKCX0KCglwID0gdG9rZW47Cglzd2l0Y2godGVybSkgewoJY2Fz ZSAnIic6CgljYXNlICdcJyc6CgkgICAgKHZvaWQpIGZnZXRjKGZpbGUpOwoJICAgIGZvcig7 OykgeyAKCQlpZigoYyA9IGdldGMoZmlsZSkpID09IEVPRiB8fCBjID09IHRlcm0pCgkJICAg IGJyZWFrOwoJCWVsc2UgaWYoYyA9PSAnXFwnKQoJCSAgICBjID0gZmVzY2FwZShmaWxlKTsK CQkqcCsrID0gYzsKCQlpZihwID09ICZ0b2tlblt0cm9vbV0pIHsKCQkgICAgdG9rZW4gPSBy ZWFsbG9jKHRva2VuLCB0cm9vbSAqIDIpOwoJCSAgICBpZih0b2tlbiA9PSBOVUxMKQoJCQly ZXR1cm4gTlVMTDsKCQkgICAgcCA9ICZ0b2tlblt0cm9vbV07CgkJICAgIHRyb29tICo9IDI7 CgkJfQoJICAgIH0KCSAgICBicmVhazsKCglkZWZhdWx0OgoJICAgIGlmKGlzc3BhY2UodGVy bSkpCgkJcmV0dXJuIE5VTEw7CgkgICAgd2hpbGUoKGMgPSBnZXRjKGZpbGUpKSAhPSBFT0Yg JiYgIWlzc3BhY2UoYykpIHsKCQlpZihjID09ICdcXCcpCgkJICAgIGMgPSBmZXNjYXBlKGZp bGUpOwoJCSpwKysgPSBjOwoJCWlmKHAgPT0gJnRva2VuW3Ryb29tXSkgewoJCSAgICB0b2tl biA9IHJlYWxsb2ModG9rZW4sIHRyb29tICogMik7CgkJICAgIGlmKHRva2VuID09IE5VTEwp CgkJCXJldHVybiBOVUxMOwoJCSAgICBwID0gJnRva2VuW3Ryb29tXTsKCQkgICAgdHJvb20g Kj0gMjsKCQl9CgkgICAgfQoJICAgIGJyZWFrOwoJfQoJKnAgPSAnXDAnOwoJcmV0dXJuIHRv a2VuOwp9CgoKLyoKICogR2V0IGEgdG9rZW4sIHJldHVybiBhIHN0cmluZyBvciBOVUxMLgog KiBUb2tlbnMgbWF5IGJlICJxdW90ZWQiIG9yICdxdW90ZWQnOyBiYWNrc2xhc2hlcyBhY2Nl cHRlZC4KICogVGhlIHN0cmluZyBpcyBzdGF0aWNhbGx5IGFsbG9jYXRlZCBhbmQgc2hvdWxk IGJlIGNvcGllZCBpZgogKiBuZWVkZWQgYmVmb3JlIHRoZSBuZXh0IGNhbGwgdG8gZnRva2Vu KCkuCiAqLwpjaGFyICoKZmRlbGltdG9rKGNoYXIgKmRlbGltcywgRklMRSAqZmlsZSwgaW50 IGZsYWdzKQp7CglzdGF0aWMgY2hhciAqdG9rZW4gPSBOVUxMOwoJc3RhdGljIGludCB0cm9v bSA9IDA7CglyZWdpc3RlciBpbnQgYzsKCXJlZ2lzdGVyIGNoYXIgKnA7CglyZWdpc3RlciBj aGFyICpxOwoJcmVnaXN0ZXIgaW50IHRlcm07CgoJaWYoKHRlcm0gPSBmbmV4dGMoZmlsZSwg ZmxhZ3MpKSA9PSBFT0YpCgkgICAgcmV0dXJuIE5VTEw7CgoJaWYodG9rZW4gPT0gTlVMTCkg ewoJICAgIHRyb29tID0gNTA7CgkgICAgdG9rZW4gPSBtYWxsb2ModHJvb20gKiBzaXplb2Yo Y2hhcikpOwoJICAgIGlmKHRva2VuID09IE5VTEwpCgkJcmV0dXJuIE5VTEw7Cgl9CgoJcCA9 IHRva2VuOwoJc3dpdGNoKHRlcm0pIHsKCWNhc2UgJyInOgoJY2FzZSAnXCcnOgoJICAgICh2 b2lkKSBmZ2V0YyhmaWxlKTsKCSAgICBmb3IoOzspIHsgCgkJaWYoKGMgPSBnZXRjKGZpbGUp KSA9PSBFT0YgfHwgYyA9PSB0ZXJtKQoJCSAgICBicmVhazsKCQllbHNlIGlmKGMgPT0gJ1xc JykKCQkgICAgYyA9IGZlc2NhcGUoZmlsZSk7CgkJKnArKyA9IGM7CgkJaWYocCA9PSAmdG9r ZW5bdHJvb21dKSB7CgkJICAgIHRva2VuID0gcmVhbGxvYyh0b2tlbiwgdHJvb20gKiAyKTsK CQkgICAgaWYodG9rZW4gPT0gTlVMTCkKCQkJcmV0dXJuIE5VTEw7CgkJICAgIHAgPSAmdG9r ZW5bdHJvb21dOwoJCSAgICB0cm9vbSAqPSAyOwoJCX0KCSAgICB9CgkgICAgYnJlYWs7CgoJ ZGVmYXVsdDoKCSAgICBpZihpc3NwYWNlKHRlcm0pKQoJCXJldHVybiBOVUxMOwoJICAgIHdo aWxlKChjID0gZ2V0YyhmaWxlKSkgIT0gRU9GICYmICFpc3NwYWNlKGMpKSB7CgkJaWYoYyA9 PSAnXFwnKQoJCSAgICBjID0gZmVzY2FwZShmaWxlKTsKCQkqcCA9IGM7CgkJaWYoKytwID09 ICZ0b2tlblt0cm9vbV0pIHsKCQkgICAgdG9rZW4gPSByZWFsbG9jKHRva2VuLCB0cm9vbSAq IDIpOwoJCSAgICBpZih0b2tlbiA9PSBOVUxMKQoJCQlyZXR1cm4gTlVMTDsKCQkgICAgcCA9 ICZ0b2tlblt0cm9vbV07CgkJICAgIHRyb29tICo9IDI7CgkJfQoJCWZvcihxID0gZGVsaW1z OyAqcSAmJiBjICE9ICpxOyBxKyspCgkJICAgIDsKCQlpZigqcSkgewoJCSAgICBpZihwID4g dG9rZW4rMSkgewoJCQlwLS07CgkJCXVuZ2V0YyhjLCBmaWxlKTsKCQkgICAgfQoJCSAgICBi cmVhazsKCQl9CgkgICAgfQoJICAgIGJyZWFrOwoJfQoJKnAgPSAnXDAnOwoJcmV0dXJuIHRv a2VuOwp9CgoKLyoKICogTG9hZCBvbmUgb3IgbW9yZSBUcmFuc2Zvcm1zIGZyb20gYSBmaWxl LgogKiBSZXR1cm4gMSBvbiBzdWNjZXNzLCAwIG9uIGZhaWx1cmUuCiAqLwppbnQKZmdldHRy YW5zZm9ybShGSUxFICpmaWxlLCBpbnQgbnRyYW5zLCBmbG9hdCAqdHJhbnMgLyogZmxvYXQg dHJhbnNbbnRyYW5zXVs0XVs0XSAqLywgaW50IGJpbmFyeSkKewoJcmVnaXN0ZXIgZmxvYXQg KlQ7CglpbnQgbnQ7CgoJZm9yKG50ID0gMDsgbnQgPCBudHJhbnM7IG50KyspIHsKCSAgICBU ID0gdHJhbnMgKyAxNipudDsKCSAgICBzd2l0Y2goZmdldG5mKGZpbGUsIDE2LCBULCBiaW5h cnkpKSB7CgkgICAgY2FzZSAxNjoKCQlicmVhazsKCgkgICAgY2FzZSAwOgoJCXJldHVybiBu dDsKCgkgICAgZGVmYXVsdDoKCQlyZXR1cm4gLTE7CgkgICAgfQoJfQoJcmV0dXJuIG50cmFu czsKfQoKaW50CmZwdXRuZihGSUxFICpmaWxlLCBpbnQgY291bnQsIGZsb2F0ICp2LCBpbnQg YmluYXJ5KQp7CglyZWdpc3RlciBpbnQgaTsKCWxvbmcgdzsKCWlmKGJpbmFyeSkgewojaWYg QklHX0VORElBTgoJICByZXR1cm4gZndyaXRlKHYsIHNpemVvZihmbG9hdCksIGNvdW50LCBm aWxlKTsKI2Vsc2UKCSAgZm9yKGkgPSAwOyBpIDwgY291bnQ7IGkrKykgewoJICAgIHcgPSBo dG9ubCgqKGxvbmcgKikmdltpXSk7CgkgICAgZndyaXRlKCZ3LCBzaXplb2YoZmxvYXQpLCAx LCBmaWxlKTsKCSAgfQoJICByZXR1cm4gY291bnQ7CiNlbmRpZgoJfQoKCWZwcmludGYoZmls ZSwgIiVnIiwgdlswXSk7Cglmb3IoaSA9IDE7IGkgPCBjb3VudDsgaSsrKQoJICAgIGZwcmlu dGYoZmlsZSwgIiAlZyIsIHZbaV0pOwoJcmV0dXJuIGNvdW50Owp9CgppbnQKZnB1dHRyYW5z Zm9ybShGSUxFICpmaWxlLCBpbnQgbnRyYW5zLCBmbG9hdCAqdHJhbnMsIGludCBiaW5hcnkp CnsKCXJlZ2lzdGVyIGludCBpLCBuOwoJcmVnaXN0ZXIgZmxvYXQgKnA7CgoJaWYoYmluYXJ5 KSB7CiNpZiBCSUdfRU5ESUFOCgkgICAgcmV0dXJuIGZ3cml0ZSh0cmFucywgNCo0KnNpemVv ZihmbG9hdCksIG50cmFucywgZmlsZSk7CiNlbHNlCglPT0dMRXJyb3IoMSwgImZwdXR0cmFu c2Zvcm06IG5lZWQgY29kZSB0byBoYW5kbGUgYmluYXJ5IHdyaXRlcyBmb3IgdGhpcyBhcmNo aXRlY3R1cmUuIik7CglyZXR1cm4gMDsKI2VuZGlmCgl9CgoJLyogQVNDSUkuICovCgoJZm9y KG4gPSAwOyBuIDwgbnRyYW5zOyBuKyspIHsKCSAgICBwID0gdHJhbnMgKyBuKjE2OwoJICAg IGZvcihpID0gMDsgaSA8IDQ7IGkrKywgcCArPSA0KSB7CgkJZnByaW50ZihmaWxlLCAiICAl MTIuOGcgICUxMi44ZyAgJTEyLjhnICAlMTIuOGdcbiIsCgkJICAgIHBbMF0sIHBbMV0sIHBb Ml0sIHBbM10pOwoJICAgIH0KCSAgICBpZihmZXJyb3IoZmlsZSkpCgkJcmV0dXJuIG47Cgkg ICAgZnByaW50ZihmaWxlLCAiXG4iKTsKCX0KCXJldHVybiBudHJhbnM7Cn0KCi8qCiAqIEdp dmVuIGEgZmlsZSBwb2ludGVyLCByZXR1cm4gYSBzdHJpbmcgYXR0ZW1wdGluZyB0byBzaG93 IHRoZSBjb250ZXh0CiAqIG9mIGl0cyBjdXJyZW50IHBvc2l0aW9uLiAgSWYgbm8gZGF0YSBp cyBhdmFpbGFibGUsIHJldHVybnMgdGhlIGVtcHR5IHN0cmluZy4KICovCmNoYXIgKgpmY29u dGV4dChyZWdpc3RlciBGSUxFICpmKQp7CiAgICBzdGF0aWMgY2hhciAqY29udCA9IE5VTEw7 CiAgICBzdGF0aWMgY2hhciBkZmx0W10gPSAiIjsKICAgIGNoYXIgYnVmWzEwMjRdOwogICAg aW50IG5wcmUsIG5wb3N0LCBubHByZSwgbmxwb3N0LCB0YWIsIGxlbjsKICAgIGludCBwcmVk b3RzID0gNCwgcG9zdGRvdHMgPSA0OwogICAgcmVnaXN0ZXIgY2hhciAqcCwgKnE7CiAgICBj aGFyICpsYXN0bGluZSwgKmxhc3Rub25ibGFuazsKICAgIGNoYXIgKmJhc2UsICpwdHI7CiAg ICBpbnQgY250OwoKICAgIGlmKGYgPT0gTlVMTCkKCXJldHVybiBkZmx0OwogICAgaWYoZmVv ZihmKSkKCXJldHVybiAiPiBFTkQgT0YgRklMRVxuIjsKI2lmIDAJLyogWFhYIHdjZiAqLwoj aWZkZWYgX19saW51eF9fCiAgICBiYXNlID0gKGNoYXIgKilmLT5fSU9fcmVhZF9iYXNlOwog ICAgcHRyID0gKGNoYXIgKilmLT5fSU9fcmVhZF9wdHI7CiAgICBjbnQgPSBwdHIgLSBiYXNl OwojZWxzZQogICAgYmFzZSA9IChjaGFyICopZi0+X2Jhc2U7CiAgICBwdHIgPSAoY2hhciAq KWYtPl9wdHI7CiAgICBjbnQgPSBmLT5fY250OwojZW5kaWYKICAgIGlmKGNudCA8PSAwIHx8 IGJhc2UgPT0gTlVMTCB8fCBwdHIgPT0gTlVMTCkKCXJldHVybiBkZmx0OwoKICAgIHAgPSBw dHI7CiAgICBmb3IobnByZSA9IG5scHJlID0gMDsgLS1wID49IGJhc2UgJiYgbnByZSA8IDEy ODsgbnByZSsrKSB7CglpZigqcCA9PSAnXG4nKSB7CgkgICAgaWYoKytubHByZSA+IDIgfHwg bnByZSA+IDYwKSB7CgkJcHJlZG90cyA9IDA7CgkJYnJlYWs7CgkgICAgfQoJfSBlbHNlIGlm KCpwICYgMHg4MCB8fCAqcCA9PSAwKQkJLyogYmluYXJ5IGRhdGE/ICovCgkgICAgYnJlYWs7 CiAgICB9CiAgICBzdHJjcHkoYnVmLCAiPiAuLi4gIik7CiAgICBxID0gYnVmICsgMiArIHBy ZWRvdHM7CiAgICB0YWIgPSAyICsgcHJlZG90czsKICAgIGZvcihwID0gcHRyIC0gbnByZTsg cCA8IHB0cjsgKSB7Cglzd2l0Y2goKnErKyA9ICpwKyspIHsKCWNhc2UgJ1xuJzogY2FzZSAn XHInOgkqcSsrID0gJz4nOyAqcSsrID0gJyAnOyB0YWIgPSAyOyBicmVhazsKCWNhc2UgJ1x0 JzoJCXRhYiArPSA4LSh0YWImNyk7IGJyZWFrOwoJZGVmYXVsdDoJCXRhYisrOwoJfQogICAg fQogICAgbGVuID0gbnByZTsKICAgIG5wb3N0ID0gbmxwb3N0ID0gMDsKICAgIGxhc3RsaW5l ID0gbGFzdG5vbmJsYW5rID0gcTsKICAgIGZvcihwID0gcHRyOyAgcCA8IHB0ciArIGNudCAm JiBsZW4gPCAxMjg7ICBsZW4rKywgcSsrKSB7CgkqcSA9ICpwKys7CglpZigqcSA9PSAnXG4n KSB7CgkgICAgaWYobmxwb3N0ID09IDApIHsKCQl3aGlsZSgtLXRhYiA+IDApICorK3EgPSAn LSc7CS8qIFBvaW50IC0tLV4gdG8gZXJyb3IgKi8KCQkqKytxID0gJ14nOyAqKytxID0gJ1xu JzsKCSAgICB9CgkgICAgaWYoKCsrbmxwb3N0ID49IDIgfHwgbGVuID4gODApICYmIGxlbiA+ IDMyKSB7CgkJcG9zdGRvdHMgPSAwOwoJCWJyZWFrOwoJICAgIH0KCSAgICBsYXN0bGluZSA9 IHE7CgkgICAgKisrcSA9ICc+JzsgKisrcSA9ICcgJzsKCX0gZWxzZSBpZigqcSAmIDB4ODAg fHwgKnEgPT0gMCkJCS8qIEJpbmFyeSBkYXRhICovCgkgICAgYnJlYWs7CgllbHNlIGlmKGlz cHJpbnQoKnEpKQoJICAgIGxhc3Rub25ibGFuayA9IHE7CiAgICB9CiAgICBpZihwb3N0ZG90 cyAmJiBsYXN0bm9uYmxhbmsgPCBsYXN0bGluZSkgewoJcSA9IGxhc3RsaW5lOwkJLyogU3Vw cHJlc3MgdHJhaWxpbmcgd2hpdGUgc3BhY2UgKi8KCXBvc3Rkb3RzID0gMDsJCS8qIHRvIGF2 b2lkIGZpbmFsIGBgPiAuLi4nJyAqLwogICAgfQogICAgc3RyY3B5KHEsICIgLi4uXG4iICsg NC1wb3N0ZG90cyk7CiAgICBpZihubHBvc3QgPT0gMCkgewoJcSArPSBzdHJsZW4ocSk7Cgl3 aGlsZSgtLXRhYiA+IDApICpxKysgPSAnLSc7CglzdHJjcHkocSwgIl5cbiIpOwogICAgfQog ICAgaWYoY29udCkgZnJlZShjb250KTsKICAgIHJldHVybiAoY29udCA9IHN0cmR1cChidWYp KTsKI2Vsc2UKICAgIHJldHVybiBkZmx0OwojZW5kaWYKfQoKCiNpZmRlZiBfX2xpbnV4X18K CmV4dGVybiBGSUxFCQkgKkNDX2ZtZW1vcGVuX19GUGNpKGNoYXIgKm1lbSwgaW50IGxlbik7 CmV4dGVybiBzdHJ1Y3Qgc3RkaW9fbWFyayAqQ0Nfc3RkaW9fc2V0bWFya19fRlAxMHN0ZGlv X21hcmtQOHN0ZGlvYnVmKHN0cnVjdCBzdGRpb19tYXJrICptLCBGSUxFICpmKTsKZXh0ZXJu IGludAkJICBDQ19zdGRpb19zZWVrbWFya19fRlAxMHN0ZGlvX21hcmsoc3RydWN0IHN0ZGlv X21hcmsgKm1hcmspOwpleHRlcm4gdm9pZCAgCQkgIENDX3N0ZGlvX2ZyZWVtYXJrX19GUDEw c3RkaW9fbWFyayhzdHJ1Y3Qgc3RkaW9fbWFyayAqbWFyayk7IAoKRklMRSAqZnN0cm9wZW4o Y2hhciAqbWVtLCBpbnQgbGVuLCBjaGFyICptb2RlKQp7IHJldHVybiBDQ19mbWVtb3Blbl9f RlBjaShtZW0sIGxlbik7IH0KCnN0cnVjdCBzdGRpb19tYXJrICpzdGRpb19zZXRtYXJrKHN0 cnVjdCBzdGRpb19tYXJrICptLCBGSUxFICpmKQp7IHJldHVybiBDQ19zdGRpb19zZXRtYXJr X19GUDEwc3RkaW9fbWFya1A4c3RkaW9idWYobSwgZik7IH0KCmludCBzdGRpb19zZWVrbWFy ayhzdHJ1Y3Qgc3RkaW9fbWFyayAqbWFyaykKeyByZXR1cm4gQ0Nfc3RkaW9fc2Vla21hcmtf X0ZQMTBzdGRpb19tYXJrKG1hcmspICE9IEVPRjsgfQoKdm9pZCBzdGRpb19mcmVlbWFyayhz dHJ1Y3Qgc3RkaW9fbWFyayAqbWFyaykKeyBDQ19zdGRpb19mcmVlbWFya19fRlAxMHN0ZGlv X21hcmsobWFyayk7IH0KCgoJLyogRW5kIExpbnV4IChHTlUgbGliYywgbW9yZSBvciBsZXNz KSAqLwoKI2Vsc2UgICAvKiBSb3VnaGx5IHZhbmlsbGEgc3RkaW8gKi8KCiNpZiBkZWZpbmVk KEFJWCkgfHwgZGVmaW5lZChfX29zZl9fKSB8fCAxIC8qIFhYWCB3Y2YgKi8KCi8qIFRoZSBz dGRpby1idWYtaGFja2luZyBjb2RlIGJlbG93IGRvZXNuJ3Qgd29yayBvbiBzb21lIHN5c3Rl bXMsIHNvCiAqIGp1c3Qgc2hpcCB0aGUgZGF0YSB0aHJvdWdoIGEgcGlwZS4gIFNtYWxsICg4 Sz8pIHNpemUgbGltaXQuCiAqLwpGSUxFICpmc3Ryb3BlbihjaGFyICpzdHIsIGludCBsZW4s IGNoYXIgKm1vZGUpCnsKICAgaW50IHBmZFsyXTsKICAgaWYocGlwZShwZmQpIDwgMCkKICAg IHJldHVybiBOVUxMOwogICB3cml0ZShwZmRbMV0sIHN0ciwgbGVuKTsKICAgY2xvc2UocGZk WzFdKTsKICAgcmV0dXJuIGZkb3BlbihwZmRbMF0sICJyIik7Cn0KCiNlbHNlIC8qIEV2ZW4g bW9yZSBuZWFybHkgdmFuaWxsYSBzdGRpbyAqLwoKLyoKICogVGhpcyBvbmUgaXMgc3RkaW8g ZGVwZW5kZW50LCBidXQgc2VlbXMgdG8gd29yayBvbiBhIGZhaXIgdmFyaWV0eSBvZgogKiBp bXBsZW1lbnRhdGlvbnMuCiAqLwpGSUxFICoKZnN0cm9wZW4oY2hhciAqc3RyLCBpbnQgbGVu LCBjaGFyICptb2RlKQp7CglGSUxFICpmOwoKCWYgPSBmb3BlbigiL2Rldi9udWxsIiwgbW9k ZSk7CS8qIEhvdyBlbHNlIGRvIEkgZ2V0IGEgRklMRSAqPyAqLwoJaWYoZiA9PSBOVUxMKQoJ ICAgIHJldHVybiBOVUxMOwoJc2V0YnVmKGYsIE5VTEwpOwoJY2xvc2UoZmlsZW5vKGYpKTsK CiNpZmRlZiBocHV4CglmLT5fX2ZpbGVMID0gZi0+X19maWxlSCA9IC0xOwojZWxzZQoJZi0+ X2ZpbGUgPSAtMTsKI2VuZGlmCglmLT5fY250ID0gbGVuOwoJZi0+X3B0ciA9IGYtPl9iYXNl ID0gKHVuc2lnbmVkIGNoYXIgKikgc3RyOwoJZi0+X2ZsYWcgJj0gfihfSU9OQkZ8X0lPTVlC VUZ8X0lPRU9GfF9JT0VSUik7CglyZXR1cm4gZjsKfQojZW5kaWYgLyogbm9uLUFJWCwgbm9u LU9TRiBzdGRpbyAqLwoKCgoJLyogTW9yZSB3aXRoIHZhbmlsbGEgc3RkaW86CgkgKiBhdHRl bXB0IHRvIHNlZWsgYmFja3dhcmRzIChiYWNrdHJhY2spIG9uIGEgc3RyZWFtLgoJICogVXNl IHRydWUgc2Vla2luZyB3aGVyZSBwb3NzaWJsZSwgb3RoZXJ3aXNlIGF0dGVtcHQgdG8KCSAq IGZpZGRsZSB3aXRoIHRoZSBidWZmZXIgcG9pbnRlcnMgYW5kIHByYXkgaXQncyBzdGlsbCBp biB0aGUgYnVmZmVyCgkgKiAoc2lnaCkuICAgW0dOVSBsaWJjIGhhcyByZWFsIGZhY2lsaXRp ZXMgZm9yIGRvaW5nIHRoaXMhXQoJICovCnN0cnVjdCBzdGRpb19tYXJrIHsKCUZJTEUgKmY7 Cglsb25nIGZwb3M7CglGSUxFIGZjb3B5OwoJY2hhciBmY2hhcnNbOF07Cn07CgpzdHJ1Y3Qg c3RkaW9fbWFyayAqCnN0ZGlvX3NldG1hcmsocmVnaXN0ZXIgc3RydWN0IHN0ZGlvX21hcmsg Km1hcmssIHJlZ2lzdGVyIEZJTEUgKnN0cmVhbSkKewogICAgaWYobWFyayA9PSBOVUxMKQoJ bWFyayA9IE9PR0xOZXdFKHN0cnVjdCBzdGRpb19tYXJrLCAic3RkaW9fc2V0bWFyayBtYXJr Iik7CiAgICBtYXJrLT5mID0gc3RyZWFtOwoKICAgIG1hcmstPmZwb3MgPSBpc2F0dHkoZmls ZW5vKHN0cmVhbSkpID8gLTEgOiBmdGVsbChzdHJlYW0pOwogICAgbWFyay0+ZmNvcHkgPSAq c3RyZWFtOwojaWYgMAkvKiBYWFggd2NmICovCiAgICBtZW1jcHkobWFyay0+ZmNoYXJzLCBt YXJrLT5mLT5fYmFzZSwgc2l6ZW9mKG1hcmstPmZjaGFycykpOwojZW5kaWYKICAgIHJldHVy biBtYXJrOwp9CgppbnQKc3RkaW9fc2Vla21hcmsocmVnaXN0ZXIgc3RydWN0IHN0ZGlvX21h cmsgKm1hcmspCnsKICAgIGlmKG1hcmstPmZwb3MgPT0gLTEgfHwgZnNlZWsobWFyay0+Ziwg bWFyay0+ZnBvcywgMCkgPT0gLTEpIHsKI2lmIDAJLyogWFhYIHdjZiAqLwoJLyogTWF5YmUg aXQncyBhIHBpcGUgb3Igc29ja2V0LCBzbyBzZWVrcyBmYWlsLgoJICogVHJ5IHJlcG9zaXRp b25pbmcgaW5zaWRlIHRoZSBzdGRpbyBidWZmZXIuCgkgKiBUaGlzIGlzIGEgc3RkaW8tZGVw ZW5kZW50IGtsdWRnZSwgYnV0IG1pZ2h0IHdvcmsuCgkgKi8KCWlmKG1hcmstPmYtPl9iYXNl ID09IG1hcmstPmZjb3B5Ll9iYXNlICYmCgkgICBtZW1jbXAobWFyay0+ZmNoYXJzLCBtYXJr LT5mLT5fYmFzZSwgc2l6ZW9mKG1hcmstPmZjaGFycykpID09IDApIHsKCQkgICAgLyogQnVm ZmVyIGxvb2tzIHVuY2hhbmdlZC4gIFJlc2V0IHBvaW50ZXJzLiAqLwoJICAgICoobWFyay0+ ZikgPSBtYXJrLT5mY29weTsKCX0gZWxzZSB7CgkgICAgcmV0dXJuIDA7CS8qIEZhaWxlZCAq LwoJfQojZWxzZQoJcmV0dXJuIDA7CiNlbmRpZgogICAgfQogICAgcmV0dXJuIDE7CQkvKiBT dWNjZWVkZWQgKi8KfQoKdm9pZApzdGRpb19mcmVlbWFyayhzdHJ1Y3Qgc3RkaW9fbWFyayAq bWFyaykKewogICAgT09HTEZyZWUobWFyayk7Cn0KCiNlbmRpZiAgLyogdmFuaWxsYSBzdGRp byAqLwoKLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KCmludApmaGFzZGF0YShGSUxFICpmKQp7 CiAgICByZXR1cm4gRl9IQVNEQVRBKGYpOwp9CgppbnQKYXN5bmNfZ2V0YyhyZWdpc3RlciBG SUxFICpmKQp7CgogICAgZmRfc2V0IGZkczsKICAgIHN0YXRpYyBzdHJ1Y3QgdGltZXZhbCBu b3RpbWUgPSB7IDAsIDAgfTsKCiAgICBpZihGX0hBU0RBVEEoZikpCglyZXR1cm4gZ2V0Yyhm KTsKICAgIEZEX1pFUk8oJmZkcyk7CiAgICBGRF9TRVQoZmlsZW5vKGYpLCAmZmRzKTsKICAg IGlmKHNlbGVjdChmaWxlbm8oZikrMSwgJmZkcywgTlVMTCwgTlVMTCwgJm5vdGltZSkgPT0g MSkKCXJldHVybiBmZ2V0YyhmKTsKICAgIHJldHVybiBOT0RBVEE7Cn0KCmludAphc3luY19m bmV4dGMocmVnaXN0ZXIgRklMRSAqZiwgcmVnaXN0ZXIgaW50IGZsYWdzKQp7CiAgICByZWdp c3RlciBpbnQgYzsKCiAgICBjID0gYXN5bmNfZ2V0YyhmKTsKICAgIGZvcig7OykgewoJc3dp dGNoKGMpIHsKCWNhc2UgRU9GOgoJY2FzZSBOT0RBVEE6CgkgICAgcmV0dXJuKGMpOwoKCWNh c2UgJyAnOgoJY2FzZSAnXHQnOgoJICAgIGJyZWFrOwkJCS8qIEFsd2F5cyBza2lwIGJsYW5r cyBhbmQgdGFicyAqLwoKCWNhc2UgJyMnOgoJICAgIGlmKGZsYWdzICYgMikJCS8qIDI6IHN0 b3Agb24gY29tbWVudHMsIGVsc2Ugc2tpcCAqLwoJCWdvdG8gZmltOwoKCSAgICB3aGlsZSgo YyA9IGdldGMoZikpICE9ICdcbicgJiYgYyAhPSBFT0YpCgkJOwoJICAgIGNvbnRpbnVlOwkJ CS8qIFJlc2NhbiB0aGlzIGMgKi8KCgljYXNlICdcbic6CgkgICAgaWYoIShmbGFncyAmIDEp KQkJLyogMTogc3RvcCBvbiBcbidzLCBlbHNlIHNraXAgdGhlbSAqLwoJCWJyZWFrOwoJCQkJ ICAgIAkvKiBmbGFncyYxID0+IGZhbGwgaW50byBkZWZhdWx0ICovCgoJZGVmYXVsdDoKCSBm aW06CgkgICAgdW5nZXRjKGMsIGYpOwoJICAgIHJldHVybihjKTsKCX0KCgljID0gYXN5bmNf Z2V0YyhmKTsKICAgIH0KfQo= --===_0_Sun_Nov__3_13:11:14_PST_1996-- From owner-freebsd-hackers Sun Nov 3 13:13:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA25545 for hackers-outgoing; Sun, 3 Nov 1996 13:13: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 NAA25534 for ; Sun, 3 Nov 1996 13:13:39 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03179; Sun, 3 Nov 1996 14:05:13 -0700 From: Terry Lambert Message-Id: <199611032105.OAA03179@phaeton.artisoft.com> Subject: Re: Blargh - BSDI disk labels To: imp@village.org (Warner Losh) Date: Sun, 3 Nov 1996 14:05:13 -0700 (MST) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org, karl@Mcs.Net In-Reply-To: from "Warner Losh" at Nov 2, 96 06:18: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 > In message <199611022235.PAA01848@phaeton.artisoft.com> Terry Lambert writes: > : I think the disklabel is it (I have JAZ disks with Net and Open on them). > > The disk label is part of the it. Does anybody know if there are > other reasons, like FFS on disk structures are incompatible? There is no FFS incompatability for OpenBSD or NetBSD. I can't speak for BSDI. One would think that BSDI would change the FS magic number if they changed the on disk format. That's what it's there for, and most of the people who put it there in the first place work for BSDI. Plus they'd have backward compatability issues if they didn't. So the ball is back in your court: does BSDI change the magic number? 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 3 13:17:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA25835 for hackers-outgoing; Sun, 3 Nov 1996 13:17:57 -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 NAA25828 for ; Sun, 3 Nov 1996 13:17:54 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id QAA12257 for ; Sun, 3 Nov 1996 16:16:22 -0500 (EST) Date: Sun, 3 Nov 1996 16:16:22 -0500 (EST) From: Mark Mayo To: freebsd-hackers@freebsd.org Subject: = Cool! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wow, I just "discovered" the make stuff in /usr/share/mk -- very cool. I was trying to install CVSup, which required the libz library (in shared format). I went and ftp'ed the /usr/src/lib/libz/* stuff from freefall, and did a make.. it produced the libz.a and libz_p.a files. I took a look at the makefile (I wanted a .so, but had no idea how to go about this) and noticed the include of bsd.lib.mk on the last line of the Makefile. So I did a find and located it, and after readin the README, I saw the light and understood what was happening here! I also noticed from examining the bsd.lib.mk makefile that I just needed to make a $(.CURDIR)/shlib_version directoy and I'd get my shared lib library!! Happy happy was I! It all worked out, I learned something about BSD, and now I'm CVSupping the RELENG_2_2 tree to start poking around and helping out with finding some bugs.. Super! Everyday I like FreeBSD (and BSD in general) more and more -- congrats to everyone involved, I've never had so much fun with a computer!! Just a happy little note from a satisfied user. cya, -Mark P.S. I'm spending every free minute I have trying to learn more about FreeBSD, C, and Unix in general so I can contribute to the project. Hopefully I'll be useful sometime in the not-so-distant future :-) ------------------------------------------- | Mark Mayo mark@quickweb.com | | RingZero Comp. www.quickweb.com | ------------------------------------------- "To iterate is human, to recurse divine." - L. Peter Deutsch From owner-freebsd-hackers Sun Nov 3 13:21:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA26111 for hackers-outgoing; Sun, 3 Nov 1996 13:21:51 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA25819; Sun, 3 Nov 1996 13:17:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA29180; Sun, 3 Nov 1996 14:15:59 -0700 Message-Id: <199611032115.OAA29180@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terry Lambert cc: dg@Root.COM, hackers@freefall.freebsd.org, smp@freefall.freebsd.org, bde@zeta.org.au Subject: Re: ed0 timeouts In-reply-to: Your message of "Sun, 03 Nov 1996 14:00:34 MST." <199611032100.OAA03152@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Nov 1996 14:15:59 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Yes, you can get another interrupt while servicing one. The driver loops > > >until all interrupts are serviced, but there would be a window between when it > > >thinks there are no more interrupts to service and returning to vector.s to > > >unmask the interrupts. This window will exist in all ISA drivers. > > > > bummer... > > > > Intel says: > > > > It is strongly recommended that first 82489 (ie APIC) should be unmasked > > and then the device interrupt should be enabled. By this sequence software > > can ensure that always an edge will occur at the APIC input only after > > the interrupt is unmasked. > > Or: "Don't ack the thing until fater it's unmasked". Huh? forgive me, not enough sleep... Is this sarcasm or a suggestion that is going over my head? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Sun Nov 3 13:38:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27793 for hackers-outgoing; Sun, 3 Nov 1996 13:38:16 -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 NAA27556; Sun, 3 Nov 1996 13:35:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03249; Sun, 3 Nov 1996 14:28:30 -0700 From: Terry Lambert Message-Id: <199611032128.OAA03249@phaeton.artisoft.com> Subject: Re: ed0 timeouts To: smp@csn.net (Steve Passe) Date: Sun, 3 Nov 1996 14:28:30 -0700 (MST) Cc: terry@lambert.org, dg@Root.COM, hackers@freefall.freebsd.org, smp@freefall.freebsd.org, bde@zeta.org.au In-Reply-To: <199611032115.OAA29180@clem.systemsix.com> from "Steve Passe" at Nov 3, 96 02:15:59 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 is strongly recommended that first 82489 (ie APIC) should be unmasked > > > and then the device interrupt should be enabled. By this sequence software > > > can ensure that always an edge will occur at the APIC input only after > > > the interrupt is unmasked. > > > > Or: "Don't ack the thing until fater it's unmasked". > > Huh? forgive me, not enough sleep... Is this sarcasm or a suggestion that > is going over my head? I think if you don't ack it, it will not allow another one in. This sort of implies you don't mask the way we currently mask, and it also implies a big latency (which I don't like at all) in taking the interrupt. Then you "manually" ack. I don't know what NT does, but SVR4 ES/MP used a two level interrupt handling mechanism, where the interrupt and all state from the hardware was saved off and queued for processing later. This let them weenie out on acking, but didn't add full processing overhead to the thing. Ie: if I get an int from a card that needs something read off it, it's read off immediately into a driver buffer, then acked, then queued for processing. Have you looked at the Windows 95 interrupt processing code? It's very similar. In some cases (bus master DMA hardware), there's a big concurrency win allowing interrupts from devices before the data from the previous interrupt is actually processed. I suspect the 95 and NT processing is similar (I haven't dived into WinICE on NT yet -- probably within the next month, though). Win95 can't allocate memeory at interrupt time, so the buffer allocation has to come from a free list, or from the ack routine (which is technically not run at interrupt level. I think there would be a big code impact on BSD to adopt this type of processing, but it might be worth it to work around your problem in the long run. From what David said, it looks like this is a generic ISA problem; I'd be surprised if it hasn't bit people without APIC's. I think the patch Bruce posted is a move in this direction (or at least that's what it looked like to me). 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 Sun Nov 3 13:57:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA29501 for hackers-outgoing; Sun, 3 Nov 1996 13:57:45 -0800 (PST) Received: from hamby1.lightside.net (hamby1.lightside.net [207.67.176.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA29490 for ; Sun, 3 Nov 1996 13:57:40 -0800 (PST) Received: from localhost (jehamby@localhost) by hamby1.lightside.net (8.8.2/8.8.2) with SMTP id NAA10657 for ; Sun, 3 Nov 1996 13:59:44 -0800 (PST) X-Authentication-Warning: hamby1.lightside.net: jehamby owned process doing -bs Date: Sun, 3 Nov 1996 13:59:42 -0800 (PST) From: Jake Hamby X-Sender: jehamby@hamby1 To: hackers@freebsd.org Subject: XFree86 3.2 now available. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk XFree86 3.2 was just released a few days ago. I see that binaries for FreeBSD 2.1.5 and FreeBSD-current are available from ftp.xfree86.org, as well as source code. Briefly, the improvements in XFree86 3.2 are that it uses X11R6.1 as a codebase, and supports a number of new chips, including beta support for Matrox Millenium! I suggest that we move XFree86 3.2 into ftp.freebsd.org, and the next 2.2-snapshot should install that version by default. -- Jake From owner-freebsd-hackers Sun Nov 3 14:14:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA02637 for hackers-outgoing; Sun, 3 Nov 1996 14:14:49 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA02276; Sun, 3 Nov 1996 14:12:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA29444; Sun, 3 Nov 1996 15:10:34 -0700 Message-Id: <199611032210.PAA29444@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terry Lambert cc: dg@Root.COM, hackers@freefall.freebsd.org, smp@freefall.freebsd.org, bde@zeta.org.au Subject: Re: ed0 timeouts In-reply-to: Your message of "Sun, 03 Nov 1996 14:28:30 MST." <199611032128.OAA03249@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Nov 1996 15:10:33 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >> Huh? forgive me, not enough sleep... Is this sarcasm or a suggestion that >> is going over my head? > > I think if you don't ack it, it will not allow another one in. ^^^ are you refering to the EOI sequence? it is complicated by the fact that you mask an INT in the IO APIC, but you send the EOI only to the local APIC, where the IRR & ISR bits are kept. So delaying the EOI will prevent it from getting to this CPU, but another CPU could then grab it, which is what we DON'T want. ( the "focus processor" feature might be a way around this problem ). >in the long run. From what David said, it looks like this is a >generic ISA problem; I'd be surprised if it hasn't bit people without >APIC's. the big difference is that the 8259 latches INTs when masked, the APIC ignores them. >I think the patch Bruce posted is a move in this direction (or at least >that's what it looked like to me). me too, but I need to apply the patch and look at it as a complete work, it touches on areas that have already changed to accommidate the APIC. there are also (undefined) macros in there that hide details (Bruce: hint, hint). -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Sun Nov 3 16:41:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16171 for hackers-outgoing; Sun, 3 Nov 1996 16:41:04 -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 QAA15807 for ; Sun, 3 Nov 1996 16:39:46 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id LAA01578; Mon, 4 Nov 1996 11:38:36 +1100 (EST) Date: Mon, 4 Nov 1996 11:38:32 +1100 (EST) From: "Daniel O'Callaghan" To: freebsd-hackers@freebsd.org Subject: ZNYX346 and FreeBSD 2.1.5 and the latest SNAP (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Forwarded from hardware due to silence. ---------- Forwarded message ---------- Date: Sun, 3 Nov 1996 01:13:05 +1100 (EST) From: Gavin Cameron To: hardware@FreeBSD.ORG Subject: ZNYX346 and FreeBSD 2.1.5 and the latest SNAP Hi there, I posted the following the couple of days ago and after the massive round of indifference I decided to see if I could get the card running on the latest SNAP. Do I need to move to something a bit more current? If someone can help me get the ZX346 running I'd appreciate it. I don't want to have to move to Linux. Hope you can help, Gavin Here's what I get in the messages file after a reboot. Nov 3 00:42:19 router /kernel: Probing for devices on PCI bus 0: Nov 3 00:42:20 router /kernel: chip0 rev 1 on pci0:0 Nov 3 00:42:20 router /kernel: chip1 rev 1 on pci0:7:0 Nov 3 00:42:20 router /kernel: chip2 rev 0 on pci0:7:1 Nov 3 00:42:20 router /kernel: vga0 rev 0 int a irq 11 on pci0:14 Nov 3 00:42:20 router /kernel: chip3 rev 0 on pci0:15 Nov 3 00:42:20 router /kernel: de0 rev 17 int a irq 5 on pci0:17 Nov 3 00:42:20 router /kernel: de0: DC21041 [10Mb/s] pass 1.1 Nov 3 00:42:20 router /kernel: de0: address 00:00:c0:d8:5f:e8 Nov 3 00:42:20 router /kernel: Probing for devices on PCI bus 1: Nov 3 00:42:20 router /kernel: de1 rev 32 int a irq 10 on pci1:4 Nov 3 00:42:20 router /kernel: de1: ZNYX ZX34X DC21140A [10-100Mb/s] pass 2.0 Nov 3 00:42:20 router /kernel: de1: address 00:c0:95:e0:02:a0 Nov 3 00:42:20 router /kernel: de1: enabling 100baseTX port Nov 3 00:42:20 router /kernel: de2 rev 32 int a irq 9 on pci1:5 Nov 3 00:42:20 router /kernel: de2: can't read ENET ROM (why=-3) (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff Nov 3 00:42:20 router /kernel: de2: DC21140A [10-100Mb/s] pass 2.0 Nov 3 00:42:20 router /kernel: de2: address unknown Nov 3 00:42:21 router /kernel: de3 rev 32 int a irq 5 on pci1:6 Nov 3 00:42:21 router /kernel: de3: can't read ENET ROM (why=-3) (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff Nov 3 00:42:21 router /kernel: de3: DC21140A [10-100Mb/s] pass 2.0 Nov 3 00:42:21 router /kernel: de3: address unknown Nov 3 00:42:21 router /kernel: de4 rev 32 int a irq 11 on pci1:7 Nov 3 00:42:21 router /kernel: de4: can't read ENET ROM (why=-3) (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff Nov 3 00:42:21 router /kernel: de4: DC21140A [10-100Mb/s] pass 2.0 Nov 3 00:42:21 router /kernel: de4: address unknown Nov 3 00:42:21 router /kernel: Probing for devices on the ISA bus: Nov 3 00:42:21 router /kernel: vt0 at 0x60-0x6f irq 1 on motherboard Nov 3 00:42:21 router /kernel: vt0: unkown s3, 80 col, color, 8 scr, mf2-kbd, [R3.20-b24] Nov 3 00:42:21 router /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Nov 3 00:42:21 router /kernel: sio0: type 16550A Nov 3 00:42:21 router /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Nov 3 00:42:21 router /kernel: sio1: type 16550A Nov 3 00:42:21 router /kernel: lpt0 at 0x378-0x37f irq 7 on isa Nov 3 00:42:21 router /kernel: lpt0: Interrupt-driven port Nov 3 00:42:22 router /kernel: lp0: TCP/IP capable interface Nov 3 00:42:22 router /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Nov 3 00:42:22 router /kernel: fdc0: NEC 72065B Nov 3 00:42:22 router /kernel: fd0: 1.44MB 3.5in Nov 3 00:42:22 router /kernel: wdc0 at 0x1f0-0x1f7 irq 14 on isa Nov 3 00:42:22 router /kernel: wdc0: unit 0 (wd0): Nov 3 00:42:22 router /kernel: wd0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S Nov 3 00:42:22 router /kernel: npx0 on motherboard Nov 3 00:42:22 router /kernel: npx0: INT 16 interface Nov 3 00:42:22 router /kernel: de0: enabling 10baseT port Nov 3 00:42:23 router lpd[99]: restarted [original article] > > Hi there, > > Does anyone have a ZNYX346, a 4 port ethernet card based on DEC 21140 > chipset, running in a 2.1.5R system? > > If so how? All ports on the ZYNX refuse to talk after bootup. > > I have the following cards in a Pentium system > * PCI S3 video card as vga0 > * PCI SMC8432BT ethernet card as de0 > * ZNYX 346 4 port ethernet card as de1 de2 de3 de4 > > One thing I notice is that the following IRQs are assigned: > * vga0 int a irq 9 > * de0 int a irq 5 > * de1 int a irq 11 > * de2 int a irq 9 > * de3 int a irq 5 > * de4 int a irq 12 > > After bootup I can use de0, but de1..4 refuse to work. I've tried ifconfiging > the interface to use link0, link1 and link2 but still no luck. > > All ethernet ports will eventually talk at 10MBits. > > When I boot up I get the following in /var/log/messages: > > Oct 31 06:10:15 router /kernel: FreeBSD 2.1.5-RELEASE #0: Thu Oct 31 04:37:18 EST 1996 > Oct 31 06:10:16 router /kernel: root@router.ormond.unimelb.edu.au:/usr/src/sys/compile/router > Oct 31 06:10:16 router /kernel: CPU: 133-MHz Pentium 735\90 or 815\100 (Pentium-class CPU) > Oct 31 06:10:16 router /kernel: Origin = "GenuineIntel" Id = 0x52c Stepping=12 > Oct 31 06:10:16 router /kernel: Features=0x1bf > Oct 31 06:10:16 router /kernel: real memory = 16777216 (16384K bytes) > Oct 31 06:10:16 router /kernel: avail memory = 14692352 (14348K bytes) > Oct 31 06:10:16 router /kernel: Probing for devices on PCI bus 0: > Oct 31 06:10:16 router /kernel: chip0 rev 1 on pci0:0 > Oct 31 06:10:16 router /kernel: chip1 rev 1 on pci0:7:0 > Oct 31 06:10:16 router /kernel: chip2 rev 0 on pci0:7:1 > Oct 31 06:10:16 router /kernel: chip3 rev 0 on pci0:15 > Oct 31 06:10:17 router /kernel: vga0 rev 0 int a irq 9 on pci0:16 > Oct 31 06:10:17 router /kernel: de0 rev 17 int a irq 5 on pci0:17 > Oct 31 06:10:17 router /kernel: de0: DC21041 [10Mb/s] pass 1.1 Ethernet address 00:00:c0:d8:5f:e8 > Oct 31 06:10:17 router /kernel: Probing for devices on PCI bus 1: > Oct 31 06:10:17 router /kernel: de1 rev 32 int a irq 11 on pci1:4 > Oct 31 06:10:17 router /kernel: de1: DC21140 [10-100Mb/s] pass 2.0 Ethernet address 00:c0:95:e0:02:a0 > Oct 31 06:10:17 router /kernel: de1: enabling 100baseTX UTP port > Oct 31 06:10:17 router /kernel: de2 rev 32 int a irq 9 on pci1:5 > Oct 31 06:10:17 router /kernel: de2: can't read ENET ROM (why=-3) (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > Oct 31 06:10:17 router /kernel: de2: DC21140 [10-100Mb/s] pass 2.0 Ethernet address unknown > Oct 31 06:10:17 router /kernel: de3 rev 32 int a irq 5 on pci1:6 > Oct 31 06:10:18 router /kernel: de3: can't read ENET ROM (why=-3) (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > Oct 31 06:10:18 router /kernel: de3: DC21140 [10-100Mb/s] pass 2.0 Ethernet address unknown > Oct 31 06:10:18 router /kernel: de4 rev 32 int a irq 12 on pci1:7 > Oct 31 06:10:18 router /kernel: de4: can't read ENET ROM (why=-3) (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > Oct 31 06:10:18 router /kernel: de4: DC21140 [10-100Mb/s] pass 2.0 Ethernet address unknown > Oct 31 06:10:18 router /kernel: Probing for devices on the ISA bus: > Oct 31 06:10:18 router /kernel: vt0 at 0x60-0x6f irq 1 on motherboard > Oct 31 06:10:18 router /kernel: vt0: unkown s3, 80 col, color, 8 scr, mf2-kbd, [R3.20-b24] > Oct 31 06:10:18 router /kernel: lpt0 at 0x378-0x37f irq 7 on isa > Oct 31 06:10:18 router /kernel: lpt0: Interrupt-driven port > Oct 31 06:10:18 router /kernel: lp0: TCP/IP capable interface > Oct 31 06:10:19 router /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa > Oct 31 06:10:19 router /kernel: sio0: type 16550A > Oct 31 06:10:19 router /kernel: wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa > Oct 31 06:10:19 router /kernel: wdc0: unit 0 (wd0): , 32-bit, multi-block-16 > Oct 31 06:10:19 router /kernel: wd0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S > Oct 31 06:10:19 router /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > Oct 31 06:10:19 router /kernel: fdc0: NEC 72065B > Oct 31 06:10:19 router /kernel: fd0: 1.44MB 3.5in > Oct 31 06:10:19 router /kernel: npx0 on motherboard > Oct 31 06:10:19 router /kernel: npx0: INT 16 interface > Oct 31 06:10:19 router /kernel: de0: enabling 10baseT/UTP port > -- []-------------------------------------+--------------------------------------[] | Gavin Cameron | Ormond College | | Ph : +61 3 9344 1201 | The University of Melbourne | | Fax : +61 3 9344 1111 | Parkville, Victoria | | Email : gavin@ormond.unimelb.edu.au | Australia, 3052 | []-------------------------------------+--------------------------------------[] From owner-freebsd-hackers Sun Nov 3 17:31:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA20729 for hackers-outgoing; Sun, 3 Nov 1996 17:31:00 -0800 (PST) Received: from pelican.cs.ucla.edu (Pelican.CS.UCLA.EDU [131.179.128.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA20704; Sun, 3 Nov 1996 17:30:50 -0800 (PST) Received: (from terzis@localhost) by pelican.cs.ucla.edu (8.7.5/UCLACS-2.0) id RAA26240; Sun, 3 Nov 1996 17:28:37 -0800 (PST) From: Andreas Terzis Message-Id: <199611040128.RAA26240@pelican.cs.ucla.edu> Subject: HELP! Multicast support for MegaHertz cc10BT Ethernet Card To: hackers@freebsd.org Date: Sun, 3 Nov 1996 17:28:36 -0800 (PST) Cc: questions@freebsd.org X-Mailer: ELM [version 2.4 PL23] 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, I have an AST J30 notebook with a MegaHertz CC10BT PCMCIA Ethernet card. The problem is that multicast apps don't run on this card even though the card supports multicast. I suspect that this is a driver problem since my machine is Multicast enabled and the other interface (lo0) shows that multicast is enabled. Has anyone encountered the same problem? Any thoughts? Thanks in advance, Andreas Terzis From owner-freebsd-hackers Sun Nov 3 17:47:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA22780 for hackers-outgoing; Sun, 3 Nov 1996 17:47:48 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA22759; Sun, 3 Nov 1996 17:47:42 -0800 (PST) Received: by sovcom.kiae.su id AA16996 (5.65.kiae-1 ); Mon, 4 Nov 1996 04:45:03 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Mon, 4 Nov 96 04:45:03 +0300 Received: (from ache@localhost) by nagual.ru (8.8.2/8.8.2) id EAA00736; Mon, 4 Nov 1996 04:42:13 +0300 (MSK) Message-Id: <199611040142.EAA00736@nagual.ru> Subject: Re: XFree86 3.2 now available. In-Reply-To: from "Jake Hamby" at "Nov 3, 96 01:59:42 pm" To: jehamby@lightside.com (Jake Hamby) Date: Mon, 4 Nov 1996 04:42:13 +0300 (MSK) Cc: hackers@freebsd.org, ports@freebsd.org, jmz@freebsd.org From: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" (Andrey A. Chernov) Organization: self X-Class: Fast 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 > XFree86 3.2 was just released a few days ago. I see that binaries for > FreeBSD 2.1.5 and FreeBSD-current are available from ftp.xfree86.org, as > well as source code. > > Briefly, the improvements in XFree86 3.2 are that it uses X11R6.1 as a > codebase, and supports a number of new chips, including beta support for > Matrox Millenium! > > I suggest that we move XFree86 3.2 into ftp.freebsd.org, and the next > 2.2-snapshot should install that version by default. Please, don't forget to update ports/x11/XFree86 too -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Sun Nov 3 19:05:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01970 for hackers-outgoing; Sun, 3 Nov 1996 19:05:54 -0800 (PST) Received: from netrover.com (ottawa11.netrover.com [205.209.19.20]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA01952 for ; Sun, 3 Nov 1996 19:05:43 -0800 (PST) Received: (from brianc@localhost) by netrover.com (8.7.6/8.7.3) id WAA00778; Sun, 3 Nov 1996 22:04:25 -0500 (EST) Message-Id: <199611040304.WAA00778@netrover.com> Date: Sun, 3 Nov 1996 22:04:25 -0500 From: brianc@netrover.com (Brian Campbell) To: freebsd-hackers@FreeBSD.org Subject: atapi errors X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 Reply-to: freebsd-hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk With the 1014 snap and an 8x NEC IDE CD-ROM, I'm getting: wdc1 at 0x170-0x177 irq 15 flags 0x80ff on isa wdc1: unit 0 (atapi): , removable, dma, iordy wcd0: 1376Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray wcd0: medium type unknown, unlocked atapi1.0: invalid command phase, ireason=0xd0, status=d0, error=d0 atapi1.0: invalid command phase, ireason=0xd8, status=d8, error=d8 atapi1.0: controller not ready for cmd atapi1.0: controller not ready for cmd atapi1.0: controller not ready for cmd atapi1.0: controller not ready for cmd atapi1.0: controller not ready for cmd atapi1.0: controller not ready for cmd Any ideas on what the problem is, or how to fix? From owner-freebsd-hackers Sun Nov 3 19:23:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA03198 for hackers-outgoing; Sun, 3 Nov 1996 19:23:45 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA03192 for ; Sun, 3 Nov 1996 19:23:39 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.2/8.7.3) with SMTP id WAA06057; Sun, 3 Nov 1996 22:23:20 -0500 (EST) Message-Id: <199611040323.WAA06057@whizzo.transsys.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Jake Hamby cc: hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: XFree86 3.2 now available. References: In-reply-to: Your message of "Sun, 03 Nov 1996 13:59:42 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Nov 1996 22:23:19 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I suggest that we move XFree86 3.2 into ftp.freebsd.org, and the next > 2.2-snapshot should install that version by default. Could someone please commit the changes to /usr/sbin/moused which I submitted via send-pr a week or so ago? The patch adds support for the Alps Glidepoint "trackpad" pointing device. In particular, for the "tap" and "tap/drag" gestures. Previously, I rebuilt the X server with literally 2 lines of changes to support this device, but now with moused, I can save considerable time, troube and a bunch of disk space, by adding the changes in moused. I've been running the modified moused for a couple of weeks now with no problems. If you have one of these pointing devices, you'll really want these changes. Louis Mamakos From owner-freebsd-hackers Sun Nov 3 20:14:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA08083 for hackers-outgoing; Sun, 3 Nov 1996 20:14:31 -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 UAA07857; Sun, 3 Nov 1996 20:12:16 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id PAA22707; Mon, 4 Nov 1996 15:10:48 +1100 Date: Mon, 4 Nov 1996 15:10:48 +1100 From: Bruce Evans Message-Id: <199611040410.PAA22707@godzilla.zeta.org.au> To: smp@csn.net, terry@lambert.org Subject: Re: ed0 timeouts Cc: bde@zeta.org.au, dg@Root.COM, hackers@freefall.freebsd.org, smp@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >me too, but I need to apply the patch and look at it as a complete work, it >touches on areas that have already changed to accommidate the APIC. >there are also (undefined) macros in there that hide details (Bruce: hint, >hint). Define them as nothing or delete them. They have nothing to do with interrupt masking. Bruce From owner-freebsd-hackers Sun Nov 3 21:20:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA17472 for hackers-outgoing; Sun, 3 Nov 1996 21:20:45 -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 VAA17436 for ; Sun, 3 Nov 1996 21:20:37 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA27760; Mon, 4 Nov 1996 00:20:05 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 4 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 XAA09202; Sun, 3 Nov 1996 23:17:32 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id XAA01799; Sun, 3 Nov 1996 23:18:23 -0500 (EST) Date: Sun, 3 Nov 1996 23:18:23 -0500 (EST) From: Thomas David Rivers Message-Id: <199611040418.XAA01799@lakes.water.net> To: dyson@freebsd.org Subject: More info on the daily panics... Cc: ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > > > Everyone - > > > > As an example of something that crashes 2.1.5 (fairly quickly, I > > may add) and will not likely be determined by 'crashme'. I offer > > the following shell script. > > > If you can digest the problem with your system down to this level, I am sure > that a fix will be quickly forthcoming. Try the fix that Bruce just > posted, and see if your problem goes away. > > John > Well - I don't really have any ideas... I was trying to suggest that running 'crashme' for weeks on end probably isn't going to route out too many, if any, bugs... The problems I'm seeing appear to all be file-system related. I've applied Bruce's fix; but it really was for a different problem. I got another panic today: ffs_valloc: dup alloc that's the one I usually get when doing the newfs on the install (for 2.1.0 and 2.1.5) if I don't alter the newfs parms. Just to be clear; this is a 2.1.5-Stable kernel with Bruce's ufs_vnops.c fix. Here's the gdb -k traceback. This isn't a debugable kernel (I should probably fix that), so there's not too much information: Script started on Sun Nov 3 22:39:49 1996 [ponds.water.net]$ gdb -k kernel.6 vmcore.6 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 0xf0193c7b in boot () (kgdb) where #0 0xf0193c7b in boot () #1 0xf0112b83 in panic () #2 0xf0175183 in ffs_valloc () #3 0xf01813c6 in ufs_makeinode () #4 0xf017ed85 in ufs_create () #5 0xf012cb97 in vn_open () #6 0xf012a3cf in open () #7 0xf019bff6 in syscall () #8 0xf01914bb 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) quit [ponds.water.net]$ Script done on Sun Nov 3 22:40:09 1996 As you can see from the ls -l on /var/crash - after I enabled savedump; I get a crash almost every day (although I went for almost a week and ran just fine): [ponds.water.net]$ pwd /var/crash [ponds.water.net]$ ls -l total 131684 -rw-r--r-- 1 root wheel 2 Nov 3 13:21 bounds -rw-r--r-- 1 root wheel 956177 Oct 23 01:29 kernel.0 -rw-r--r-- 1 root wheel 956177 Oct 24 03:07 kernel.1 -rw-r--r-- 1 root wheel 965207 Oct 30 07:54 kernel.2 -rw-r--r-- 1 root wheel 965207 Oct 31 03:20 kernel.3 -rw-r--r-- 1 root wheel 965207 Nov 1 03:21 kernel.4 -rw-r--r-- 1 root wheel 965207 Nov 2 03:24 kernel.5 -rw-r--r-- 1 root wheel 965207 Nov 3 13:22 kernel.6 -rw-rw-r-- 1 root wheel 5 Jul 16 22:37 minfree -rw-r--r-- 1 root wheel 8650752 Oct 23 01:29 vmcore.0 -rw-r--r-- 1 root wheel 8650752 Oct 24 03:07 vmcore.1 -rw-r--r-- 1 root wheel 8650752 Oct 30 07:54 vmcore.2 -rw-r--r-- 1 root wheel 8650752 Oct 31 03:20 vmcore.3 -rw-r--r-- 1 root wheel 8650752 Nov 1 03:21 vmcore.4 -rw-r--r-- 1 root wheel 8650752 Nov 2 03:23 vmcore.5 -rw-r--r-- 1 root wheel 8650752 Nov 3 13:22 vmcore.6 (By the way, the panic on Nov 2nd - vmcore.5, was panic: ifree: freeing free inode the most frequent one I see...) You'll note from the times, these crashes tend to occur at roughly the same time. I've been scanning the cron logs; the only thing I see starting up about that time is the 03:15:00 /usr/libexec/atrun and a 03:15:00 /usr/lib/newsbin/input/newsrun. Both of these run every hour (well, atrun runs more often than that, of course) - so I'm not yet sure exactly what command(s) is/are causing the panic. Almost all the entries in the cron logs look like: Oct 23 01:15:01 ponds CRON[3494]: (news) CMD (/usr/lib/newsbin/input/newsrun) Oct 23 01:20:00 ponds CRON[3610]: (root) CMD (/usr/libexec/atrun) Oct 23 01:30:01 ponds cron[138]: (CRON) STARTUP (fork ok) although a few have something besides 'newsrun' starting up... it all seems pretty harmless. Let me add that there are no 'at' entries in the queue, for anyone on the system... Perhaps my next step is to build a debuggable kernel and start debugging... Let me add that a duplicate alloc, and freeing already free'd inodes, etc.... tend to point to a problem in the same area. Something fishy the the inode management in ffs_alloc.c. Of course, a reliable reproduction of the problem would help toward locating the fix... The 'freeing free inode' occurs if cg_inosused for the inode being free'd is already clear. The 'dup alloc' panic occurs if the i_mode of the inode which was returned from the allocator was already set (indicating the inode was already allocated.) The allocator here is ffs_nodealloccg() - which can return a wrong result if the cg_inosused field is clear... isclr() (from /usr/include/sys/param.h) is: #define isclr(a,i) (((a)[(i)/NBBY] & (1<<((i)%NBBY))) == 0) [NBBY is '8' from types.h.] This seems completely reasonable for accessing a bit from a character array... The cg_inosused() macro to access the used inodes table would be incorrect if CG_MAGIC wasn't set for some reason - then you would wind up pointing to trash for the inode table... This is what makes me think that allocating more inodes/blocks in a file system tickles this problem... Ideas on possible investigation avenues (i.e. hints on where to look) would be appreciated :-) But, I'm starting to become familiar with ffs_valloc.c & the cg structure :-) - Dave Rivers - From owner-freebsd-hackers Sun Nov 3 23:00:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA29432 for hackers-outgoing; Sun, 3 Nov 1996 23:00: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 XAA29387 for ; Sun, 3 Nov 1996 23:00:00 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14503(4)>; Sun, 3 Nov 1996 22:59:28 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177557>; Sun, 3 Nov 1996 22:59:20 -0800 To: "Daniel O'Callaghan" , "Gavin Cameron" cc: freebsd-hackers@freebsd.org Subject: Re: ZNYX346 and FreeBSD 2.1.5 and the latest SNAP (fwd) In-reply-to: Your message of "Sun, 03 Nov 96 16:38:32 PST." Date: Sun, 3 Nov 1996 22:59:13 PST From: Bill Fenner Message-Id: <96Nov3.225920pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Daniel, Gavin, Look in sys/pci/if_de.c; there is some kludgery there to handle the ZNYX 21040 multiport cards. It's worth trying to duplicate the 21040 special-case code and seeing if it can handle the 21140 ZNYX; it looks fairly straightforward. Bill From owner-freebsd-hackers Sun Nov 3 23:19:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA01251 for hackers-outgoing; Sun, 3 Nov 1996 23:19: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 XAA01245 for ; Sun, 3 Nov 1996 23:19:28 -0800 (PST) Received: from burdell.cc.gatech.edu (root@burdell.cc.gatech.edu [130.207.3.207]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id XAA08944 for ; Sun, 3 Nov 1996 23:19:21 -0800 (PST) Received: from oscar.cc.gatech.edu (cau@oscar.cc.gatech.edu [130.207.107.12]) by burdell.cc.gatech.edu (8.8.Beta.5/8.6.9) with ESMTP id CAA09574 for ; Mon, 4 Nov 1996 02:17:54 -0500 (EST) Received: (from cau@localhost) by oscar.cc.gatech.edu (8.8.Beta.5/8.6.9) id CAA04756 for hackers@freebsd.org; Mon, 4 Nov 1996 02:17:52 -0500 (EST) From: cau@cc.gatech.edu (Carlos Ugarte) Message-Id: <199611040717.CAA04756@oscar.cc.gatech.edu> Subject: Philips CDD2000 CD-R works as HP-4020i To: hackers@freebsd.org Date: Mon, 4 Nov 1996 02:17:52 -0500 (EST) 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 About a week ago I posted a message to questions but received no response. My problem is solved though, and I thought someone might want to know that the Philips CDD2000 CD-Recorder works under FreeBSD 2.2-961014-SNAP with very minor modifications. Maybe someone could make these changes to the tree and add the CD-R to the list of working CD-R's. The only modifications required were to scsiconf.c and worm.c - adding the vendor ID ("IMS") and model number ("CDD2000/00") in such a way that it duplicates the HP 4020i entries. Apparently some of the older CDD2000 drives had a different ID, so this may not work for all. The quirks are the same as those of the HP drive. Philips recently advertised the internal models for US $499 (after a rebate); this is at least $100 cheaper than the HP drives I could find around here. I just burnt a CD and was able to read it from FreeBSD and DOS. Carlos -- Carlos A. Ugarte cau@cc.gatech.edu Author of PageMage, a virtual desktop util for OS/2 http://www.cc.gatech.edu/people/home/cau/ If you understand what you're doing, you are not learning anything From owner-freebsd-hackers Sun Nov 3 23:58:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA04701 for hackers-outgoing; Sun, 3 Nov 1996 23:58:45 -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 XAA04675 for ; Sun, 3 Nov 1996 23:58:38 -0800 (PST) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id XAA23142; Sun, 3 Nov 1996 23:59:32 -0800 Date: Sun, 3 Nov 1996 23:59:24 -0800 (PST) From: Veggy Vinny To: Carlos Ugarte cc: hackers@FreeBSD.ORG Subject: Re: Philips CDD2000 CD-R works as HP-4020i In-Reply-To: <199611040717.CAA04756@oscar.cc.gatech.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, 4 Nov 1996, Carlos Ugarte wrote: > The only modifications required were to scsiconf.c and worm.c - > adding the vendor ID ("IMS") and model number ("CDD2000/00") in > such a way that it duplicates the HP 4020i entries. Apparently > some of the older CDD2000 drives had a different ID, so this may > not work for all. The quirks are the same as those of the HP drive. This is because the HP is a OEM Philips drive. Even the firmware is the same... Vince GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin From owner-freebsd-hackers Mon Nov 4 00:34:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA07929 for hackers-outgoing; Mon, 4 Nov 1996 00:34:23 -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 AAA07901; Mon, 4 Nov 1996 00:34:13 -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 KAA73480; Mon, 4 Nov 1996 10:34:03 +0200 Date: Mon, 4 Nov 1996 10:34:03 +0200 (EET) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: hackers@FreeBSD.ORG, isp@FreeBSD.ORG cc: gated@gated.merit.edu Subject: Re: Gated (both 3.5b3 and 3.6a2) on FreeBSD woes: no OSPF Hello startup :( 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 once again, people, I'm sorry for bothering you with silly questions :( [... "Hello timer mismatch" messages ...] It went out to be a stupid mistype by me, in gated.conf on FreeBSD, hellointerval didn't match the one used by other boxes. Now all is fine, FreeBSD works perfectly. Please take my apologies for wasting bandwidth. And, once again, great Thanks to John Capo for the port of the latest Gated. I strongly recommend FreeBSD team to integrate it into the ports tree, as a replacement for 3.5b3 or as just "yet another" Gated. > > I'm running 3.6a2 on one -current system and two -stable systems. > > A port is at ftp://ftp.irbs.com/FreeBSD/ports/gated-3.6a2.tgz. > > > John Capo jc@irbs.com > > IRBS Engineering FreeBSD Servers and Workstations > > (954) 792-9551 Unix/Internet Consulting - ISP Solutions > -- Best, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Mon Nov 4 01:26:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA17202 for hackers-outgoing; Mon, 4 Nov 1996 01:26: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 BAA16743; Mon, 4 Nov 1996 01:22:41 -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 KAA23656; Mon, 4 Nov 1996 10:21:40 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA18267; Mon, 4 Nov 1996 10:21:40 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id KAA04671; Mon, 4 Nov 1996 10:11:42 +0100 (MET) From: J Wunsch Message-Id: <199611040911.KAA04671@uriah.heep.sax.de> Subject: Re: More info on the daily panics... To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 4 Nov 1996 10:11:42 +0100 (MET) Cc: dyson@freebsd.org, ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611040418.XAA01799@lakes.water.net> from Thomas David Rivers at "Nov 3, 96 11:18:23 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 Thomas David Rivers wrote: > I got another panic today: > > ffs_valloc: dup alloc Interesting. Remember one of my mails from yesterday: i've got the same problem when using MFS. Maybe an incident... For me, it happened after a previous attempt to dd(1) into a particular file in MFS suddenly aborted with ``dd: filename: Bad address''. Trying to dd to the same file again triggered the dup alloc. -- 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 Mon Nov 4 02:09:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA23521 for hackers-outgoing; Mon, 4 Nov 1996 02:09:28 -0800 (PST) Received: from picasso.wcape.school.za (picasso.wcape.school.za [196.21.102.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA23477 for ; Mon, 4 Nov 1996 02:09:18 -0800 (PST) Received: by picasso.wcape.school.za via rmail with stdio id for freebsd-hackers@freebsd.org; Mon, 4 Nov 1996 00:36:05 +0200 (SAT) (Smail-3.2 1996-Jul-4 #1 built 1996-Oct-15) Received: from leftside.wcape.school.za (localhost [127.0.0.1]) by leftside.wcape.school.za (8.7.5/8.7.3) with SMTP id AAA00218 for ; Mon, 4 Nov 1996 00:26:56 +0200 (SAT) Date: Mon, 4 Nov 1996 00:26:55 +0200 (SAT) From: Peter van Heusden To: freebsd-hackers@freebsd.org Subject: Probe failing on SoundBlaster component of Phoneblaster 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 have a Creative Labs Phoneblaster, which is basically a Soundblaster 16 merged with a modem, and am having problems detecting the Soundblaster part of it. The board is a Plug&Pray one, but I don't think that is the problem, for reasons described below. Anyway, my kernel is configured controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr ... The sb0 probe fails, so I pulled the code from sb_dsp.c, and hacked it into a loadable kernel module, which also fails to get the correct response from the probe. What basically happens is this: outb 1 at the DSP_RESET port wait a while outb 0 at the DSP_RESET port wait a while longer (both waits are done using tenmicrosec(), defined in /i386/isa/sound/soundcard.c) check for bit 7 set at DSP_DATA_AVAIL port (response from card is 0xFF) check for response 0xAA at DSP_READ port Everything goes fine, but the response at DSP_READ is 0x00, not 0xAA. The fact that 0xFF is read at the DSP_DATA_AVAIL port seems to imply to me that the card is in fact there (i.e. the P&P config must have worked). I am thus confused by the 0x00 failure. Does anyone out there have a Phoneblaster that is actually working under FreeBSD? Any advice would be appreciated. Peter -- Peter van Heusden | Computers Networks Greens Justice Peace Beer Africa pvh@leftside.wcape.school.za pvh@gem.co.za From owner-freebsd-hackers Mon Nov 4 03:06:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA28950 for hackers-outgoing; Mon, 4 Nov 1996 03:06:15 -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 DAA28942 for ; Mon, 4 Nov 1996 03:06:11 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id VAA16027; Mon, 4 Nov 1996 21:35:52 +1030 From: Michael Smith Message-Id: <199611041105.VAA16027@genesis.atrad.adelaide.edu.au> Subject: Re: Probe failing on SoundBlaster component of Phoneblasterd To: pvh@leftside.wcape.school.za (Peter van Heusden) Date: Mon, 4 Nov 1996 21:35:51 +1030 (CST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: from "Peter van Heusden" at Nov 4, 96 00:26:55 am 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 Peter van Heusden stands accused of saying: > > Everything goes fine, but the response at DSP_READ is 0x00, not 0xAA. The > fact that 0xFF is read at the DSP_DATA_AVAIL port seems to imply to me > that the card is in fact there (i.e. the P&P config must have worked). I > am thus confused by the 0x00 failure. I'm sorry I can't help you with your actual proble, but it's worth noting that reading an empty bus will give you 0xff, so your first assumption above is not necessarily valid. > Peter -- ]] 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 Mon Nov 4 03:30:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA29904 for hackers-outgoing; Mon, 4 Nov 1996 03:30:06 -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 DAA29896 for ; Mon, 4 Nov 1996 03:30: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 DAA00705; Mon, 4 Nov 1996 03:27:20 -0800 (PST) Message-Id: <199611041127.DAA00705@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Michael Smith cc: pvh@leftside.wcape.school.za (Peter van Heusden), freebsd-hackers@FreeBSD.org Subject: Re: Probe failing on SoundBlaster component of Phoneblasterd In-reply-to: Your message of "Mon, 04 Nov 1996 21:35:51 +1030." <199611041105.VAA16027@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 03:27:20 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk His problem most likely is that his card is not configured properly. Curious, what does the PnP code in the kernel prints out at boot time? Amancio >From The Desk Of Michael Smith : > Peter van Heusden stands accused of saying: > > > > Everything goes fine, but the response at DSP_READ is 0x00, not 0xAA. The > > fact that 0xFF is read at the DSP_DATA_AVAIL port seems to imply to me > > that the card is in fact there (i.e. the P&P config must have worked). I > > am thus confused by the 0x00 failure. > > I'm sorry I can't help you with your actual proble, but it's worth > noting that reading an empty bus will give you 0xff, so your first > assumption above is not necessarily valid. > > > Peter > > -- > ]] 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 Mon Nov 4 03:38:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00548 for hackers-outgoing; Mon, 4 Nov 1996 03:38:05 -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 DAA00543 for ; Mon, 4 Nov 1996 03:38:01 -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 DAA04124 for ; Mon, 4 Nov 1996 03:38:31 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id WAA09945 for freebsd-hackers@freebsd.org; Mon, 4 Nov 1996 22:36:56 +1100 From: Julian Assange Message-Id: <199611041136.WAA09945@suburbia.net> Subject: scsi dat drive under freebsd To: freebsd-hackers@freebsd.org Date: Mon, 4 Nov 1996 22:36:56 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Will freebsd support 4mm DAT tape drives? I haven't noticed any specific support. The solaris st driver documentation has some magic-data for 4mm DATs using Helical scans, which seems to imply that they need specific support? -- "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 4 03:48:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA01195 for hackers-outgoing; Mon, 4 Nov 1996 03:48:19 -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 DAA01175 for ; Mon, 4 Nov 1996 03:48:16 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.6/8.6.9) with ESMTP id DAA01027; Mon, 4 Nov 1996 03:47:28 -0800 (PST) To: Julian Assange cc: freebsd-hackers@FreeBSD.org Subject: Re: scsi dat drive under freebsd In-reply-to: Your message of "Mon, 04 Nov 1996 22:36:56 +1100." <199611041136.WAA09945@suburbia.net> Date: Mon, 04 Nov 1996 03:47:28 -0800 Message-ID: <1025.847108048@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Will freebsd support 4mm DAT tape drives? I haven't noticed any specific It's supported my HP DAT drive for ages. Jordan From owner-freebsd-hackers Mon Nov 4 04:17:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05727 for hackers-outgoing; Mon, 4 Nov 1996 04:17:26 -0800 (PST) Received: from viking.ucsalf.ac.uk (viking.ucsalf.ac.uk [192.195.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA05700 for ; Mon, 4 Nov 1996 04:17:19 -0800 (PST) Received: by viking.ucsalf.ac.uk (Smail3.1.29.1 #4) id m0vKNxo-000377C; Mon, 4 Nov 96 12:17 GMT Message-Id: From: sbolting@nemonet.com (Stephen Boltinghouse) Subject: cmsg cancel <201.654193326831@news.nemonet.com> To: freebsd-hackers@freebsd.org Date: Sun, 03 Nov 1996 01:57:10 +1 X-Gated-To-News-By: news@ucsalf.ac.uk X-Cancelled-By: hw@atlantic.FB12.TU-Berlin.DE X-No-Archive: Yes Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk MMF chain letter cancelled by hw@atlantic.fb12.tu-berlin.de . This is spam! Far above of ten thousand of these have been posted. The Breidbart index of this series was 691. See report "S.Boltinghouse" in news.admin.net-abuse.announce or in de.admin.news.net-abuse.announce. Subject was: Just try this, it will work. From owner-freebsd-hackers Mon Nov 4 05:04:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA13268 for hackers-outgoing; Mon, 4 Nov 1996 05:04:39 -0800 (PST) Received: from oberon.tpgi.com.au (oberon.tpgi.com.au [203.12.160.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA13252 for ; Mon, 4 Nov 1996 05:04:34 -0800 (PST) Received: from buggs.cynergy.com.au ([203.12.164.9]) by oberon.tpgi.com.au (8.7.5/8.7.3) with ESMTP id XAA28505 for ; Mon, 4 Nov 1996 23:59:36 +1100 (EST) Received: from jimmy (e4s75.syd.enternet.com.au [203.63.39.75]) by buggs.cynergy.com.au (8.7.5/8.7.3) with SMTP id XAA26833 for ; Mon, 4 Nov 1996 23:11:42 +1000 (EST) Message-Id: <3.0.32.19961103002501.006a94c4@buggs.cynergy.com.au> X-Sender: kstrach@buggs.cynergy.com.au (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 05 Nov 1996 00:07:38 +1100 To: hackers@freebsd.org From: Keith Strachan Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-hackers Mon Nov 4 05:24:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA15338 for hackers-outgoing; Mon, 4 Nov 1996 05:24:55 -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 FAA15324 for ; Mon, 4 Nov 1996 05:24:45 -0800 (PST) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 23354 on Mon, 4 Nov 1996 14:16:09 +0100; id OAA23354 efrom: marc@nietzsche.bowtie.nl; eto: UNKNOWN Received: from localhost (localhost [127.0.0.1]) by nietzsche.bowtie.nl (8.7.5/8.7.3) with ESMTP id OAA14058; Mon, 4 Nov 1996 14:16:26 +0100 (MET) Message-Id: <199611041316.OAA14058@nietzsche.bowtie.nl> X-Mailer: exmh version 1.6.7 5/3/96 To: Jaye Mathisen cc: Michael Smith , hackers@FreeBSD.ORG Subject: Re: How's our ELF support coming? In-reply-to: mrcpu's message of Sat, 02 Nov 1996 00:27:57 -0800. Date: Mon, 04 Nov 1996 14:16:25 +0100 From: Marc van Kempen Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Solidtech's Database. I thought I recalled seeing that there was some > funky stuff going on with certain types of newer elf/Linux binaries, but > apparently I was mistaken. > > So, heigh ho, it's off we go... > > On Sat, 2 Nov 1996, Michael Smith wrote: > I'm running 2.2-960801-SNAP and I couldn't get it to work. However the sco emulation also improved and with this it works fine (until now, I'm about to test it more extensively) Regards, Marc. ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ---------------------------------------------------- From owner-freebsd-hackers Mon Nov 4 05:32:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA15998 for hackers-outgoing; Mon, 4 Nov 1996 05:32:17 -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 FAA15979; Mon, 4 Nov 1996 05:32:10 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.6/8.6.9) with ESMTP id FAA01666; Mon, 4 Nov 1996 05:32:09 -0800 (PST) To: hackers@freebsd.org cc: isp@freebsd.org Subject: pppgetty Date: Mon, 04 Nov 1996 05:32:09 -0800 Message-ID: <1664.847114329@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Whatever happened with this? Were we going to integrate it? If not, why not? It seems a perfectly useful feature, and a great way of making a more annex-like solution out of a FreeBSD box. Having now learned and lived with the horror that is radiusd, I have to say that there's a certain attractiveness to making a single box do your dialup-ppp services *and* your interactive logins. Accounting sure becomes a lot easier, and if you're using external modems anyway... Jordan From owner-freebsd-hackers Mon Nov 4 05:50:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA17045 for hackers-outgoing; Mon, 4 Nov 1996 05:50:38 -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 FAA17036 for ; Mon, 4 Nov 1996 05:50:33 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA14387; Mon, 4 Nov 1996 08:50:02 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 4 Nov 1996 08: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 IAA16931; Mon, 4 Nov 1996 08:37:50 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id IAA02674; Mon, 4 Nov 1996 08:38:44 -0500 (EST) Date: Mon, 4 Nov 1996 08:38:44 -0500 (EST) From: Thomas David Rivers Message-Id: <199611041338.IAA02674@lakes.water.net> To: joerg_wunsch@uriah.heep.sax.de, ponds!freefall.cdrom.com!freebsd-hackers Subject: Re: More info on the daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > As Thomas David Rivers wrote: > > > I got another panic today: > > > > ffs_valloc: dup alloc > > Interesting. Remember one of my mails from yesterday: i've got the > same problem when using MFS. Maybe an incident... > > For me, it happened after a previous attempt to dd(1) into a particular > file in MFS suddenly aborted with ``dd: filename: Bad address''. > Trying to dd to the same file again triggered the dup alloc. > Well - it is interesting... Let me tell you about a "theory" of mine - the theory of "bug time." I know this sounds silly, but I have a great deal of empirical evidence that suggests that bugs lie dormant in code; perhaps for dozens of years... then, suddenly; they'll begin manifesting themselves. When you begin investigating the problem - the answer it usually readily found; the developer frequently lameting "This never could have worked!" I think there could be sound psychological reasons for this - such as people not reporting problems, etc.... but I don't have any physical reasons to bring logic to my observations :-) Anyway, following the theory of "bug time" - you should see a few more reports like mine begin to trickle in :-) :-) - Dave Rivers - From owner-freebsd-hackers Mon Nov 4 06:15:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA18558 for hackers-outgoing; Mon, 4 Nov 1996 06:15:18 -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 GAA18528; Mon, 4 Nov 1996 06:15:05 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA04882; Mon, 4 Nov 1996 08:13:59 -0600 From: Joe Greco Message-Id: <199611041413.IAA04882@brasil.moneng.mei.com> Subject: Re: pppgetty To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 4 Nov 1996 08:13:58 -0600 (CST) Cc: hackers@freebsd.org, isp@freebsd.org In-Reply-To: <1664.847114329@time.cdrom.com> from "Jordan K. Hubbard" at Nov 4, 96 05:32:09 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Whatever happened with this? Were we going to integrate it? If not, > why not? It seems a perfectly useful feature, and a great way of > making a more annex-like solution out of a FreeBSD box. Having now > learned and lived with the horror that is radiusd, I have to say that > there's a certain attractiveness to making a single box do your > dialup-ppp services *and* your interactive logins. Accounting sure > becomes a lot easier, and if you're using external modems anyway... Jordan, I am not particularly thrilled about the idea of modems on the same box as interactive logins, as it can be a security risk (think of what could happen if someone exploited a security hole to gain access to a cua* device, all sorts of havoc could follow). I guess this also dates back to my SunOS days, because my old Suns were not fast enough to handle even two 14.4K modems. I much preferred offloading the modems onto a system with a 386DX/25 and a few 16550's. Anyways... I still have my patches to do the pppgetty thing. As a matter of fact, I just recently integrated those patches with my "network login router" software... this was the original local hack that ran on the 386DX/25 :-) A modified getty and login presents a "normal" banner and login: prompt and then waits for input. A central server is then contacted, and returns a reply based on local policy as to what to do with the user (local login, remote login, etc)... all very transparently. This is really cool because it provides much of the core functionality needed for ISP "terminal server" environments. Let's say you have a "shell account" machine and a "terminal server" machine. You set logins that have a passwd entry on the "shell account" machine to be rlogin'ed over to the shell account machine, logins that begin with a 'P' to log in on the terminal server via passwd authentication, and PAP style logins of course log in on the terminal server too. Now when the ISP gets a little bigger, assuming everything else was also engineered for growth (usually isn't, common ISP mistake)... you get half a dozen more terminal servers. Each one is drop and go. When you need another shell account machine, you have a little fun.. you set up local "NLR" policy so that logins starting with the letters 'A-M' are on one machine and 'N-Z' on the other. You put the home file systems on appropriate disks, etc. The users are automagically logged in on the right machine.... nifty cool. I am not willing to release this code as it sits, but if there is some particularly enterprising small ISP with a good C hacker that would like to work with me to whip it into better shape, I would consider providing it under BSD style copyright after it was whipped into shape. ... JG From owner-freebsd-hackers Mon Nov 4 06:42:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA20758 for hackers-outgoing; Mon, 4 Nov 1996 06:42:36 -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 GAA20752 for ; Mon, 4 Nov 1996 06:42:30 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id IAA22198; Mon, 4 Nov 1996 08:41:46 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma022175; Mon Nov 4 08:41:34 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 IAA10053; Mon, 4 Nov 1996 08:41:41 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.7.6/8.6.12) with ESMTP id IAA09263; Mon, 4 Nov 1996 08:41:30 -0600 (CST) Message-Id: <199611041441.IAA09263@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Marc van Kempen cc: Jaye Mathisen , Michael Smith , hackers@freebsd.org Subject: Re: How's our ELF support coming? In-reply-to: Your message of "Mon, 04 Nov 1996 14:16:25 +0100." <199611041316.OAA14058@nietzsche.bowtie.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 08:41:29 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Marc van Kempen writes: >I'm running 2.2-960801-SNAP and I couldn't get it to work. >However the sco emulation also improved and with this >it works fine (until now, I'm about to test it more extensively) > You'll need -current as of about 10/24. You'll also have to brand ldconfig, ldd and ld-linux.so I think. The linux_lib 2.1 port takes care of the branding. I've run a variety of linux binaries with this setup including: gcc 2.7.2 (and friends), quake, jdk, abuse, xterm, bash, xv, ... >Regards, >Marc. >---------------------------------------------------- >Marc van Kempen BowTie Technology >Email: marc@bowtie.nl WWW & Databases >tel. +31 40 2 43 20 65 >fax. +31 40 2 44 21 86 http://www.bowtie.nl >---------------------------------------------------- > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Mon Nov 4 06:58:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA22745 for hackers-outgoing; Mon, 4 Nov 1996 06:58:24 -0800 (PST) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA22730; Mon, 4 Nov 1996 06:58:18 -0800 (PST) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA05881; Mon, 4 Nov 96 15:57:34 +0100 Date: Mon, 4 Nov 96 15:57:34 +0100 Message-Id: <9611041457.AA05881@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: ache@nagual.ru Cc: hackers@freebsd.org, ports@freebsd.org In-Reply-To: <199611040142.EAA00736@nagual.ru> (ache@nagual.ru) Subject: Re: XFree86 3.2 now available. X-Mailer: Emacs Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7?= writes: >> XFree86 3.2 was just released a few days ago. I see that binaries for >> FreeBSD 2.1.5 and FreeBSD-current are available from ftp.xfree86.org, as >> well as source code. >> >> Briefly, the improvements in XFree86 3.2 are that it uses X11R6.1 as a >> codebase, and supports a number of new chips, including beta support for >> Matrox Millenium! >> >> I suggest that we move XFree86 3.2 into ftp.freebsd.org, and the next >> 2.2-snapshot should install that version by default. > Please, don't forget to update ports/x11/XFree86 too I am working on it. Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-hackers Mon Nov 4 06:58:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA22808 for hackers-outgoing; Mon, 4 Nov 1996 06:58:38 -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 GAA22793 for ; Mon, 4 Nov 1996 06:58:33 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA05007; Mon, 4 Nov 1996 08:57:06 -0600 From: Joe Greco Message-Id: <199611041457.IAA05007@brasil.moneng.mei.com> Subject: Re: Another data point in the daily panics... To: gpalmer@freebsd.org (Gary Palmer) Date: Mon, 4 Nov 1996 08:57:05 -0600 (CST) Cc: ponds!rivers@dg-rtp.dg.com, greg@uswest.net, freebsd-hackers@freefall.freebsd.org In-Reply-To: <4048.847003445@orion.webspan.net> from "Gary Palmer" at Nov 3, 96 01:44:05 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Thomas David Rivers wrote in message ID > <199611011143.GAA11189@lakes.water.net>: > > 2) Does INN & CCD hit the file system as hard as a CNEWS expire? > > (I wouldn't think so with an mmap'd active file. But then > > you probably shouldn't mmap the active file because of > > problems there.) > > I would be surprised if the drive loading was different. The only > thing that may change is the accessing of the drive where the > history/active file(s) are kept, and that shouldn't affect the CCD's > spool... all I know is when expireover/fastrm hits my FS, I can kiss > the performance goodbye. You are not kissing your performance totally goodbye if you have your news spool on multiple filesystems... but I assume you have them all striped into one mongo filesystem. Personally I wanted to see fastrm go as fast as possible, so I have six spool filesystems each built out of two Hawk drives CCD'd together... I run a special "expirerm" script that knows which hierarchies are on which disks, and then goes and invokes "fastrm" in parallel. This has the side effect of taking the machine to its knees for a few minutes, as I/O becomes saturated, but it takes 1/6 as long as doing it on a larger unified CCD spool.. hey, if you are going to take a performance hit, take a REAL performace hit but minimize the amount of time. (And no, I do not want to hear about the 'ease of administration' issue of a single spool from ANYBODY :-) ) newspump.sol.net, #25 on the Freenix list this month. :-) Pure FreeBSD. ... JG From owner-freebsd-hackers Mon Nov 4 07:51:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA26195 for hackers-outgoing; Mon, 4 Nov 1996 07:51:02 -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 HAA26190 for ; Mon, 4 Nov 1996 07:50:59 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vKRIM-0000ts-00; Mon, 4 Nov 1996 08:50:38 -0700 To: Julian Assange Subject: Re: scsi dat drive under freebsd Cc: freebsd-hackers@freebsd.org In-reply-to: Your message of "Mon, 04 Nov 1996 22:36:56 +1100." <199611041136.WAA09945@suburbia.net> References: <199611041136.WAA09945@suburbia.net> Date: Mon, 04 Nov 1996 08:50:38 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611041136.WAA09945@suburbia.net> Julian Assange writes: : Will freebsd support 4mm DAT tape drives? I haven't noticed any specific : support. The solaris st driver documentation has some magic-data for 4mm : DATs using Helical scans, which seems to imply that they need specific : support? Works like a champ for me when I brought home the 4mm dat from work. Warner From owner-freebsd-hackers Mon Nov 4 08:37:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA00970 for hackers-outgoing; Mon, 4 Nov 1996 08:37:45 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA00927; Mon, 4 Nov 1996 08:37:26 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA02631; Mon, 4 Nov 1996 16:56:35 +0100 From: Luigi Rizzo Message-Id: <199611041556.QAA02631@labinfo.iet.unipi.it> Subject: Re: pppgetty To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Mon, 4 Nov 1996 16:56:34 +0100 (MET) Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG, isp@FreeBSD.ORG In-Reply-To: <199611041413.IAA04882@brasil.moneng.mei.com> from "Joe Greco" at Nov 4, 96 08:13:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Jordan, > > I am not particularly thrilled about the idea of modems on the same box > as interactive logins, as it can be a security risk (think of what could ... > that ran on the 386DX/25 :-) A modified getty and login presents a > "normal" banner and login: prompt and then waits for input. A central > server is then contacted, and returns a reply based on local policy as > to what to do with the user (local login, remote login, etc)... all > very transparently. is this something similar to what mgetty does ? It has a "login.config" file which can take the appropriate decision basing on login name (not real Regular Expressions are supported, but that shouldn't be too hard). Maybe your stuff is more flexible, though. 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 Mon Nov 4 08:55:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA02318 for hackers-outgoing; Mon, 4 Nov 1996 08:55:02 -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 IAA02295; Mon, 4 Nov 1996 08:54:55 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.6/8.7.3) id KAA27670; Mon, 4 Nov 1996 10:54:47 -0600 (CST) Date: Mon, 4 Nov 1996 10:54:47 -0600 (CST) From: Mark Tinguely Message-Id: <199611041654.KAA27670@plains.nodak.edu> To: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Matrox Meteor and PPRO problem found Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So far the matrox meteor hard crashing the system is isolated to > 440fx (Natoma chipsets) based motherboards. I could get Neptune based PCI 90 Mhz Pentium system to crash with the meteor if I was capturing and viewing on the same machine. From owner-freebsd-hackers Mon Nov 4 09:22:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA04513 for hackers-outgoing; Mon, 4 Nov 1996 09:22:41 -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 JAA04468; Mon, 4 Nov 1996 09:22:13 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA05213; Mon, 4 Nov 1996 10:47:44 -0600 From: Joe Greco Message-Id: <199611041647.KAA05213@brasil.moneng.mei.com> Subject: Re: pppgetty To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 4 Nov 1996 10:47:44 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, jkh@time.cdrom.com, hackers@FreeBSD.ORG, isp@FreeBSD.ORG In-Reply-To: <199611041556.QAA02631@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 4, 96 04:56:34 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Jordan, > > > > I am not particularly thrilled about the idea of modems on the same box > > as interactive logins, as it can be a security risk (think of what could > ... > > that ran on the 386DX/25 :-) A modified getty and login presents a > > "normal" banner and login: prompt and then waits for input. A central > > server is then contacted, and returns a reply based on local policy as > > to what to do with the user (local login, remote login, etc)... all > > very transparently. > > is this something similar to what mgetty does ? It has a > "login.config" file which can take the appropriate decision basing on > login name (not real Regular Expressions are supported, but that > shouldn't be too hard). > > Maybe your stuff is more flexible, though. My stuff wants to rely on a central server, which traditionally for Solaria was very trivial (kicked off by inetd): /* * nlrd - the Network Login Router query daemon * * (c) 1993, 1994 by sol.net Network Services and Joe Greco * All rights reserved. */ #include #include #include #define NLRTAB "/usr/local/etc/nlrtab" #define NLRDEFAULT "solaria.sol.net" int crstrip(c) char *c; { register char *ptr; if (ptr = rindex(c, '\n')) { *ptr = '\0'; } if (ptr = rindex(c, '\r')) { *ptr = '\0'; } return(0); } int main() { char userbuf[80]; char usernm[256]; char hostnm[256]; struct passwd *passent; FILE *nlrtabfp; fgets(userbuf, sizeof(userbuf), stdin); crstrip(userbuf); if (nlrtabfp = fopen(NLRTAB, "r")) { while (! feof(nlrtabfp)) { fscanf(nlrtabfp, "%s %s", usernm, hostnm); if (! feof(nlrtabfp)) { if (! strcmp(usernm, userbuf)) { printf("%s\n", hostnm); exit(0); } } } fclose(nlrtabfp); } if (! (passent = getpwnam(userbuf))) { printf("-\n"); } else { printf("%s\n", NLRDEFAULT); } exit(0); } Yo, can you say "simple code"? I knew you could :-) (The code may not compile as I hacked out some #ifdef's and Solaria- specific code - but you see the idea) Since decision making is bubbled up to this level, there is nothing preventing you from adding a if (*userbuf == 'P') { printf("+\n"); exit(0); } after the crstrip(userbuf)... or any of many other possible changes. The "nlrtab" file was meant as an exceptions/override list, but out here at MEI I wrote a script to take the automounter's "auto.home" file and parse it up such that there is an entry for each engineer pointing to that engineer's desktop workstation. Works like a champ. Since I have not looked at mgetty, I can not say for sure what it does, but there is nothing that would prevent "nlrd" from being made into a gizmo that read out of a more generalized configuration file, and took action appropriately. RADIUS is essentially a much more complex, featureful, "do it all" version of my NLR system. I prefer simplicity sometimes. :-) ... JG From owner-freebsd-hackers Mon Nov 4 09:54:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA09196 for hackers-outgoing; Mon, 4 Nov 1996 09:54:34 -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 JAA09171; Mon, 4 Nov 1996 09:54:23 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.6/8.6.9) with ESMTP id JAA03231; Mon, 4 Nov 1996 09:54:14 -0800 (PST) To: Mark Tinguely cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Matrox Meteor and PPRO problem found In-reply-to: Your message of "Mon, 04 Nov 1996 10:54:47 CST." <199611041654.KAA27670@plains.nodak.edu> Date: Mon, 04 Nov 1996 09:54:14 -0800 Message-ID: <3229.847130054@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I could get Neptune based PCI 90 Mhz Pentium system to crash with the meteor > if I was capturing and viewing on the same machine. I did notice one thing today, though I don't know if it's at all relevant: ahc0 rev 0 int a irq 9 on pci0:11 meteor0 rev 0 int a irq 9 on pci0:19:0 Notice how they're both on the same IRQ? I can capture without saving all day, turn on grab-and-save, however, and I trigger the hang problem Amancio's been talking about. Interesting coincidence. Does our PCI code currently handle IRQ sharing with 100% success? Jordan From owner-freebsd-hackers Mon Nov 4 09:57:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA09521 for hackers-outgoing; Mon, 4 Nov 1996 09:57:50 -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 JAA09491; Mon, 4 Nov 1996 09:57:34 -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 JAA02073; Mon, 4 Nov 1996 09:57:23 -0800 (PST) Message-Id: <199611041757.JAA02073@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Mark Tinguely cc: hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Matrox Meteor and PPRO problem found In-reply-to: Your message of "Mon, 04 Nov 1996 10:54:47 CST." <199611041654.KAA27670@plains.nodak.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 09:57:23 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Mark Tinguely : > > So far the matrox meteor hard crashing the system is isolated to > > 440fx (Natoma chipsets) based motherboards. > > I could get Neptune based PCI 90 Mhz Pentium system to crash with the meteor > if I was capturing and viewing on the same machine. > Good point. I forgot about the Neptune chipset and possibly the Orion chipset. The story with the Orion chipset is that you have to tweak the CPU or the PCI chipset to increase the PCI bus speed. No news yet on a fix for the saa 7116 and 7196 based video capture boards. Amancio From owner-freebsd-hackers Mon Nov 4 10:07:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA10372 for hackers-outgoing; Mon, 4 Nov 1996 10:07:00 -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 KAA10352; Mon, 4 Nov 1996 10:06:48 -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 KAA02197; Mon, 4 Nov 1996 10:06:24 -0800 (PST) Message-Id: <199611041806.KAA02197@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Jordan K. Hubbard" cc: Mark Tinguely , hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Matrox Meteor and PPRO problem found In-reply-to: Your message of "Mon, 04 Nov 1996 09:54:14 PST." <3229.847130054@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 10:06:24 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of "Jordan K. Hubbard" : > > I could get Neptune based PCI 90 Mhz Pentium system to crash with the meteo r > > if I was capturing and viewing on the same machine. > > I did notice one thing today, though I don't know if it's at all > relevant: > > ahc0 rev 0 int a irq 9 on pci0:11 > meteor0 rev 0 int a irq 9 on pci0:19:0 > > Notice how they're both on the same IRQ? I can capture without saving > all day, turn on grab-and-save, however, and I trigger the hang > problem Amancio's been talking about. Interesting coincidence. Does > our PCI code currently handle IRQ sharing with 100% success? > If memory does not failed me I have taken out all PCI devices except for the ide controller and whrn saving images or running vic the meteor crashes my PPRO . Amancio From owner-freebsd-hackers Mon Nov 4 10:13:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA10856 for hackers-outgoing; Mon, 4 Nov 1996 10:13:46 -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 KAA10827; Mon, 4 Nov 1996 10:13:33 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.6/8.7.3) id MAA29835; Mon, 4 Nov 1996 12:13:26 -0600 (CST) Date: Mon, 4 Nov 1996 12:13:26 -0600 (CST) From: Mark Tinguely Message-Id: <199611041813.MAA29835@plains.nodak.edu> To: hasty@rah.star-gate.com, jkh@time.cdrom.com Subject: Re: Matrox Meteor and PPRO problem found Cc: hackers@freebsd.org, multimedia@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If memory does not failed me I have taken out all PCI devices except for the > ide controller and whrn saving images or running vic the meteor crashes > my PPRO . try this, do not run X on the capturing machine; display the vic on another machine. This trick for the most part) works on the neptune. I know the display and meteor were on different IRQs. I think the problem is other traffic on the PCI bus. --mark. From owner-freebsd-hackers Mon Nov 4 10:18:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA11089 for hackers-outgoing; Mon, 4 Nov 1996 10:18:31 -0800 (PST) Received: from matrix.uti.com (root@matrix.uti.com [204.248.52.7]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA11084 for ; Mon, 4 Nov 1996 10:18:25 -0800 (PST) Received: from Tower2.uti.com (carnahan.uti.com [204.248.61.32]) by matrix.uti.com (8.6.12/8.6.9) with ESMTP id MAA23173 for ; Mon, 4 Nov 1996 12:17:33 -0600 Message-Id: <199611041817.MAA23173@matrix.uti.com> From: "Ken" To: Date: Mon, 4 Nov 1996 12:18:04 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Later, Ken From owner-freebsd-hackers Mon Nov 4 10:21:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA11269 for hackers-outgoing; Mon, 4 Nov 1996 10:21: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 KAA11242; Mon, 4 Nov 1996 10:20:54 -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 KAA02367; Mon, 4 Nov 1996 10:20:42 -0800 (PST) Message-Id: <199611041820.KAA02367@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Mark Tinguely cc: jkh@time.cdrom.com, hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Matrox Meteor and PPRO problem found In-reply-to: Your message of "Mon, 04 Nov 1996 12:13:26 CST." <199611041813.MAA29835@plains.nodak.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 10:20:42 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Mark Tinguely : > > If memory does not failed me I have taken out all PCI devices except for t he > > ide controller and whrn saving images or running vic the meteor crashes > > my PPRO . > > try this, do not run X on the capturing machine; display the vic on another > machine. This trick for the most part) works on the neptune. I know the > display and meteor were on different IRQs. I think the problem is other > traffic on the PCI bus. > > --mark. Oh, I have code which does not use the display and it crashes hard the system. I think that you are right about other traffic being on the bus affecting the Meteor. Most likely is when the Meteor attempts to generate a halt or similar operation to stop and then resume. Cheers, Amancio From owner-freebsd-hackers Mon Nov 4 10:26:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA11625 for hackers-outgoing; Mon, 4 Nov 1996 10:26: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 KAA11466; Mon, 4 Nov 1996 10:24:26 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-7.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA07406 (5.67b/IDA-1.5); Mon, 4 Nov 1996 19:22:29 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id TAA01810; Mon, 4 Nov 1996 19:21:49 +0100 (MET) Message-Id: <199611041821.TAA01810@x14.mi.uni-koeln.de> Date: Mon, 4 Nov 1996 19:20:29 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: tinguely@plains.nodak.edu (Mark Tinguely), hackers@freebsd.org, multimedia@freebsd.org Subject: Re: Matrox Meteor and PPRO problem found In-Reply-To: <3229.847130054@time.cdrom.com>; from Jordan K. Hubbard on Nov 4, 1996 09:54:14 -0800 References: <3229.847130054@time.cdrom.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > > I could get Neptune based PCI 90 Mhz Pentium system to crash with the meteor > > if I was capturing and viewing on the same machine. > > I did notice one thing today, though I don't know if it's at all > relevant: > > ahc0 rev 0 int a irq 9 on pci0:11 > meteor0 rev 0 int a irq 9 on pci0:19:0 > > Notice how they're both on the same IRQ? I can capture without saving > all day, turn on grab-and-save, however, and I trigger the hang > problem Amancio's been talking about. Interesting coincidence. Does > our PCI code currently handle IRQ sharing with 100% success? Well, I'm quite convinced it does ... Regards, STefan From owner-freebsd-hackers Mon Nov 4 11:05:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA14409 for hackers-outgoing; Mon, 4 Nov 1996 11:05: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 LAA14397 for ; Mon, 4 Nov 1996 11:04:55 -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 NAA03944; Mon, 4 Nov 1996 13:04:12 -0600 (CST) Received: by bio-5.bsd.uchicago.edu (5.0/SMI-SVR4) id AA06751; Mon, 4 Nov 1996 13:04:09 +0600 Date: Mon, 4 Nov 1996 13:04:09 +0600 Message-Id: <9611041904.AA06751@bio-5.bsd.uchicago.edu> To: proff@suburbia.net Cc: freebsd-hackers@freebsd.org In-Reply-To: <199611041136.WAA09945@suburbia.net> (message from Julian Assange on Mon, 4 Nov 1996 22:36:56 +1100 (EST)) Subject: Re: scsi dat drive under freebsd From: Tim Pierce Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [shouldn't this be on freebsd-questions?] > Will freebsd support 4mm DAT tape drives? My WangTEK 6300-mumble series worked out of the box, as it were. There were a few growing pains, but I now suspect a misconfigured adapter rather than any kernel problems. > The solaris st driver documentation has some magic-data for 4mm > DATs using Helical scans, which seems to imply that they need specific > support? The Solaris st(7) page gives me the impression that `magic-data' is a (poorly-chosen) dummy name used as an example; note that the ficticious manufacturer of the dummy drive is `Magic DAT'. It should not be construed as evidence that 4mm drives necessarily need `magic numbers' in order to run. For example, here's the beginning of the st conf file on my Solaris box: name="st" class="scsi" target=0 lun=0; name="st" class="scsi" target=1 lun=0; name="st" class="scsi" target=2 lun=0; [ ... etc. ... ] When I plugged the aforementioned WangTEK into this box, it worked like a charm. Presumably you need to add magic data for drives which don't work precisely according to the SCSI spec, or which can't be properly auto-sensed -- items which FreeBSD handles via a `rogue list'. I'd guess that if you're thinking of buying a 4mm DAT for your FreeBSD system, don't worry too much about it, but check the handbook and the SCSI driver source for a list of rogue drives first to make sure you don't wind up with something that needs to be babysat. From owner-freebsd-hackers Mon Nov 4 11:12:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA15178 for hackers-outgoing; Mon, 4 Nov 1996 11:12: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 LAA15143; Mon, 4 Nov 1996 11:12:11 -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 LAA02830; Mon, 4 Nov 1996 11:09:23 -0800 (PST) Message-Id: <199611041909.LAA02830@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: se@ZPR.Uni-Koeln.DE (Stefan Esser) cc: jkh@time.cdrom.com (Jordan K. Hubbard), tinguely@plains.nodak.edu (Mark Tinguely), hackers@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: Matrox Meteor and PPRO problem found In-reply-to: Your message of "Mon, 04 Nov 1996 19:20:29 +0100." <199611041821.TAA01810@x14.mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 11:09:23 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Stefan Esser : > Jordan K. Hubbard writes: > > > I could get Neptune based PCI 90 Mhz Pentium system to crash with the met eor > > > if I was capturing and viewing on the same machine. > > > > I did notice one thing today, though I don't know if it's at all > > relevant: > > > > ahc0 rev 0 int a irq 9 on pci0:11 > > meteor0 rev 0 int a irq 9 on pci0:19:0 > > > > Notice how they're both on the same IRQ? I can capture without saving > > all day, turn on grab-and-save, however, and I trigger the hang > > problem Amancio's been talking about. Interesting coincidence. Does > > our PCI code currently handle IRQ sharing with 100% success? > > Well, I'm quite convinced it does ... Curious , how is the IRQs sharing currently being implemented? Or how does the PCI code know which adapter generated the interrupt? Tnks, Amancio From owner-freebsd-hackers Mon Nov 4 11:28:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA16641 for hackers-outgoing; Mon, 4 Nov 1996 11:28:50 -0800 (PST) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA16612; Mon, 4 Nov 1996 11:28:45 -0800 (PST) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id LAA12805; Mon, 4 Nov 1996 11:43:58 -0800 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id LAA18941; Mon, 4 Nov 1996 11:25:13 -0800 Date: Mon, 4 Nov 1996 11:25:12 -0800 (PST) From: Michael Dillon To: hackers@freebsd.org cc: isp@freebsd.org Subject: Re: pppgetty In-Reply-To: <199611041647.KAA05213@brasil.moneng.mei.com> Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 4 Nov 1996, Joe Greco wrote: > took action appropriately. RADIUS is essentially a much more complex, > featureful, "do it all" version of my NLR system. RADIUS is also the standard authentication protocol for ISP's and will be a required protocol for ISP's who wish to participate in ROAMing consortiums. If you are going to build a pppgetty it would be OK to have RADIUS authentication optional but it would be bad to leave it out entirely. Linux already has two variations of a hacked login supporting RADIUS and PPP. There is also a linux version of pppd that has been hacked to replace login. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com From owner-freebsd-hackers Mon Nov 4 11:30:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA17269 for hackers-outgoing; Mon, 4 Nov 1996 11:30:53 -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 LAA17221 for ; Mon, 4 Nov 1996 11:30:45 -0800 (PST) Received: (babkin@localhost) by hq.icb.chel.su (8.7.5/8.6.5) id AAA12170 for hackers@freebsd.org; Tue, 5 Nov 1996 00:30:46 +0500 (ESK) From: "Serge A. Babkin" Message-Id: <199611041930.AAA12170@hq.icb.chel.su> Subject: COFF->BSD converter To: hackers@freebsd.org Date: Tue, 5 Nov 1996 00:30:45 +0500 (ESK) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I wrote the COFF -> BSD object file converter. It needs more extensive testing but it works for now. Now the compatibility library and set of headers are needed to use it. I don't know how long would it take from me to write them. So if anyone can suggest any help it will be gladly accepted. The possible benefits from this project are: - getting semi-native version of Oracle (or any other product distributed as set of object files) - using some libraries (say, Motif) converted from SCO (it's possible to get personal SCO license for free, so why do not use some godd things from it ?) -SB From owner-freebsd-hackers Mon Nov 4 11:37:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA18798 for hackers-outgoing; Mon, 4 Nov 1996 11:37:18 -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 LAA18759; Mon, 4 Nov 1996 11:37:09 -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 LAA03024; Mon, 4 Nov 1996 11:37:07 -0800 (PST) Message-Id: <199611041937.LAA03024@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org cc: multimedia@freebsd.org Subject: SAA 7146 and SAA 7196 based boards Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 11:37:07 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone have a board based upon the above chipsets? The reason why I am asking is because the SAA 7146 is supposed to work with the Pentium Pro and the Natoma Chipset. Now , I am just trying to locate a working solution once we locate a board , it may take a while to fully qualify the board. Amancio From owner-freebsd-hackers Mon Nov 4 11:50:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA21339 for hackers-outgoing; Mon, 4 Nov 1996 11:50:18 -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 LAA21122; Mon, 4 Nov 1996 11:49:20 -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 UAA23464; Mon, 4 Nov 1996 20:47:42 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA00337; Mon, 4 Nov 1996 20:47:32 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id UAA20397; Mon, 4 Nov 1996 20:37:18 +0100 (MET) From: J Wunsch Message-Id: <199611041937.UAA20397@uriah.heep.sax.de> Subject: Re: pppgetty To: hackers@FreeBSD.org, isp@FreeBSD.org Date: Mon, 4 Nov 1996 20:37:18 +0100 (MET) In-Reply-To: <199611041413.IAA04882@brasil.moneng.mei.com> from Joe Greco at "Nov 4, 96 08:13:58 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 Joe Greco wrote: > This is really cool because it provides much of the core functionality > needed for ISP "terminal server" environments. Perhaps make a `termserver' port/package out of it? -- 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 Mon Nov 4 12:27:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA25005 for hackers-outgoing; Mon, 4 Nov 1996 12:27:01 -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 MAA24996 for ; Mon, 4 Nov 1996 12:26:57 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id MAA26717 for ; Mon, 4 Nov 1996 12:26:55 -0800 (PST) Message-Id: <199611042026.MAA26717@austin.polstra.com> To: freebsd-hackers@freebsd.org Subject: CVSup users PLEASE READ Date: Mon, 04 Nov 1996 12:26:54 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A few people have been experiencing hangs and/or premature EOFs from the server with CVSup 13.5. The problem is caused by an incompatible mix of Modula-3 shared libraries and header files. I inadvertently made it possible for this to happen during a brief window when I split the shared libraries into a separate "modula-3-lib" port. This problem does not affect people who installed the "cvsup-13.5" (binary) package. Here is the scenario under which you might encounter the problems: * You already had Modula-3 installed on your system. * You built CVSup 13.5 from the port (i.e., from source). * Building the CVSup port caused the new "modula-3-lib" port to get built and installed, but it did not cause the latest version of the "modula-3" port to get built and installed. Under this scenario, your CVSup port got built with a new set of shared libraries, but an old set of header files. Here is another indication that you are probably affected by this problem: * The file "/usr/local/lib/m3/FreeBSD/libm3.so.4.0" exists on your system. * The file "/usr/local/bin/m3build-4" does _not_ exist on your system. If you think you've been hit by this problem, you can fix it like this: * pkg_delete your "cvsup", "modula-3", and "modula-3-lib" packages (use "pkg_info -ac" to see which versions are installed). * Make sure these three ports are up to date in your ports tree. * Rebuild and install the "cvsup" port. (It will cause the other two ports to be rebuilt and installed too.) I apologize for causing this problem. I have fixed the ports so that it shouldn't happen any more. The time window during which the ports were wrong was from 10/29/96 23:14 GMT until 11/1/96 20:27 GMT. Thanks to Satoshi Asami for first noticing the problem, and to James FitzGibbon for helping me confirm the cause of it. -- 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 Mon Nov 4 12:35:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA25669 for hackers-outgoing; Mon, 4 Nov 1996 12:35:16 -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 MAA25652 for ; Mon, 4 Nov 1996 12:35:07 -0800 (PST) Received: from spiffy.cybernet.com (spiffy.cybernet.com [192.245.33.55]) by gateway.cybernet.com (8.7.6/8.7.3) with SMTP id PAA19310; Mon, 4 Nov 1996 15:41:07 -0500 (EST) Message-ID: X-Mailer: XFMail 0.5-beta [p0] on FreeBSD MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.0.5-beta.p0.FreeBSD:961104153310:416=_" In-Reply-To: <199611032111.NAA10511@rah.star-gate.com> Date: Mon, 04 Nov 1996 15:22:19 -0500 (EST) Organization: Cybernet Systems Corporation From: Mark Taylor To: Amancio Hasty Subject: RE: Geomview, Mbone and FreeBSD... Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk This message is in MIME format --_=XFMail.0.5-beta.p0.FreeBSD:961104153310:416=_ Content-Type: text/plain; charset=us-ascii Already done. I've submitted the patches to the Geometry Center. They were developed with the help of one of their workers. The Geometry Center, last I heard (a few months ago), had lost its funding source. The patch is simple, and can be found at: ftp://ftp.cybernet.com/pub/outgoing/FreeBSD/Geomview-1.5.patch or included in this email. On 18:11:20 Amancio Hasty wrote: >>Are there any stdio experts which can lend a hand in porting Geomview? > >Bill and a couple of people have develop a cool interface to track >mbone traffic using a 3d map of the world showing off the tunnels >as ballistic trajectories. > >At any rate, the file giving us a problem is futil.c . It likes to >manipulate the stdio data structures and does seeks on stdio. > >Here is the file and if requested I can give out a pointer to the >Geomview tar file: > > -------------------------------------------------------------------- Mark J. Taylor Network R&D Engineer Cybernet Systems mtaylor@cybernet.com 727 Airport Blvd. PHONE (313) 668-2567 Ann Arbor, MI 48108 FAX (313) 668-8780 -------------------------------------------------------------------- --_=XFMail.0.5-beta.p0.FreeBSD:961104153310:416=_ Content-Type: application/octet-stream; name=Geomview-1.5.patch; SizeOnDisk=5704 Content-Description: Geomview-1.5.patch Content-Transfer-Encoding: none Content-Disposition: attachment; filename="Geomview-1.5.patch" diff -N -c -r Geomview.orig/INSTALL Geomview/INSTALL *** Geomview.orig/INSTALL Fri Dec 2 15:03:13 1994 --- Geomview/INSTALL Sat Aug 10 19:20:28 1996 *************** *** 90,95 **** --- 90,96 ---- Sun Sparc, SunOS 4.1.x sun4 sun4 gcc Sun Sparc, Solaris 2.x solaris sun4 gcc Linux linux linux gcc + FreeBSD FreeBSD x11 gcc HP Risc hp x11 gcc Dec Alpha alpha x11 cc RS/6000 rs6000 x11 cc diff -N -c -r Geomview.orig/makefiles/mk.FreeBSD Geomview/makefiles/mk.FreeBSD *** Geomview.orig/makefiles/mk.FreeBSD Wed Dec 31 19:00:00 1969 --- Geomview/makefiles/mk.FreeBSD Wed Jul 24 17:19:29 1996 *************** *** 0 **** --- 1,25 ---- + # + # Makefile that sets machine-specific variables and rules + # for FreeBSD. + # + # + # A machine-specific makefile is included by all other makefiles. + # + + CPU = FreeBSD + MACHTYPE = x11 + RANLIB = ranlib + CC = gcc -pipe -DBSD -Dalloca=alloca + INSTALL = ${GEOM}/tools/install.bsd + AR = /usr/bin/ar + MKDEPFLAGS = + + # Add the location of the Motif (Xm/*.h) include files to the path. + # (Or, add a /usr/include/Xm sym-link and remove this -I option.) + SYSCOPTS = -I/usr/include/X11 + + SYSXLIBS = -L/usr/X11R6/lib -lXm -lXt -lXext -lX11 + + # Uncomment one of the SYSLIBS definitions according to your version of Linux: + + SYSLIBS = diff -c -r Geomview.orig/src/bin/geomview/x11/gvmain.c Geomview/src/bin/geomview /x11/gvmain.c *** Geomview.orig/src/bin/geomview/x11/gvmain.c Thu Nov 17 18:45:03 1994 --- Geomview/src/bin/geomview/x11/gvmain.c Wed Jul 24 16:19:58 1996 *************** *** 10,18 **** #ifdef __linux__ #include #endif ! #ifdef __osf__ #include #endif /* xgv main - global variables */ /***************************************************************************** / --- 10,21 ---- #ifdef __linux__ #include #endif ! #if defined(__osf__) || defined(__FreeBSD__) #include #endif + #ifdef __FreeBSD__ + #include + #endif /* xgv main - global variables */ /***************************************************************************** / *************** *** 40,46 **** __setfpucw(_FPU_IEEE); #endif ! #ifdef __osf__ signal(SIGFPE, SIG_IGN); /* Ignore e.g. divide-by-zero traps */ #endif --- 43,53 ---- __setfpucw(_FPU_IEEE); #endif ! #ifdef __FreeBSD__ ! fpsetmask(fpgetmask()&(~FP_X_DZ)); ! #endif ! ! #if defined(__osf__) || defined(__FreeBSD__) signal(SIGFPE, SIG_IGN); /* Ignore e.g. divide-by-zero traps */ #endif diff -c -r Geomview.orig/src/lib/oogl/refcomm/streampool.c Geomview/src/lib/oogl /refcomm/streampool.c *** Geomview.orig/src/lib/oogl/refcomm/streampool.c Sun Oct 16 19:11:55 1994 --- Geomview/src/lib/oogl/refcomm/streampool.c Thu Jul 11 22:39:50 1996 *************** *** 218,227 **** --- 218,235 ---- p->otype = PO_ALL; p->next = NULL; p->mode = rw; + #ifndef __FreeBSD__ p->seekable = (p->inf && tell(fileno(p->inf)) != -1 && + #else + p->seekable = (p->inf && ftell(p->inf) != -1 && + #endif !isatty(fileno(p->inf))); p->softEOF = !p->seekable; + #ifndef __FreeBSD__ p->level = (p->outf && tell(fileno(p->outf)) != -1 && + #else + p->level = (p->outf && ftell(p->outf) != -1 && + #endif !isatty(fileno(p->outf))) ? 0 : 1; p->flags = PF_TEMP; *************** *** 325,331 **** --- 333,343 ---- if(p->inf != NULL) { if(isatty(fileno(p->inf))) { p->softEOF = 1; + #ifndef __FreeBSD__ } else if(tell(fileno(p->inf)) != -1) { + #else + } else if(ftell(p->inf) != -1) { + #endif p->seekable = 1; } if(fstat(fileno(p->inf), &st) < 0 || (st.st_mode & S_IFMT) == S_IFIFO) *************** *** 335,341 **** --- 347,357 ---- watchfd(fileno(p->inf)); } if(p->level == 0 && p->outf && + #ifndef __FreeBSD__ (tell(fileno(p->outf)) == -1 || isatty(fileno(p->outf)))) + #else + (ftell(p->outf) == -1 || isatty(fileno(p->outf)))) + #endif p->level = 1; return p; } diff -c -r Geomview.orig/src/lib/oogl/util/error.c Geomview/src/lib/oogl/util/er ror.c *** Geomview.orig/src/lib/oogl/util/error.c Mon May 2 21:04:17 1994 --- Geomview/src/lib/oogl/util/error.c Tue Jul 9 11:19:38 1996 *************** *** 81,88 **** --- 81,90 ---- char * sperrno(unsigned int err) { + #if !defined(__FreeBSD__) extern int sys_nerr; extern char *sys_errlist[]; + #endif static char errstr[16]; if(err < sys_nerr) diff -c -r Geomview.orig/src/lib/oogl/util/futil.c Geomview/src/lib/oogl/util/fu til.c *** Geomview.orig/src/lib/oogl/util/futil.c Fri Aug 26 00:11:27 1994 --- Geomview/src/lib/oogl/util/futil.c Thu Jul 11 22:23:37 1996 *************** *** 154,159 **** --- 154,164 ---- #define _IO_read_ptr _gptr #define _IO_read_end _egptr #endif + #ifdef __FreeBSD__ + #define _base _bf._base + #define _ptr _p + #define _cnt _r + #endif /* Peer into a stdio buffer, check whether it has data available * for reading. Almost portable given the common stdio ancestry. *************** *** 800,806 **** #else /* Roughly vanilla stdio */ ! #if defined(AIX) || defined(__osf__) /* The stdio-buf-hacking code below doesn't work on some systems, so * just ship the data through a pipe. Small (8K?) size limit. --- 805,811 ---- #else /* Roughly vanilla stdio */ ! #if defined(AIX) || defined(__osf__) || defined(__FreeBSD__) /* The stdio-buf-hacking code below doesn't work on some systems, so * just ship the data through a pipe. Small (8K?) size limit. --_=XFMail.0.5-beta.p0.FreeBSD:961104153310:416=_-- End of MIME message From owner-freebsd-hackers Mon Nov 4 12:48:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA26599 for hackers-outgoing; Mon, 4 Nov 1996 12:48:04 -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 MAA26518; Mon, 4 Nov 1996 12:48:00 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.6/8.7.3) id OAA08712; Mon, 4 Nov 1996 14:47:52 -0600 (CST) Date: Mon, 4 Nov 1996 14:47:52 -0600 (CST) From: Mark Tinguely Message-Id: <199611042047.OAA08712@plains.nodak.edu> To: hasty@rah.star-gate.com Subject: Re: Matrox Meteor and PPRO problem found Cc: hackers@freebsd.org, jkh@time.cdrom.com, multimedia@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk moving the camera or a lot of motion in the frames could cause a crash. obvoiusly the computing of the vic/nv helps cause the problem. --mark From owner-freebsd-hackers Mon Nov 4 12:48:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA26660 for hackers-outgoing; Mon, 4 Nov 1996 12:48:10 -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 MAA26645 for ; Mon, 4 Nov 1996 12:48:08 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id MAA10084 for ; Mon, 4 Nov 1996 12:45:44 -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 MAA03563; Mon, 4 Nov 1996 12:43:39 -0800 (PST) Message-Id: <199611042043.MAA03563@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Mark Taylor cc: hackers@FreeBSD.org Subject: Re: Geomview, Mbone and FreeBSD... In-reply-to: Your message of "Mon, 04 Nov 1996 15:22:19 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 12:43:39 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I will give the patches a try.... Tnks! Amancio From owner-freebsd-hackers Mon Nov 4 12:53:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27193 for hackers-outgoing; Mon, 4 Nov 1996 12:53:44 -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 MAA27090; Mon, 4 Nov 1996 12:52:44 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA09835 (5.67b/IDA-1.5); Mon, 4 Nov 1996 21:46:56 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id VAA02155; Mon, 4 Nov 1996 21:46:29 +0100 (MET) Message-Id: <199611042046.VAA02155@x14.mi.uni-koeln.de> Date: Mon, 4 Nov 1996 21:45:09 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: hasty@rah.star-gate.com (Amancio Hasty) Cc: se@zpr.uni-koeln.de (Stefan Esser), jkh@time.cdrom.com (Jordan K. Hubbard), tinguely@plains.nodak.edu (Mark Tinguely), hackers@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: Matrox Meteor and PPRO problem found In-Reply-To: <199611041909.LAA02830@rah.star-gate.com>; from Amancio Hasty on Nov 4, 1996 11:09:23 -0800 References: <199611041909.LAA02830@rah.star-gate.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty writes: > >From The Desk Of Stefan Esser : > > Jordan K. Hubbard writes: > > > Notice how they're both on the same IRQ? I can capture without saving > > > all day, turn on grab-and-save, however, and I trigger the hang > > > problem Amancio's been talking about. Interesting coincidence. Does > > > our PCI code currently handle IRQ sharing with 100% success? > > > > Well, I'm quite convinced it does ... > > Curious , how is the IRQs sharing currently being implemented? > Or how does the PCI code know which adapter generated the interrupt? PCI device drivers have to assume that their interrupt handlers are called without actually needing service, and for that reason have to check the device's interrupt status register as soon as possible. A device that does not require service will return to a dispatcher loop (which has been registered as the interrupt handler) and that loop will apply the correct netmask (bio_mask, net_mask, ...) for each handler. This allows a network adapter and a SCSI card to share the same IRQ with no problems (and with no need to block out interrupts to unrelated devices for too long). The performance impact is very low (at most a few usecs per interrupt), if each driver really checks its interrupt status first. This code was written by Wolfgang Stanglmeier about one year ago and has been used with no (reported) problems on quite some systems, possibly without their owners knowing :) Regards, STefan From owner-freebsd-hackers Mon Nov 4 12:53:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27212 for hackers-outgoing; Mon, 4 Nov 1996 12:53:47 -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 MAA27087 for ; Mon, 4 Nov 1996 12:52:40 -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 VAA15064 for ; Mon, 4 Nov 1996 21:52:29 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id VAA25073 for freebsd-hackers@FreeBSD.org; Mon, 4 Nov 1996 21:51:52 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id VAA04304; Mon, 4 Nov 1996 21:44:14 +0100 (MET) Message-Id: <199611042044.VAA04304@keltia.freenix.fr> Date: Mon, 4 Nov 1996 21:44:14 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-hackers@freebsd.org Subject: Re: scsi dat drive under freebsd References: <199611041136.WAA09945@suburbia.net> X-Mailer: Mutt 0.49.07 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2632 In-Reply-To: <199611041136.WAA09945@suburbia.net>; from Julian Assange on Nov 4, 1996 22:36:56 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Julian Assange: > Will freebsd support 4mm DAT tape drives? I haven't noticed any specific > support. The solaris st driver documentation has some magic-data for 4mm > DATs using Helical scans, which seems to imply that they need specific > support? Apart from maybe supporting changing the compression mode by software, I don't see what could be special. Anyway, my HP 35480A has been working for a long long time. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #26: Sun Oct 27 19:39:11 MET 1996 From owner-freebsd-hackers Mon Nov 4 12:54:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27267 for hackers-outgoing; Mon, 4 Nov 1996 12:54:03 -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 MAA27247; Mon, 4 Nov 1996 12:53:57 -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 MAA03717; Mon, 4 Nov 1996 12:52:40 -0800 (PST) Message-Id: <199611042052.MAA03717@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Mark Tinguely cc: hackers@freebsd.org, jkh@time.cdrom.com, multimedia@freebsd.org Subject: Re: Matrox Meteor and PPRO problem found In-reply-to: Your message of "Mon, 04 Nov 1996 14:47:52 CST." <199611042047.OAA08712@plains.nodak.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 12:52:40 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think that the problem is related to the SAA 7116 not handling properly one of the modes in PCI 2.0 at least thats the latest info bit that I just received from Philips. The solution at least for the Natoma chipsets is to get a SAA 7146 and SAA 7196 video capture board. You have to take this with a grain of salt until we actually test such a board. Regards, Amancio >From The Desk Of Mark Tinguely : > moving the camera or a lot of motion in the frames could cause a crash. > obvoiusly the computing of the vic/nv helps cause the problem. > > --mark From owner-freebsd-hackers Mon Nov 4 13:00:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27836 for hackers-outgoing; Mon, 4 Nov 1996 13:00:43 -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 NAA27806; Mon, 4 Nov 1996 13:00:30 -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 MAA03792; Mon, 4 Nov 1996 12:59:12 -0800 (PST) Message-Id: <199611042059.MAA03792@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: se@zpr.uni-koeln.de (Stefan Esser) cc: jkh@time.cdrom.com (Jordan K. Hubbard), tinguely@plains.nodak.edu (Mark Tinguely), hackers@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: Matrox Meteor and PPRO problem found In-reply-to: Your message of "Mon, 04 Nov 1996 21:45:09 +0100." <199611042046.VAA02155@x14.mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 12:59:12 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Stefan Esser : > This code was written by Wolfgang Stanglmeier about one year ago > and has been used with no (reported) problems on quite some systems, > possibly without their owners knowing :) > > Regards, STefan Oh, I have a system with two video capture boards, an SMC etherpower and an S3 something PCI card so yes I have noticed and I was curious 8) BTW: Not sure that the problem is however when I replaced one of the video capture boards with an and adaptec 2940 it didn't work so I guess there is some more work to be done between: adpatec 2940/Matrox Meteor/S3/SMC etherpower. I just don't know which driver is mishandling the shared interrupt mechanism. Tnks! Amancio From owner-freebsd-hackers Mon Nov 4 13:13:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA28429 for hackers-outgoing; Mon, 4 Nov 1996 13:13:16 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA28418 for ; Mon, 4 Nov 1996 13:12:50 -0800 (PST) Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA21465; Mon, 4 Nov 1996 16:00:38 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA11237; Mon, 4 Nov 1996 16:00:39 -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 RAA03867; Mon, 4 Nov 1996 17:07:03 GMT Message-Id: <199611041707.RAA03867@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: Karl Denninger Cc: hackers@freebsd.org Subject: Re: Blargh - BSDI disk labels In-Reply-To: Your message of "Fri, 01 Nov 1996 18:00:51 CST." <199611020000.SAA14917@Jupiter.Mcs.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 17:07:02 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Blargh folks. > > FreeBSD doesn't understand BSDI disk labels. Like at all. > > There's no fix for this, is there? Here's a patch I made for 2.1.0 so I could mount my BSD/OS labels. It's ugly but it works... --- /sys/kern/subr_diskslice.c Tue May 30 08:05:51 1995 +++ ./subr_diskslice.c Mon Nov 4 17:03:58 1996 @@ -748,17 +748,27 @@ } if (pp->p_offset != start) { if (sname != NULL) { - printf( -"%s: rejecting BSD label: raw partition offset != slice offset\n", - sname); + if (sp->ds_type == 159 /* BSD/OS */ && pp->p_offset == 0) { + printf( +"%s: BSD/OS BSD label: restricting to diskslice\n", sname); + pp->p_offset += start; + pp->p_size -= start; + if (pp->p_size > sp->ds_size) + pp->p_size = sp->ds_size; + } else { + printf( +"%s: rejecting BSD label: raw partition offset (%d) != slice offset (%d)\n", + sname, pp->p_offset, start); + } slice_info(sname, sp); partition_info(sname, RAW_PART, pp); } - return ("fixlabel: raw partition offset != slice offset"); + if (pp->p_offset != start) + return ("fixlabel: raw partition offset != slice offset"); } if (pp->p_size != sp->ds_size) { if (sname != NULL) { - printf("%s: raw partition size != slice size\n", sname); + printf("%s: raw partition size (%d) != slice size (%d)\n", sname, pp->p_size, sp->ds_size); slice_info(sname, sp); partition_info(sname, RAW_PART, pp); } @@ -783,8 +793,8 @@ || pp->p_offset + pp->p_size < pp->p_offset) { if (sname != NULL) { printf( -"%s: rejecting partition in BSD label: it isn't entirely within the slice\n", - sname); +"%s: rejecting partition %c in BSD label: it isn't entirely within the slice\n", + sname, 'a' + part); if (!warned) { slice_info(sname, sp); warned = TRUE; -- 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 Mon Nov 4 13:37:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA29989 for hackers-outgoing; Mon, 4 Nov 1996 13:37:03 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA29962; Mon, 4 Nov 1996 13:36:50 -0800 (PST) Received: from brasil.moneng.mei.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vKWhI-0008reC; Mon, 4 Nov 96 13:36 PST Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA05636; Mon, 4 Nov 1996 15:31:55 -0600 From: Joe Greco Message-Id: <199611042131.PAA05636@brasil.moneng.mei.com> Subject: Re: pppgetty To: michael@memra.com (Michael Dillon) Date: Mon, 4 Nov 1996 15:31:55 -0600 (CST) Cc: hackers@freebsd.org, isp@freebsd.org In-Reply-To: from "Michael Dillon" at Nov 4, 96 11:25:12 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Mon, 4 Nov 1996, Joe Greco wrote: > > > took action appropriately. RADIUS is essentially a much more complex, > > featureful, "do it all" version of my NLR system. > > RADIUS is also the standard authentication protocol for ISP's and will be > a required protocol for ISP's who wish to participate in ROAMing > consortiums. If you are going to build a pppgetty it would be OK to > have RADIUS authentication optional but it would be bad to leave it out > entirely. > > Linux already has two variations of a hacked login supporting RADIUS > and PPP. There is also a linux version of pppd that has been hacked to > replace login. Having looked for both of these in the past (and not knowing where to look), I sorta gave up. I agree that RADIUS would be nice... :-) But I wasn't about to set out to start fresh when I could do something simple to extend what I already had. If you have any pointers, please pass them this way. ... JG From owner-freebsd-hackers Mon Nov 4 13:59:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA03047 for hackers-outgoing; Mon, 4 Nov 1996 13:59:27 -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 NAA03041 for ; Mon, 4 Nov 1996 13:59:25 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id NAA10184 for ; Mon, 4 Nov 1996 13:59:21 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id WAA01638 for FreeBSD-hackers@freebsd.org; Mon, 4 Nov 1996 22:57:51 +0100 (MET) From: Guido van Rooij Message-Id: <199611042157.WAA01638@gvr.win.tue.nl> Subject: frefall connectivity from europe To: FreeBSD-hackers@freebsd.org (FreeBSD-hackers) Date: Mon, 4 Nov 1996 22:57:51 +0100 (MET) 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 It's really horrible lately...Is the cause known? (I should add an option to traceroute that the startinbg ttl should be an option). -Guido From owner-freebsd-hackers Mon Nov 4 14:00:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03157 for hackers-outgoing; Mon, 4 Nov 1996 14:00:06 -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 NAA03085; Mon, 4 Nov 1996 13:59:50 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA05686; Mon, 4 Nov 1996 15:59:04 -0600 From: Joe Greco Message-Id: <199611042159.PAA05686@brasil.moneng.mei.com> Subject: Re: pppgetty To: j@uriah.heep.sax.de (J Wunsch) Date: Mon, 4 Nov 1996 15:59:04 -0600 (CST) Cc: hackers@FreeBSD.org, isp@FreeBSD.org In-Reply-To: <199611041937.UAA20397@uriah.heep.sax.de> from "J Wunsch" at Nov 4, 96 08:37:18 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As Joe Greco wrote: > > > This is really cool because it provides much of the core functionality > > needed for ISP "terminal server" environments. > > Perhaps make a `termserver' port/package out of it? That was why I asked for an enterprising ISP with a C hacker with a few CPU cycles to spare... :-) Someone also just brought up the Linux RADIUS thing again and maybe there is some merit in that. That would be ultimately cool... ... JG From owner-freebsd-hackers Mon Nov 4 14:01:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03425 for hackers-outgoing; Mon, 4 Nov 1996 14:01:20 -0800 (PST) Received: from rocket.comtrol.com (rocket.comtrol.com [204.73.219.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA03408 for ; Mon, 4 Nov 1996 14:01:08 -0800 (PST) Received: from amirpc (amir [204.73.219.82]) by rocket.comtrol.com (8.6.9/8.6.9) with SMTP id QAA15788 for ; Mon, 4 Nov 1996 16:00:12 -0600 Date: Mon, 4 Nov 1996 16:00:12 -0600 Message-Id: <199611042200.QAA15788@rocket.comtrol.com> X-Sender: amir@comtrol.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: amir@comtrol.com (Amir Farah) Subject: Re: driver problem Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have the following 2 questions: 1) Does FreeBSD have CAPI support?? Has anyone written little CAPI applications that I could use to test a driver?? 2) Is there multi-link PPP available for FreeBSD?? Thanks amir From owner-freebsd-hackers Mon Nov 4 14:06:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03993 for hackers-outgoing; Mon, 4 Nov 1996 14:06:17 -0800 (PST) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA03980; Mon, 4 Nov 1996 14:06:12 -0800 (PST) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id OAA15419; Mon, 4 Nov 1996 14:21:31 -0800 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id OAA20262; Mon, 4 Nov 1996 14:02:45 -0800 Date: Mon, 4 Nov 1996 14:02:44 -0800 (PST) From: Michael Dillon To: hackers@freebsd.org cc: isp@freebsd.org Subject: Re: pppgetty In-Reply-To: <199611042131.PAA05636@brasil.moneng.mei.com> Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 4 Nov 1996, Joe Greco wrote: > > RADIUS is also the standard authentication protocol for ISP's and will be > > a required protocol for ISP's who wish to participate in ROAMing > > consortiums. If you are going to build a pppgetty it would be OK to > > have RADIUS authentication optional but it would be bad to leave it out > > entirely. > > > > Linux already has two variations of a hacked login supporting RADIUS > > and PPP. There is also a linux version of pppd that has been hacked to > > replace login. > If you have any pointers, please pass them this way. You could try a web search for radlogin but the best would be to inquire on linuxisp@lightning.com or server-linux@netspace.org Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com From owner-freebsd-hackers Mon Nov 4 14:33:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07055 for hackers-outgoing; Mon, 4 Nov 1996 14:33:18 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA06740; Mon, 4 Nov 1996 14:29:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA06642; Mon, 4 Nov 1996 15:29:25 -0700 Message-Id: <199611042229.PAA06642@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Bruce Evans cc: dg@root.com, hackers@freefall.freebsd.org, smp@freefall.freebsd.org Subject: Re: ed0 timeouts In-reply-to: Your message of "Sun, 03 Nov 1996 20:47:03 +1100." <199611030947.UAA28658@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 15:29:25 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce, >My version of -current does lazy 8259-masking so that the 8259 doesn't >have to be masked unless the device interrupt repeats. I added these changes to the SMP kernel (#define APIC_LAZY in smptests.h, should be commited later today) and it seems to fix the problem! However system IO seemed to get hosed when I entered ddb to check the values of a few checkpoints I keep for debug. I went in/out of ddb several times (I think) but then going out the system "semi-hung": I could not get back to my virtual term, nor could I loggin anywhere else. I could ping the system so at least part of it lived... Have you ever seen similar problems with this code on your system? -- > It would probably >work to never mask it for edge triggered interrupts, but I'm worried >about noise, and level sensitive interrupts need to be handled somehow. I suspect I have only "greatly diminished" the occurrancees of INT loss, NOT completely eliminated them, since you mask on the 2nd hit. I would think a "properly" designed card would not be prone to noise. I could make 2 versions of the INTR macro (edge & level), and plug the appropriate one in as necessary in the XintXXX table. Opinions, anyone? -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Mon Nov 4 14:35:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07329 for hackers-outgoing; Mon, 4 Nov 1996 14:35:21 -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 OAA07306 for ; Mon, 4 Nov 1996 14:35:15 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id QAA18872; Mon, 4 Nov 1996 16:34:45 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma018853; Mon Nov 4 16:34:18 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 QAA20773; Mon, 4 Nov 1996 16:34:26 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.7.6/8.6.12) with ESMTP id QAA02056; Mon, 4 Nov 1996 16:34:37 -0600 (CST) Message-Id: <199611042234.QAA02056@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Serge A. Babkin" cc: hackers@freebsd.org Subject: Re: COFF->BSD converter In-reply-to: Your message of "Tue, 05 Nov 1996 00:30:45 +0500." <199611041930.AAA12170@hq.icb.chel.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 16:34:37 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Serge A. Babkin" writes: >I wrote the COFF -> BSD object file converter. It needs more extensive >testing but it works for now. Now the compatibility library and >set of headers are needed to use it. I don't know how long would it >take from me to write them. So if anyone can suggest any help >it will be gladly accepted. The possible benefits from this project are: > Cool, but doesn't objcopy do the conversion if properly configured? What compat libraries and headers do you need? Is the stuff from linux' ibcs2 any help? >- getting semi-native version of Oracle (or any other product distributed as >set of object files) > >- using some libraries (say, Motif) converted from SCO (it's possible >to get personal SCO license for free, so why do not use some >godd things from it ?) because the free SCO is ELF :( Is anyone working on ELF support for SCO? > >-SB > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Mon Nov 4 15:21:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA11369 for hackers-outgoing; Mon, 4 Nov 1996 15:21:43 -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 PAA11348 for ; Mon, 4 Nov 1996 15:21:37 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.6/8.7.3) id RAA10608 for freebsd-hackers@freebsd.org; Mon, 4 Nov 1996 17:21:31 -0600 (CST) Date: Mon, 4 Nov 1996 17:21:31 -0600 (CST) From: Mark Tinguely Message-Id: <199611042321.RAA10608@plains.nodak.edu> To: freebsd-hackers@freebsd.org Subject: Virtual/phyical alignments. Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I allocated a contiguous block that needs to be 8k aligned. I needed to calculate the current offset to keep to use with a hardware head/tail combination. I have been using: /* rsqh == virtual address of head pointer */ idt->rsqh = ((u_long) rsq) & 0x1ffc; This has been working for several weeks and then today, after a compile that added more paranoid checks, everything started failing. It took me at least an hour to discover that (rsq & 0x1000) == 0x1000 not 0 as I would have assumed. The physical address is 8k aligned but the virtual address is not. A substitution of : idt->rsqh = vtophys((u_long) rsq) & 0x1ffc; I know it is too difficult to assure alignments of physical/virtual are the same in the kernel (we demanding people always have these "it would be nice if" thoughts). Yes, I am glad it happened during developement instead of hate mail and in the very least let this be a warning to others... don't assume virtual alignment when allocating for physical alignment. --mark "in the belltower with a high powered rifle :)". From owner-freebsd-hackers Mon Nov 4 15:39:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA12834 for hackers-outgoing; Mon, 4 Nov 1996 15:39:12 -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 PAA12825 for ; Mon, 4 Nov 1996 15:39:07 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.7.6/8.7.3) id JAA25538 for freebsd-hackers@freebsd.org; Tue, 5 Nov 1996 09:39:05 +1000 Received: from pandora.devetir.qld.gov.au by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id JAA11443 for ; Tue, 5 Nov 1996 09:41:55 +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 JAA08094 for ; Tue, 5 Nov 1996 09:40:55 +1000 Received: by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id XAA26280; Mon, 4 Nov 1996 23:39:23 GMT Date: Mon, 4 Nov 1996 23:39:23 GMT Message-Id: <199611042339.XAA26280@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: <199611041930.AAA12170@hq.icb.chel.su> In-Reply-To: <199611041930.AAA12170@hq.icb.chel.su> From: sysseh@devetir.qld.gov.au (Stephen Hocking) Subject: Re: COFF->BSD converter X-Original-Newsgroups: local.freebsd.hackers To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199611041930.AAA12170@hq.icb.chel.su>, "Serge A. Babkin" writes: > I wrote the COFF -> BSD object file converter. It needs more extensive > testing but it works for now. Now the compatibility library and > set of headers are needed to use it. I don't know how long would it > take from me to write them. So if anyone can suggest any help > it will be gladly accepted. The possible benefits from this project are: Alright! Where do I get it? And do you have an ELF to a.out converter? > > - using some libraries (say, Motif) converted from SCO (it's possible > to get personal SCO license for free, so why do not use some > godd things from it ?) > I have this same license, along with the media, but it remains to be seen if the Motif libraries are COFF or ELF. As it is SCO V5, I think it's ELF. Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-hackers Mon Nov 4 15:45:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA13417 for hackers-outgoing; Mon, 4 Nov 1996 15:45:12 -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 PAA13384; Mon, 4 Nov 1996 15:45:04 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id SAA25563; Mon, 4 Nov 1996 18:42:20 -0500 (EST) Date: Mon, 4 Nov 1996 18:42:20 -0500 (EST) From: Mark Mayo To: Terry Lambert cc: Warner Losh , jmb@freefall.freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: /usr/obj size In-Reply-To: <199611032116.OAA03231@phaeton.artisoft.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 Sun, 3 Nov 1996, Terry Lambert wrote: > > However, one thing is clear: You need about 1.5G of disk space to have > > an effective development machine. I have 2.25G on my machine, and > > things get a little cramped when I try to do both OpenBSD things and > > FreeBSD things at the same time. > > Amen. I have 3G on this box, and I do FreeBSD, FreeBSD + Terry, > FreeBSD + SMP, and OpenBSD. It's still quite cramped. Hmmm, I only have ~600MB for my FreeBSD partition. But the good news is that I managed to move as much as I could (/home, etc..) into the zip, leaing me with ~118MB free after the new supof the src tree. A quick note on that point: nowhere on the freebsd web pages does it mention that the src-contrib delta is onw part of the CVS tree... Of course, I just fired off the cvsup-file from ftp.freebsd.org, after adding the tag=RELENG_2_2 and there was no src-contrib line. I quickly figured it out after the make world failed trying to cleandir /usr/src/contrib (which didn't exisit on my August SNAP). Obvious problem, but if I hadn't been paying attention to the -current news I maybe wouldn't have guessed.. On the topic of hard-disks, I obviously need a new one, so what do you all recomend for a FAST-SCSI-2 drive. I just have an NCR c810 controller, so I don't need the Ultra-Wide stuff. My local store is telling me that a 2GB Quantum Atlas is about $900 CDN!!! And his price on a Seagate Hawk 2.1GB is $700. Seems high to me, and I remember Terry and others debating the equal cost of IDE and SCSI a while ago.. The exchange rate is about 0.76 right now, so my local guy wants about $500 US for the Hawk. Like I said, seems high.. Oh, I can't forget to say thanks to John Polstra, the CVSup utility is amazing!! The entire process only took about 1.5 hours to get the new tree (including the contrib stuff) over a 33.6 modem! Wow. TIA, -Mark ------------------------------------------- | Mark Mayo mark@quickweb.com | | RingZero Comp. www.quickweb.com | ------------------------------------------- "To iterate is human, to recurse divine." - L. Peter Deutsch > > I'm waiting for the 24G drives to catch on so that the 9G prices > drop. 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 Mon Nov 4 16:04:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA15187 for hackers-outgoing; Mon, 4 Nov 1996 16:04:45 -0800 (PST) Received: from netrover.com (ottawa3.netrover.com [205.209.19.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA15180 for ; Mon, 4 Nov 1996 16:04:39 -0800 (PST) Received: (from brianc@localhost) by netrover.com (8.7.6/8.7.3) id TAA00489; Mon, 4 Nov 1996 19:03:17 -0500 (EST) Message-Id: <199611050003.TAA00489@netrover.com> Date: Mon, 4 Nov 1996 19:03:17 -0500 From: brianc@netrover.com (Brian Campbell) To: freebsd-hackers@FreeBSD.org Subject: Re: COFF->BSD converter References: <199611041930.AAA12170@hq.icb.chel.su> <199611042339.XAA26280@netfl15a.devetir.qld.gov.au> X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 Reply-to: brianc@pobox.com In-Reply-To: <199611042339.XAA26280@netfl15a.devetir.qld.gov.au>; from Stephen Hocking on Nov 4, 1996 23:39:23 +0000 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Is there an objdump for FreeBSD? From owner-freebsd-hackers Mon Nov 4 16:21:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16120 for hackers-outgoing; Mon, 4 Nov 1996 16:21:42 -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 QAA16106 for ; Mon, 4 Nov 1996 16:21:37 -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 QAA13187; Mon, 4 Nov 1996 16:17:27 -0800 (PST) Message-ID: <327E8785.2781E494@whistle.com> Date: Mon, 04 Nov 1996 16:17:09 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Matt Thomas CC: Karl Denninger , hackers@FreeBSD.org Subject: Re: Blargh - BSDI disk labels References: <199611041707.RAA03867@whydos.lkg.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Matt Thomas wrote: > > > > > Blargh folks. > > > > FreeBSD doesn't understand BSDI disk labels. Like at all. > > > > There's no fix for this, is there? > > Here's a patch I made for 2.1.0 so I could mount my BSD/OS labels. > It's ugly but it works... bruce, can you do something with this and get it in? I keep getting asked about this.. julian From owner-freebsd-hackers Mon Nov 4 16:27:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16322 for hackers-outgoing; Mon, 4 Nov 1996 16:27:37 -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 QAA16305 for ; Mon, 4 Nov 1996 16:27:28 -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 QAA13513; Mon, 4 Nov 1996 16:24:24 -0800 (PST) Message-ID: <327E892A.446B9B3D@whistle.com> Date: Mon, 04 Nov 1996 16:24:10 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Amir Farah CC: hackers@FreeBSD.org Subject: Re: driver problem References: <199611042200.QAA15788@rocket.comtrol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Amir Farah wrote: > > I have the following 2 questions: > > 1) Does FreeBSD have CAPI support?? Has anyone written little CAPI > applications that I could use to test a driver?? what is CAPI? > > 2) Is there multi-link PPP available for FreeBSD?? check mpd in ftp.freebsd.org/pub/FreeBSD/incoming > > Thanks > > amir From owner-freebsd-hackers Mon Nov 4 16:51:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA17708 for hackers-outgoing; Mon, 4 Nov 1996 16:51:53 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA17699 for ; Mon, 4 Nov 1996 16:51:45 -0800 (PST) Received: from alpo.whistle.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vKZjm-0008rmC; Mon, 4 Nov 96 16:51 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 QAA13940 for ; Mon, 4 Nov 1996 16:44:24 -0800 (PST) Message-ID: <327E8DDA.59E2B600@whistle.com> Date: Mon, 04 Nov 1996 16:44:10 -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: [Fwd: usr.sbin.inetd] Content-Type: multipart/mixed; boundary="------------FF6D5DF3F54BC7E1CFBAE39" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------FF6D5DF3F54BC7E1CFBAE39 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is a compatible but useful addition to inetd. I've wanted this for a long time.. one change... in the man page it describes tha option as [something I forget] but we decided that it should be better described as: {wait|nowait}[/maxclients] does anyone see a reason this is bad? does anyone else thonk it's useful? the reason to do it: it allows one to limit the effect on a small memory machine of multiple simultanious connection requests. The example would be if you suddenly get 20 mail messages incoming, accepting them all would be suicide, as the machine would thrash itself to death. with this option you can limit the effect. processing them 3 at a time will get them done quicker than thrashing on 20 at once which might take 100 times as long.. for our embedded FreeBSD box this has turned out to be the SINGLE BIGGEST improvement to user perceptions of unreliablility and performance. I'd like ot see it a standard optin so that we don't have to keep a separate inetd in out tree, because we can't do without it.. comments please.. (BTW it includes a cleanup to make it compile in -wall) julian --------------FF6D5DF3F54BC7E1CFBAE39 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from whistle.com (whistle.whistle.com [207.76.205.131]) by alpo.whistle.com (8.8.2/8.8.2) with ESMTP id NAA10448 for ; Mon, 4 Nov 1996 13:51:42 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA29848 for ; Mon, 4 Nov 1996 13:51:40 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma029844; Mon Nov 4 13:51:26 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id NAA02353 for julian@whistle.com; Mon, 4 Nov 1996 13:51:25 -0800 (PST) From: Archie Cobbs Message-Id: <199611042151.NAA02353@bubba.whistle.com> Subject: usr.sbin.inetd To: julian@whistle.com (Julian Elischer) Date: Mon, 4 Nov 1996 13:51:25 -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 Index: Makefile =================================================================== RCS file: /cvs/freebsd/src/usr.sbin/inetd/Makefile,v retrieving revision 1.3 diff -c -r1.3 Makefile *** 1.3 1996/01/01 08:42:22 --- Makefile 1996/11/04 21:50:26 *************** *** 4,9 **** --- 4,12 ---- MAN8= inetd.8 MLINKS= inetd.8 inetd.conf.5 + COPTS+= -Wall + #COPTS+= -DSANITY_CHECK + DPADD+= ${LIBUTIL} LDADD+= -lutil Index: inetd.8 =================================================================== RCS file: /cvs/freebsd/src/usr.sbin/inetd/inetd.8,v retrieving revision 1.9 diff -c -r1.9 inetd.8 *** 1.9 1996/08/09 22:20:23 --- inetd.8 1996/11/04 21:50:26 *************** *** 101,107 **** service name socket type protocol ! wait/nowait user server program server program arguments --- 101,107 ---- service name socket type protocol ! wait/nowait[/max-child] user server program server program arguments *************** *** 260,265 **** --- 260,274 ---- requests until a timeout. TCPMUX services must use .Dq nowait . + .Pp + The maximum number of outstanding child processes (or ``threads'') + for a ``nowait'' service may be explicitly specified by appending a + ``/'' followed by the number to the ``nowait'' keyword. Normally + (or if a value of zero is specified) there is no maximum. Otherwise, + once the maximum is reached, further connection attempts will be + queued up until an existing child process finishes. This also works + in the case of ``wait'' mode, although a value other than one (the + default) might not make sense in some cases. .Pp The .Em user Index: inetd.c =================================================================== RCS file: /cvs/freebsd/src/usr.sbin/inetd/inetd.c,v retrieving revision 1.15 diff -c -r1.15 inetd.c *** 1.15 1996/11/01 01:42:08 --- inetd.c 1996/11/04 21:50:26 *************** *** 32,45 **** */ #ifndef lint ! static char copyright[] = "@(#) Copyright (c) 1983, 1991, 1993, 1994\n\ The Regents of the University of California. All rights reserved.\n"; #endif /* not lint */ #ifndef lint /* from: @(#)inetd.c 8.4 (Berkeley) 4/13/94"; */ ! static char inetd_c_rcsid[] = "$Id: inetd.c,v 1.15 1996/11/01 01:42:08 alex Exp $"; #endif /* not lint */ --- 32,45 ---- */ #ifndef lint ! static char copyright[] __attribute__ ((unused)) = "@(#) Copyright (c) 1983, 1991, 1993, 1994\n\ The Regents of the University of California. All rights reserved.\n"; #endif /* not lint */ #ifndef lint /* from: @(#)inetd.c 8.4 (Berkeley) 4/13/94"; */ ! static char inetd_c_rcsid[] __attribute__ ((unused)) = "$Id: inetd.c,v 1.15 1996/11/01 01:42:08 alex Exp $"; #endif /* not lint */ *************** *** 112,117 **** --- 112,118 ---- #include #include #include + #include #include #include *************** *** 124,139 **** #include #include #include #include "pathnames.h" #define TOOMANY 256 /* don't start more than TOOMANY */ #define CNT_INTVL 60 /* servers in CNT_INTVL sec. */ #define RETRYTIME (60*10) /* retry after bind or server fail */ #define SIGBLOCK (sigmask(SIGCHLD)|sigmask(SIGHUP)|sigmask(SIGALRM)) - int debug = 0; int log = 0; int nsock, maxsock; --- 125,141 ---- #include #include #include + #include #include "pathnames.h" #define TOOMANY 256 /* don't start more than TOOMANY */ #define CNT_INTVL 60 /* servers in CNT_INTVL sec. */ #define RETRYTIME (60*10) /* retry after bind or server fail */ + #define MAX_MAXCHLD 32767 /* max allowable max children */ #define SIGBLOCK (sigmask(SIGCHLD)|sigmask(SIGHUP)|sigmask(SIGALRM)) int debug = 0; int log = 0; int nsock, maxsock; *************** *** 149,155 **** char *se_service; /* name of service */ int se_socktype; /* type of socket to use */ char *se_proto; /* protocol used */ ! short se_wait; /* single threaded server */ short se_checked; /* looked at during merge */ char *se_user; /* user name to run as */ struct biltin *se_bi; /* if built-in, description */ --- 151,159 ---- char *se_service; /* name of service */ int se_socktype; /* type of socket to use */ char *se_proto; /* protocol used */ ! short se_maxchild; /* max number of children */ ! short se_numchild; /* current number of children */ ! short *se_pids; /* array of child pids */ short se_checked; /* looked at during merge */ char *se_user; /* user name to run as */ struct biltin *se_bi; /* if built-in, description */ *************** *** 159,165 **** int se_fd; /* open descriptor */ int se_type; /* type */ struct sockaddr_in se_ctrladdr;/* bound address */ ! int se_rpc; /* ==1 if RPC service */ int se_rpc_prog; /* RPC program number */ u_int se_rpc_lowvers; /* RPC low version */ u_int se_rpc_highvers; /* RPC high version */ --- 163,170 ---- int se_fd; /* open descriptor */ int se_type; /* type */ struct sockaddr_in se_ctrladdr;/* bound address */ ! u_char se_accept; /* i.e., wait/nowait mode */ ! u_char se_rpc; /* ==1 if RPC service */ int se_rpc_prog; /* RPC program number */ u_int se_rpc_lowvers; /* RPC low version */ u_int se_rpc_highvers; /* RPC high version */ *************** *** 195,201 **** --- 200,209 ---- char *newstr __P((char *)); char *nextline __P((FILE *)); void print_service __P((char *, struct servtab *)); + void addchild __P((struct servtab *, int)); void reapchild __P((int)); + void enable __P((struct servtab *)); + void disable __P((struct servtab *)); void retry __P((int)); int setconfig __P((void)); void setup __P((struct servtab *)); *************** *** 209,215 **** char *bi_service; /* internally provided service name */ int bi_socktype; /* type of socket supported */ short bi_fork; /* 1 if should fork before call */ ! short bi_wait; /* 1 if should wait for child */ void (*bi_fn)(); /* function which performs it */ } biltins[] = { /* Echo received data */ --- 217,223 ---- char *bi_service; /* internally provided service name */ int bi_socktype; /* type of socket supported */ short bi_fork; /* 1 if should fork before call */ ! short bi_maxchild; /* max number of children (default) */ void (*bi_fn)(); /* function which performs it */ } biltins[] = { /* Echo received data */ *************** *** 298,304 **** if (!inet_aton(optarg, &bind_address)) { syslog(LOG_ERR, "-a %s: invalid IP address", optarg); ! exit(1); } break; case 'p': --- 306,312 ---- if (!inet_aton(optarg, &bind_address)) { syslog(LOG_ERR, "-a %s: invalid IP address", optarg); ! exit(EX_USAGE); } break; case 'p': *************** *** 309,315 **** syslog(LOG_ERR, "usage: inetd [-dl] [-a address] [-R rate]" " [-p pidfile] [conf-file]"); ! exit(1); } argc -= optind; argv += optind; --- 317,323 ---- syslog(LOG_ERR, "usage: inetd [-dl] [-a address] [-R rate]" " [-p pidfile] [conf-file]"); ! exit(EX_USAGE); } argc -= optind; argv += optind; *************** *** 383,389 **** if (debug) fprintf(stderr, "someone wants %s\n", sep->se_service); ! if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) { ctrl = accept(sep->se_fd, (struct sockaddr *)0, (int *)0); if (debug) --- 391,397 ---- if (debug) fprintf(stderr, "someone wants %s\n", sep->se_service); ! if (sep->se_accept && sep->se_socktype == SOCK_STREAM) { ctrl = accept(sep->se_fd, (struct sockaddr *)0, (int *)0); if (debug) *************** *** 395,401 **** sep->se_service); continue; } ! if(log) { i = sizeof peer; if(getpeername(ctrl, (struct sockaddr *) &peer, &i)) { --- 403,409 ---- sep->se_service); continue; } ! if (log) { i = sizeof peer; if(getpeername(ctrl, (struct sockaddr *) &peer, &i)) { *************** *** 456,475 **** } if (pid < 0) { syslog(LOG_ERR, "fork: %m"); ! if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) close(ctrl); sigsetmask(0L); sleep(1); continue; } ! if (pid && sep->se_wait) { ! sep->se_wait = pid; ! if (sep->se_fd >= 0) { ! FD_CLR(sep->se_fd, &allsock); ! nsock--; ! } ! } sigsetmask(0L); if (pid == 0) { if (dofork) { --- 464,478 ---- } if (pid < 0) { syslog(LOG_ERR, "fork: %m"); ! if (sep->se_accept && sep->se_socktype == SOCK_STREAM) close(ctrl); sigsetmask(0L); sleep(1); continue; } ! if (pid) ! addchild(sep, pid); sigsetmask(0L); if (pid == 0) { if (dofork) { *************** *** 478,488 **** maxsock); for (tmpint = maxsock; tmpint > 2; tmpint--) if (tmpint != ctrl) ! close(tmpint); } ! if (sep->se_bi) (*sep->se_bi->bi_fn)(ctrl, sep); ! else { if (debug) fprintf(stderr, "%d execl %s\n", getpid(), sep->se_server); --- 481,492 ---- maxsock); for (tmpint = maxsock; tmpint > 2; tmpint--) if (tmpint != ctrl) ! (void) close(tmpint); } ! if (sep->se_bi) { (*sep->se_bi->bi_fn)(ctrl, sep); ! /* NOTREACHED */ ! } else { if (debug) fprintf(stderr, "%d execl %s\n", getpid(), sep->se_server); *************** *** 497,522 **** sep->se_user); if (sep->se_socktype != SOCK_STREAM) recv(0, buf, sizeof (buf), 0); ! _exit(1); } if (setsid() < 0) { syslog(LOG_ERR, "%s: can't setsid(): %m", sep->se_service); ! /* _exit(1); not fatal yet */ } if (pwd->pw_uid) { if (setlogin(sep->se_user) < 0) { syslog(LOG_ERR, "%s: can't setlogin(%s): %m", sep->se_service, sep->se_user); ! /* _exit(1); not fatal yet */ } if (setgid(pwd->pw_gid) < 0) { syslog(LOG_ERR, "%s: can't set gid %d: %m", sep->se_service, pwd->pw_gid); ! _exit(1); } (void) initgroups(pwd->pw_name, pwd->pw_gid); --- 501,526 ---- sep->se_user); if (sep->se_socktype != SOCK_STREAM) recv(0, buf, sizeof (buf), 0); ! _exit(EX_NOUSER); } if (setsid() < 0) { syslog(LOG_ERR, "%s: can't setsid(): %m", sep->se_service); ! /* _exit(EX_OSERR); not fatal yet */ } if (pwd->pw_uid) { if (setlogin(sep->se_user) < 0) { syslog(LOG_ERR, "%s: can't setlogin(%s): %m", sep->se_service, sep->se_user); ! /* _exit(EX_OSERR); not yet */ } if (setgid(pwd->pw_gid) < 0) { syslog(LOG_ERR, "%s: can't set gid %d: %m", sep->se_service, pwd->pw_gid); ! _exit(EX_OSERR); } (void) initgroups(pwd->pw_name, pwd->pw_gid); *************** *** 524,530 **** syslog(LOG_ERR, "%s: can't set uid %d: %m", sep->se_service, pwd->pw_uid); ! _exit(1); } } execv(sep->se_server, sep->se_argv); --- 528,534 ---- syslog(LOG_ERR, "%s: can't set uid %d: %m", sep->se_service, pwd->pw_uid); ! _exit(EX_OSERR); } } execv(sep->se_server, sep->se_argv); *************** *** 532,551 **** recv(0, buf, sizeof (buf), 0); syslog(LOG_ERR, "cannot execute %s: %m", sep->se_server); ! _exit(1); } } ! if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) close(ctrl); } } } void reapchild(signo) int signo; { ! int status; pid_t pid; struct servtab *sep; --- 536,581 ---- recv(0, buf, sizeof (buf), 0); syslog(LOG_ERR, "cannot execute %s: %m", sep->se_server); ! _exit(EX_OSERR); } } ! if (sep->se_accept && sep->se_socktype == SOCK_STREAM) close(ctrl); } } } + /* + * Record a new child pid for this service. If we've reached the + * limit on children, then stop accepting incoming requests. + */ + + void + addchild(struct servtab *sep, pid_t pid) + { + #ifdef SANITY_CHECK + if (sep->se_numchild >= sep->se_maxchild) { + syslog(LOG_ERR, "%s: %d >= %d", + __FUNCTION__, sep->se_numchild, sep->se_maxchild); + exit(EX_SOFTWARE); + } + #endif + if (sep->se_maxchild == 0) + return; + sep->se_pids[sep->se_numchild++] = pid; + if (sep->se_numchild == sep->se_maxchild) + disable(sep); + } + + /* + * Some child process has exited. See if it's on somebody's list. + */ + void reapchild(signo) int signo; { ! int k, status; pid_t pid; struct servtab *sep; *************** *** 556,574 **** if (debug) fprintf(stderr, "%d reaped, status %#x\n", pid, status); ! for (sep = servtab; sep; sep = sep->se_next) ! if (sep->se_wait == pid) { ! if (status) ! syslog(LOG_WARNING, ! "%s: exit status 0x%x", ! sep->se_server, status); ! if (debug) ! fprintf(stderr, "restored %s, fd %d\n", ! sep->se_service, sep->se_fd); ! FD_SET(sep->se_fd, &allsock); ! nsock++; ! sep->se_wait = 1; ! } } } --- 586,612 ---- if (debug) fprintf(stderr, "%d reaped, status %#x\n", pid, status); ! for (sep = servtab; sep; sep = sep->se_next) { ! for (k = 0; k < sep->se_numchild; k++) ! if (sep->se_pids[k] == pid) ! break; ! if (k == sep->se_numchild) ! continue; ! if (sep->se_numchild == sep->se_maxchild) ! enable(sep); ! memmove(sep->se_pids + k, sep->se_pids + k + 1, ! --sep->se_numchild * sizeof(*sep->se_pids)); ! if (status) ! syslog(LOG_WARNING, ! "%s: exit status 0x%x", ! sep->se_server, status); ! if (debug) ! fprintf(stderr, ! "restored %s, fd %d\n", ! sep->se_service, ! sep->se_fd); ! break; ! } } } *************** *** 576,582 **** config(signo) int signo; { ! struct servtab *sep, *cp, **sepp; struct passwd *pwd; long omask; --- 614,620 ---- config(signo) int signo; { ! struct servtab *sep, *new, **sepp; struct passwd *pwd; long omask; *************** *** 586,628 **** } for (sep = servtab; sep; sep = sep->se_next) sep->se_checked = 0; ! while (cp = getconfigent()) { ! if ((pwd = getpwnam(cp->se_user)) == NULL) { syslog(LOG_ERR, "%s/%s: No such user '%s', service ignored", ! cp->se_service, cp->se_proto, cp->se_user); continue; } for (sep = servtab; sep; sep = sep->se_next) ! if (strcmp(sep->se_service, cp->se_service) == 0 && ! strcmp(sep->se_proto, cp->se_proto) == 0) break; if (sep != 0) { int i; omask = sigblock(SIGBLOCK); ! /* ! * sep->se_wait may be holding the pid of a daemon ! * that we're waiting for. If so, don't overwrite ! * it unless the config file explicitly says don't ! * wait. ! */ ! if (cp->se_bi == 0 && ! (sep->se_wait == 1 || cp->se_wait == 0)) ! sep->se_wait = cp->se_wait; ! #define SWAP(a, b) { char *c = a; a = b; b = c; } ! if (cp->se_user) ! SWAP(sep->se_user, cp->se_user); ! if (cp->se_server) ! SWAP(sep->se_server, cp->se_server); for (i = 0; i < MAXARGV; i++) ! SWAP(sep->se_argv[i], cp->se_argv[i]); sigsetmask(omask); ! freeconfig(cp); if (debug) print_service("REDO", sep); } else { ! sep = enter(cp); if (debug) print_service("ADD ", sep); } --- 624,680 ---- } for (sep = servtab; sep; sep = sep->se_next) sep->se_checked = 0; ! while ((new = getconfigent())) { ! if ((pwd = getpwnam(new->se_user)) == NULL) { syslog(LOG_ERR, "%s/%s: No such user '%s', service ignored", ! new->se_service, new->se_proto, new->se_user); continue; } for (sep = servtab; sep; sep = sep->se_next) ! if (strcmp(sep->se_service, new->se_service) == 0 && ! strcmp(sep->se_proto, new->se_proto) == 0) break; if (sep != 0) { int i; + #define SWAP(a, b) { typeof(a) c = a; a = b; b = c; } omask = sigblock(SIGBLOCK); ! /* copy over outstanding child pids */ ! if (sep->se_maxchild && new->se_maxchild) { ! new->se_numchild = sep->se_numchild; ! if (new->se_numchild > new->se_maxchild) ! new->se_numchild = new->se_maxchild; ! memcpy(new->se_pids, sep->se_pids, ! new->se_numchild * sizeof(*new->se_pids)); ! } ! SWAP(sep->se_pids, new->se_pids); ! sep->se_maxchild = new->se_maxchild; ! sep->se_numchild = new->se_numchild; ! /* might need to turn on or off service now */ ! if (sep->se_fd >= 0) { ! if (sep->se_maxchild ! && sep->se_numchild == sep->se_maxchild) { ! if (FD_ISSET(sep->se_fd, &allsock)) ! disable(sep); ! } else { ! if (!FD_ISSET(sep->se_fd, &allsock)) ! enable(sep); ! } ! } ! sep->se_accept = new->se_accept; ! if (new->se_user) ! SWAP(sep->se_user, new->se_user); ! if (new->se_server) ! SWAP(sep->se_server, new->se_server); for (i = 0; i < MAXARGV; i++) ! SWAP(sep->se_argv[i], new->se_argv[i]); sigsetmask(omask); ! freeconfig(new); if (debug) print_service("REDO", sep); } else { ! sep = enter(new); if (debug) print_service("ADD ", sep); } *************** *** 673,679 **** */ omask = sigblock(SIGBLOCK); sepp = &servtab; ! while (sep = *sepp) { if (sep->se_checked) { sepp = &sep->se_next; continue; --- 725,731 ---- */ omask = sigblock(SIGBLOCK); sepp = &servtab; ! while ((sep = *sepp)) { if (sep->se_checked) { sepp = &sep->se_next; continue; *************** *** 727,733 **** timingout = 0; for (sep = servtab; sep; sep = sep->se_next) ! if (sep->se_fd == -1) setup(sep); } --- 779,785 ---- timingout = 0; for (sep = servtab; sep; sep = sep->se_next) ! if (sep->se_fd == -1 && !ISMUX(sep)) setup(sep); } *************** *** 796,805 **** } if (sep->se_socktype == SOCK_STREAM) listen(sep->se_fd, 64); ! FD_SET(sep->se_fd, &allsock); ! nsock++; ! if (sep->se_fd > maxsock) ! maxsock = sep->se_fd; if (debug) { fprintf(stderr, "registered %s on %d\n", sep->se_server, sep->se_fd); --- 848,854 ---- } if (sep->se_socktype == SOCK_STREAM) listen(sep->se_fd, 64); ! enable(sep); if (debug) { fprintf(stderr, "registered %s on %d\n", sep->se_server, sep->se_fd); *************** *** 814,831 **** struct servtab *sep; { if (sep->se_fd >= 0) { ! nsock--; ! FD_CLR(sep->se_fd, &allsock); (void) close(sep->se_fd); sep->se_fd = -1; } sep->se_count = 0; /* ! * Don't keep the pid of this running deamon: when reapchild() * reaps this pid, it would erroneously increment nsock. */ ! if (sep->se_wait > 1) ! sep->se_wait = 1; } struct servtab * --- 863,879 ---- struct servtab *sep; { if (sep->se_fd >= 0) { ! if (FD_ISSET(sep->se_fd, &allsock)) ! disable(sep); (void) close(sep->se_fd); sep->se_fd = -1; } sep->se_count = 0; /* ! * Don't keep any running pids, otherwise when reapchild() * reaps this pid, it would erroneously increment nsock. */ ! sep->se_numchild = 0; } struct servtab * *************** *** 838,844 **** sep = (struct servtab *)malloc(sizeof (*sep)); if (sep == (struct servtab *)0) { syslog(LOG_ERR, "Out of memory."); ! exit(-1); } *sep = *cp; sep->se_fd = -1; --- 886,892 ---- sep = (struct servtab *)malloc(sizeof (*sep)); if (sep == (struct servtab *)0) { syslog(LOG_ERR, "Out of memory."); ! exit(EX_OSERR); } *sep = *cp; sep->se_fd = -1; *************** *** 849,854 **** --- 897,962 ---- return (sep); } + void + enable(struct servtab *sep) + { + if (debug) + print_service("ENAB", sep); + #ifdef SANITY_CHECK + if (sep->se_fd < 0) { + syslog(LOG_ERR, + "%s: %s: bad fd", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (ISMUX(sep)) { + syslog(LOG_ERR, + "%s: %s: is mux", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (FD_ISSET(sep->se_fd, &allsock)) { + syslog(LOG_ERR, + "%s: %s: not off", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + #endif + FD_SET(sep->se_fd, &allsock); + nsock++; + if (sep->se_fd > maxsock) + maxsock = sep->se_fd; + } + + void + disable(struct servtab *sep) + { + if (debug) + print_service("DSAB", sep); + #ifdef SANITY_CHECK + if (sep->se_fd < 0) { + syslog(LOG_ERR, + "%s: %s: bad fd", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (ISMUX(sep)) { + syslog(LOG_ERR, + "%s: %s: is mux", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (!FD_ISSET(sep->se_fd, &allsock)) { + syslog(LOG_ERR, + "%s: %s: not on", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (nsock == 0) { + syslog(LOG_ERR, "%s: nsock=0", __FUNCTION__); + exit(EX_SOFTWARE); + } + #endif + FD_CLR(sep->se_fd, &allsock); + nsock--; + if (sep->se_fd == maxsock) + maxsock--; + } + FILE *fconfig = NULL; struct servtab serv; char line[LINE_MAX]; *************** *** 879,885 **** { struct servtab *sep = &serv; int argc; ! char *cp, *arg; char *versp; static char TCPMUX_TOKEN[] = "tcpmux/"; #define MUX_LEN (sizeof(TCPMUX_TOKEN)-1) --- 987,993 ---- { struct servtab *sep = &serv; int argc; ! char *cp, *arg, *s; char *versp; static char TCPMUX_TOKEN[] = "tcpmux/"; #define MUX_LEN (sizeof(TCPMUX_TOKEN)-1) *************** *** 959,972 **** } } arg = sskip(&cp); ! sep->se_wait = strcmp(arg, "wait") == 0; if (ISMUX(sep)) { /* ! * Silently enforce "nowait" for TCPMUX services since ! * they don't have an assigned port to listen on. */ ! sep->se_wait = 0; ! if (strcmp(sep->se_proto, "tcp")) { syslog(LOG_ERR, "%s: bad protocol for tcpmux service %s", --- 1067,1102 ---- } } arg = sskip(&cp); ! if (!strncmp(arg, "wait", 4)) ! sep->se_accept = 0; ! else if (!strncmp(arg, "nowait", 6)) ! sep->se_accept = 1; ! else { ! syslog(LOG_ERR, ! "%s: bad wait/nowait for service %s", ! CONFIG, sep->se_service); ! goto more; ! } ! sep->se_maxchild = -1; ! if ((s = strchr(arg, '/')) != NULL) { ! char *eptr; ! u_long val; ! ! val = strtoul(s + 1, &eptr, 10); ! if (eptr == s + 1 || *eptr || val > MAX_MAXCHLD) { ! syslog(LOG_ERR, ! "%s: bad max-child for service %s", ! CONFIG, sep->se_service); ! goto more; ! } ! sep->se_maxchild = val; ! } if (ISMUX(sep)) { /* ! * Silently enforce "wait" mode for TCPMUX services ! * since they don't have an assigned port to listen on. */ ! sep->se_accept = 1; if (strcmp(sep->se_proto, "tcp")) { syslog(LOG_ERR, "%s: bad protocol for tcpmux service %s", *************** *** 994,1007 **** sep->se_service); goto more; } sep->se_bi = bi; - sep->se_wait = bi->bi_wait; } else sep->se_bi = NULL; argc = 0; for (arg = skip(&cp); cp; arg = skip(&cp)) ! if (argc < MAXARGV) sep->se_argv[argc++] = newstr(arg); while (argc <= MAXARGV) sep->se_argv[argc++] = NULL; return (sep); --- 1124,1155 ---- sep->se_service); goto more; } + sep->se_accept = 1; /* force accept mode for built-ins */ sep->se_bi = bi; } else sep->se_bi = NULL; + if (sep->se_maxchild < 0) /* apply default max-children */ + if (sep->se_bi) + sep->se_maxchild = sep->se_bi->bi_maxchild; + else + sep->se_maxchild = sep->se_accept ? 0 : 1; + if (sep->se_maxchild) { + sep->se_pids = malloc(sep->se_maxchild * sizeof(*sep->se_pids)); + if (sep->se_pids == NULL) { + syslog(LOG_ERR, "Out of memory."); + exit(EX_OSERR); + } + } argc = 0; for (arg = skip(&cp); cp; arg = skip(&cp)) ! if (argc < MAXARGV) { sep->se_argv[argc++] = newstr(arg); + } else { + syslog(LOG_ERR, + "%s: too many arguments for service %s", + CONFIG, sep->se_service); + goto more; + } while (argc <= MAXARGV) sep->se_argv[argc++] = NULL; return (sep); *************** *** 1021,1026 **** --- 1169,1176 ---- free(cp->se_user); if (cp->se_server) free(cp->se_server); + if (cp->se_pids) + free(cp->se_pids); for (i = 0; i < MAXARGV; i++) if (cp->se_argv[i]) free(cp->se_argv[i]); *************** *** 1040,1046 **** cp = skip(cpp); if (cp == NULL) { syslog(LOG_ERR, "%s: syntax error", CONFIG); ! exit(-1); } return (cp); } --- 1190,1196 ---- cp = skip(cpp); if (cp == NULL) { syslog(LOG_ERR, "%s: syntax error", CONFIG); ! exit(EX_DATAERR); } return (cp); } *************** *** 1062,1068 **** c = getc(fconfig); (void) ungetc(c, fconfig); if (c == ' ' || c == '\t') ! if (cp = nextline(fconfig)) goto again; *cpp = (char *)0; return ((char *)0); --- 1212,1218 ---- c = getc(fconfig); (void) ungetc(c, fconfig); if (c == ' ' || c == '\t') ! if ((cp = nextline(fconfig))) goto again; *cpp = (char *)0; return ((char *)0); *************** *** 1100,1109 **** newstr(cp) char *cp; { ! if (cp = strdup(cp ? cp : "")) return (cp); syslog(LOG_ERR, "strdup: %m"); ! exit(-1); } #ifdef OLD_SETPROCTITLE --- 1250,1259 ---- newstr(cp) char *cp; { ! if ((cp = strdup(cp ? cp : ""))) return (cp); syslog(LOG_ERR, "strdup: %m"); ! exit(EX_OSERR); } #ifdef OLD_SETPROCTITLE *************** *** 1439,1456 **** char *action; struct servtab *sep; { ! if(sep->se_rpc) ! fprintf(stderr, ! "%s: %s proto=%s, wait=%d, user=%s builtin=%x server=%s\n", ! action, sep->se_service, sep->se_proto, ! sep->se_wait, sep->se_user, (int)sep->se_bi, ! sep->se_server); ! else ! fprintf(stderr, ! "%s: %s proto=%s, wait=%d, user=%s builtin=%x server=%s\n", ! action, sep->se_service, sep->se_proto, ! sep->se_wait, sep->se_user, (int)sep->se_bi, ! sep->se_server); } /* --- 1589,1599 ---- char *action; struct servtab *sep; { ! fprintf(stderr, ! "%s: %s proto=%s accept=%d max=%d user=%s builtin=%x server=%s\n", ! action, sep->se_service, sep->se_proto, ! sep->se_accept, sep->se_maxchild, sep->se_user, ! (int)sep->se_bi, sep->se_server); } /* --------------FF6D5DF3F54BC7E1CFBAE39-- From owner-freebsd-hackers Mon Nov 4 17:27:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA19237 for hackers-outgoing; Mon, 4 Nov 1996 17:27:50 -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 RAA19231 for ; Mon, 4 Nov 1996 17:27:47 -0800 (PST) Received: from parkplace.cet.co.jp by mail.crl.com with SMTP id AA19395 (5.65c/IDA-1.5 for ); Mon, 4 Nov 1996 18:28:54 -0700 Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id BAA00924; Tue, 5 Nov 1996 01:21:12 GMT Date: Tue, 5 Nov 1996 10:21:12 +0900 (JST) From: Michael Hancock To: Thomas David Rivers Cc: FreeBSD Hackers Subject: Re: More info on the daily panics... In-Reply-To: <199611040418.XAA01799@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 I think you're on the right track. Continue looking at the initialization code of the inode allocation code and also start looking at deallocation. /sys/ufs/ufs/ufs_inode.c:ufs_reclaim() and /sys/kern/vfs_subr.c:vclean(). It could also be a nasty race condition. Also, please provide some stats on your system including the size of RAM, Size of Disk, %Free Disk Space, %Free Inodes, the number of fictitious cylinders, etc. Regards, Mike Hancock btw, I am by no means an fs expert. I am interested in file systems though. On Sun, 3 Nov 1996, Thomas David Rivers wrote: > I've applied Bruce's fix; but it really was for a different problem. > > I got another panic today: > > ffs_valloc: dup alloc > > that's the one I usually get when doing the newfs on the install > (for 2.1.0 and 2.1.5) if I don't alter the newfs parms. Just to > be clear; this is a 2.1.5-Stable kernel with Bruce's ufs_vnops.c > fix. > > Here's the gdb -k traceback. This isn't a debugable kernel (I should > probably fix that), so there's not too much information: > > > Script started on Sun Nov 3 22:39:49 1996 > [ponds.water.net]$ gdb -k kernel.6 vmcore.6 > 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 0xf0193c7b in boot () > (kgdb) where > #0 0xf0193c7b in boot () > #1 0xf0112b83 in panic () > #2 0xf0175183 in ffs_valloc () > #3 0xf01813c6 in ufs_makeinode () > #4 0xf017ed85 in ufs_create () > #5 0xf012cb97 in vn_open () > #6 0xf012a3cf in open () > #7 0xf019bff6 in syscall () > #8 0xf01914bb 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) quit > [ponds.water.net]$ > Script done on Sun Nov 3 22:40:09 1996 > > As you can see from the ls -l on /var/crash - after I enabled > savedump; I get a crash almost every day (although I went for > almost a week and ran just fine): > > [ponds.water.net]$ pwd > /var/crash > [ponds.water.net]$ ls -l > total 131684 > -rw-r--r-- 1 root wheel 2 Nov 3 13:21 bounds > -rw-r--r-- 1 root wheel 956177 Oct 23 01:29 kernel.0 > -rw-r--r-- 1 root wheel 956177 Oct 24 03:07 kernel.1 > -rw-r--r-- 1 root wheel 965207 Oct 30 07:54 kernel.2 > -rw-r--r-- 1 root wheel 965207 Oct 31 03:20 kernel.3 > -rw-r--r-- 1 root wheel 965207 Nov 1 03:21 kernel.4 > -rw-r--r-- 1 root wheel 965207 Nov 2 03:24 kernel.5 > -rw-r--r-- 1 root wheel 965207 Nov 3 13:22 kernel.6 > -rw-rw-r-- 1 root wheel 5 Jul 16 22:37 minfree > -rw-r--r-- 1 root wheel 8650752 Oct 23 01:29 vmcore.0 > -rw-r--r-- 1 root wheel 8650752 Oct 24 03:07 vmcore.1 > -rw-r--r-- 1 root wheel 8650752 Oct 30 07:54 vmcore.2 > -rw-r--r-- 1 root wheel 8650752 Oct 31 03:20 vmcore.3 > -rw-r--r-- 1 root wheel 8650752 Nov 1 03:21 vmcore.4 > -rw-r--r-- 1 root wheel 8650752 Nov 2 03:23 vmcore.5 > -rw-r--r-- 1 root wheel 8650752 Nov 3 13:22 vmcore.6 > > > (By the way, the panic on Nov 2nd - vmcore.5, was > panic: ifree: freeing free inode > the most frequent one I see...) > > You'll note from the times, these crashes tend to occur at > roughly the same time. I've been scanning the cron logs; the > only thing I see starting up about that time is the 03:15:00 > /usr/libexec/atrun and a 03:15:00 /usr/lib/newsbin/input/newsrun. > Both of these run every hour (well, atrun runs more often than that, > of course) - so I'm not yet sure exactly what command(s) is/are > causing the panic. > > Almost all the entries in the cron logs look like: > > Oct 23 01:15:01 ponds CRON[3494]: (news) CMD (/usr/lib/newsbin/input/newsrun) > Oct 23 01:20:00 ponds CRON[3610]: (root) CMD (/usr/libexec/atrun) > Oct 23 01:30:01 ponds cron[138]: (CRON) STARTUP (fork ok) > > although a few have something besides 'newsrun' starting up... it all > seems pretty harmless. > > Let me add that there are no 'at' entries in the queue, for anyone > on the system... > > Perhaps my next step is to build a debuggable kernel and start > debugging... > > Let me add that a duplicate alloc, and freeing already free'd inodes, > etc.... tend to point to a problem in the same area. Something > fishy the the inode management in ffs_alloc.c. > > Of course, a reliable reproduction of the problem would help toward > locating the fix... > > The 'freeing free inode' occurs if cg_inosused for the inode being > free'd is already clear. The 'dup alloc' panic occurs if the i_mode > of the inode which was returned from the allocator was already set > (indicating the inode was already allocated.) The allocator here > is ffs_nodealloccg() - which can return a wrong result if the cg_inosused > field is clear... > > isclr() (from /usr/include/sys/param.h) is: > > #define isclr(a,i) (((a)[(i)/NBBY] & (1<<((i)%NBBY))) == 0) > > [NBBY is '8' from types.h.] This seems completely reasonable for > accessing a bit from a character array... > > The cg_inosused() macro to access the used inodes table would be > incorrect if CG_MAGIC wasn't set for some reason - then you would > wind up pointing to trash for the inode table... > > This is what makes me think that allocating more inodes/blocks > in a file system tickles this problem... > > Ideas on possible investigation avenues (i.e. hints on where to > look) would be appreciated :-) But, I'm starting to become > familiar with ffs_valloc.c & the cg structure :-) > > - Dave Rivers - From owner-freebsd-hackers Mon Nov 4 17:47:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA20189 for hackers-outgoing; Mon, 4 Nov 1996 17:47:57 -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 RAA20183 for ; Mon, 4 Nov 1996 17:47:53 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA20974 for hackers@freebsd.org; Tue, 5 Nov 1996 12:17:42 +1030 From: Michael Smith Message-Id: <199611050147.MAA20974@genesis.atrad.adelaide.edu.au> Subject: fsck for embedded systems? To: hackers@freebsd.org Date: Tue, 5 Nov 1996 12:17:42 +1030 (CST) 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 I've been waiting to be bitten by for a while has finally come up; How do people out there building embedded BSD systems get around the fact that fsck won't take -p and -y simultaneously? ie. if you have an untidy shutdown, and the system comes up with a slightly unhappy disk, what's the best way of dealing with this? -- ]] 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 Mon Nov 4 17:50:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA20323 for hackers-outgoing; Mon, 4 Nov 1996 17:50:43 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA20315 for ; Mon, 4 Nov 1996 17:50:33 -0800 (PST) Received: from wong.rogerswave.ca by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vKaep-0008reC; Mon, 4 Nov 96 17:50 PST Received: (from wong@localhost) by wong.rogerswave.ca (8.7.5/8.7.3) id VAA00406; Mon, 4 Nov 1996 21:41:07 -0500 (EST) Date: Mon, 4 Nov 1996 21:41:07 -0500 (EST) From: Ken Wong Reply-To: wong@rogerswave.ca To: freebsd-hackers@FreeBSD.org Subject: Re: atapi errors In-Reply-To: <199611040304.WAA00778@netrover.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 config seems to work fine. I see the difference is cdrom rev. 3.05 as compare to 3.04 in yours. wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, dma, iordy wcd0: 1376Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray wcd0: medium type unknown, unlocked On Sun, 3 Nov 1996, Brian Campbell wrote: > With the 1014 snap and an 8x NEC IDE CD-ROM, I'm getting: > > wdc1 at 0x170-0x177 irq 15 flags 0x80ff on isa > wdc1: unit 0 (atapi): , removable, dma, iordy > wcd0: 1376Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray > wcd0: medium type unknown, unlocked > atapi1.0: invalid command phase, ireason=0xd0, status=d0, error=d0 > atapi1.0: invalid command phase, ireason=0xd8, status=d8, error=d8 > atapi1.0: controller not ready for cmd > atapi1.0: controller not ready for cmd > atapi1.0: controller not ready for cmd > atapi1.0: controller not ready for cmd > atapi1.0: controller not ready for cmd > atapi1.0: controller not ready for cmd > > Any ideas on what the problem is, or how to fix? > > From owner-freebsd-hackers Mon Nov 4 18:01:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA20945 for hackers-outgoing; Mon, 4 Nov 1996 18:01:34 -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 SAA20937 for ; Mon, 4 Nov 1996 18:01:32 -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 SAA05783; Mon, 4 Nov 1996 18:02:14 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id NAA29354; Tue, 5 Nov 1996 13:01:06 +1100 From: Julian Assange Message-Id: <199611050201.NAA29354@suburbia.net> Subject: Re: XFree86 3.2 now available. To: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Date: Tue, 5 Nov 1996 13:01:05 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <9611041457.AA05881@cabri.obs-besancon.fr> from "Jean-Marc Zucconi" at Nov 4, 96 03:57:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Please, don't forget to update ports/x11/XFree86 too > > I am working on it. BTW, is there some particular reason why there isn't a binary x11 port in ports? -- "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 4 18:16:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA21661 for hackers-outgoing; Mon, 4 Nov 1996 18:16:59 -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 SAA21653 for ; Mon, 4 Nov 1996 18:16:57 -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 SAA06037 for ; Mon, 4 Nov 1996 18:17:48 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id NAA30270 for hackers@freebsd.org; Tue, 5 Nov 1996 13:16:26 +1100 From: Julian Assange Message-Id: <199611050216.NAA30270@suburbia.net> Subject: Re: src/games/piano To: hackers@freebsd.org Date: Tue, 5 Nov 1996 13:16:26 +1100 (EST) In-Reply-To: <199611021459.PAA07864@vector.jhs.no_domain> from "Julian H. Stacey" at Nov 2, 96 03:59:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > P.S. My /usr/src/games/piano is 11KB, my /usr/ports/games/xroach is > > 29KB. It hurts when you use CVS because there would be 4KB CVS > > subdirectories for each directory (there are at least 3 if it's a > > port). I use "primes" for developing hash tables with some frequency. -- "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 4 18:51:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA22987 for hackers-outgoing; Mon, 4 Nov 1996 18:51:42 -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 SAA22982 for ; Mon, 4 Nov 1996 18:51:40 -0800 (PST) From: sthaug@nethelp.no Received: from verdi.nethelp.no by mail.crl.com with SMTP id AA05427 (5.65c/IDA-1.5 for ); Mon, 4 Nov 1996 19:52:38 -0700 Received: (qmail 2755 invoked by uid 1001); 5 Nov 1996 02:49:24 +0000 (GMT) To: mark@quickweb.com Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: /usr/obj size In-Reply-To: Your message of "Mon, 4 Nov 1996 18:42:20 -0500 (EST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 05 Nov 1996 03:49:24 +0100 Message-Id: <2753.847162164@verdi.nethelp.no> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On the topic of hard-disks, I obviously need a new one, so what do you all > recomend for a FAST-SCSI-2 drive. I just have an NCR c810 controller, so I > don't need the Ultra-Wide stuff. My local store is telling me that a 2GB > Quantum Atlas is about $900 CDN!!! And his price on a Seagate Hawk 2.1GB > is $700. Seems high to me, and I remember Terry and others debating the > equal cost of IDE and SCSI a while ago.. The exchange rate is about 0.76 > right now, so my local guy wants about $500 US for the Hawk. Like I said, > seems high.. You might want to check the IBM DORS-32160 2 GB if you can find them. They are less than two thirds of the price of the Atlas here in Norway. I have two of them, and are very happy with price and performance so far. At least here in Norway SCSI is definitely more expensive than IDE (about 30% more). I tend to stick with SCSI because I regard the technology as much better than IDE. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Mon Nov 4 21:13:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04244 for hackers-outgoing; Mon, 4 Nov 1996 21:13:55 -0800 (PST) Received: from netrover.com (ottawa23.netrover.com [205.209.19.32]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA04230 for ; Mon, 4 Nov 1996 21:13:48 -0800 (PST) Received: (from brianc@localhost) by netrover.com (8.7.6/8.7.3) id AAA00885; Tue, 5 Nov 1996 00:12:21 -0500 (EST) Message-Id: <199611050512.AAA00885@netrover.com> Date: Tue, 5 Nov 1996 00:12:20 -0500 From: brianc@netrover.com (Brian Campbell) To: freebsd-hackers@FreeBSD.org Subject: Re: atapi errors References: <199611040304.WAA00778@netrover.com> X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 Reply-to: freebsd-hackers@FreeBSD.org In-Reply-To: ; from Ken Wong on Nov 4, 1996 21:41:07 -0500 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Ken Wong writes: > My config seems to work fine. I see the difference is cdrom rev. 3.05 > as compare to 3.04 in yours. > > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (atapi): , removable, dma, iordy > wcd0: 1376Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray > wcd0: medium type unknown, unlocked > > > With the 1014 snap and an 8x NEC IDE CD-ROM, I'm getting: > > > > wdc1 at 0x170-0x177 irq 15 flags 0x80ff on isa > > wdc1: unit 0 (atapi): , removable, dma, iordy > > wcd0: 1376Kb/sec, 128Kb cache, audio play, 256 volume levels, ejectable tray > > wcd0: medium type unknown, unlocked > > atapi1.0: invalid command phase, ireason=0xd0, status=d0, error=d0 > > atapi1.0: invalid command phase, ireason=0xd8, status=d8, error=d8 > > atapi1.0: controller not ready for cmd > > atapi1.0: controller not ready for cmd Hmmm ... it'd be nice to blame it on the hardware, but I don't think I can this time. Booting the same machine into windows 95 or qnx enables the CD to be read without any problems. I was hoping someone would say "oh, that's been fixed in -current, grab atapi.c" or "oh, looks like it timed out too soon, adjust flarg to plib" From owner-freebsd-hackers Mon Nov 4 21:19:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04602 for hackers-outgoing; Mon, 4 Nov 1996 21:19:33 -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 VAA04541; Mon, 4 Nov 1996 21:18:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id PAA10694; Tue, 5 Nov 1996 15:56:31 +1100 Date: Tue, 5 Nov 1996 15:56:31 +1100 From: Bruce Evans Message-Id: <199611050456.PAA10694@godzilla.zeta.org.au> To: bde@zeta.org.au, smp@csn.net Subject: Re: ed0 timeouts Cc: dg@root.com, hackers@freefall.freebsd.org, smp@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I added these changes to the SMP kernel (#define APIC_LAZY in smptests.h, >should be commited later today) and it seems to fix the problem! > >However system IO seemed to get hosed when I entered ddb to check >the values of a few checkpoints I keep for debug. >I went in/out of ddb several times (I think) but then going out the system >"semi-hung": I could not get back to my virtual term, nor could I loggin >anywhere else. I could ping the system so at least part of it lived... > >Have you ever seen similar problems with this code on your system? ISTR remember that the non-masking of interrupts in ddb became critical when I implemented lazy masking. It was at least difficult to debug. >I would think a "properly" designed card would not be prone to noise. >I could make 2 versions of the INTR macro (edge & level), and plug the >appropriate one in as necessary in the XintXXX table. It would be good to generate more-specialized versions of the interrupt handlers, without generation more versions :-). (I spent a lot of time debugging a syscall performance bug that turned out to be that _Xsyscall was almost an exact multiple of PAGE_SIZE away from _syscall. This caused lots of cache collisions. The Pentium I-cache is only 2-way interleaved, so the next code access to another axact multiple of PAGE_SIZE away busts the cache. It was noticeably (40% slowdown) busted even on a 486DX/2. I fixed this by reordering the object files, but then the bloated interrupt code happened to push `doreti' to almost an exact multiple of PAGE_SIZE away from _Xsyscall :-].) Bruce This keeps interrupts disabled in debuggers. Its main disadvantage is that the clock no longer ever works while you're sitting at the debugger prompt. Previously the clock (and other interrupts) worked iff they happened not to be masked. TODO: The clock (and perhaps other devices) should be adjusted when the debugger gives up control. The debugger should not (except optionally) permit interrupts while single stepping. diff -c2 exception.s~ exception.s *** exception.s~ Mon Aug 12 09:36:45 1996 --- exception.s Mon Oct 28 20:55:30 1996 *************** *** 59,66 **** #define TRAP(a) pushl $(a) ; jmp _alltraps - /* - * XXX - debugger traps are now interrupt gates so at least bdb doesn't lose - * control. The sti's give the standard losing behaviour for ddb and kgdb. - */ #ifdef BDE_DEBUGGER #define BDBTRAP(name) \ --- 116,119 ---- *************** *** 79,84 **** #endif - #define BPTTRAP(a) testl $PSL_I,4+8(%esp) ; je 1f ; sti ; 1: ; TRAP(a) - MCOUNT_LABEL(user) MCOUNT_LABEL(btrap) --- 132,135 ---- *************** *** 88,97 **** IDTVEC(dbg) BDBTRAP(dbg) ! pushl $0; BPTTRAP(T_TRCTRAP) IDTVEC(nmi) pushl $0; TRAP(T_NMI) IDTVEC(bpt) BDBTRAP(bpt) ! pushl $0; BPTTRAP(T_BPTFLT) IDTVEC(ofl) pushl $0; TRAP(T_OFLOW) --- 139,148 ---- IDTVEC(dbg) BDBTRAP(dbg) ! pushl $0; TRAP(T_TRCTRAP) IDTVEC(nmi) pushl $0; TRAP(T_NMI) IDTVEC(bpt) BDBTRAP(bpt) ! pushl $0; TRAP(T_BPTFLT) IDTVEC(ofl) pushl $0; TRAP(T_OFLOW) diff -c2 machdep.c~ machdep.c *** machdep.c~ Thu Oct 31 22:03:44 1996 --- machdep.c Sat Nov 2 12:52:14 1996 *************** *** 1041,1047 **** setidt(x, &IDTVEC(rsvd), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(0, &IDTVEC(div), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); ! setidt(1, &IDTVEC(dbg), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(2, &IDTVEC(nmi), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); ! setidt(3, &IDTVEC(bpt), SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(4, &IDTVEC(ofl), SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(5, &IDTVEC(bnd), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); --- 1063,1069 ---- setidt(x, &IDTVEC(rsvd), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(0, &IDTVEC(div), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); ! setidt(1, &IDTVEC(dbg), SDT_SYS386IGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(2, &IDTVEC(nmi), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); ! setidt(3, &IDTVEC(bpt), SDT_SYS386IGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(4, &IDTVEC(ofl), SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL)); setidt(5, &IDTVEC(bnd), SDT_SYS386TGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); From owner-freebsd-hackers Mon Nov 4 21:20:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04715 for hackers-outgoing; Mon, 4 Nov 1996 21: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 VAA04687 for ; Mon, 4 Nov 1996 21:20:34 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA00799; Tue, 5 Nov 1996 00:20:02 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 5 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 XAA06217 for ; Mon, 4 Nov 1996 23:13:15 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id XAA00266 for freebsd-hackers@freefall.cdrom.com; Mon, 4 Nov 1996 23:14:10 -0500 (EST) Date: Mon, 4 Nov 1996 23:14:10 -0500 (EST) From: Thomas David Rivers Message-Id: <199611050414.XAA00266@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Another round of aha2940 (or perhaps generic SCSI) lock ups.. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok - I've done everything Adaptec tech. support said to do. I've ensure proper termination; dropped the transfer times, disabled synchronous & wide negotation on the older devices, disconnection negotiation, etc... What this has done has let me reproduce the SCSI lock-up more readily. 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 This just repeats until I reboot the machine. I let it continue for about 5 minutes. The only variation was the number of SCBs aborted. [Note, if I do a reset - the aha2940 is unable to probe the SCSI bus for devices. I have to turn the machine off and back on.] I note that "Vladimir P. Frolov" has just reported the same problem; with an Adaptec 7880. I did not experience my problems until *after* I upgraded my kernel to 2.1.5-STABLE. - Dave Rivers - From owner-freebsd-hackers Mon Nov 4 21:20:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04727 for hackers-outgoing; Mon, 4 Nov 1996 21:20:45 -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 VAA04704 for ; Mon, 4 Nov 1996 21:20:40 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA00848; Tue, 5 Nov 1996 00:20:08 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 5 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 XAA06881; Mon, 4 Nov 1996 23:42:26 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id XAA00348; Mon, 4 Nov 1996 23:43:22 -0500 (EST) Date: Mon, 4 Nov 1996 23:43:22 -0500 (EST) From: Thomas David Rivers Message-Id: <199611050443.XAA00348@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers, ponds!rivers Subject: More on aha2940 problems... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - after the last attempt to write a tape, I only got one SCSI reset set of messages - and things didn't loop... Here's what I got: sd1(ahc0:1:0): timed out in command phase, SCSISIGI == 0x84 sd1(ahc0:1:0): BUS DEVICE RESET message queued. sd1(ahc0:1:0): timed out in command phase, SCSISIGI == 0x84 ahc0: Issued Channel A Bus Reset #1. 3 SCBs aborted sd0(ahc0:0:0): UNIT ATTENTION info?:4020040 asc:29,0 sd0(ahc0:0:0): Power on, reset, or bus device reset occurred , retries:3 sd1(ahc0:1:0): ABORTED COMMAND asc:49,0 Invalid message error , retries:3 ahc0:A:1: refuses WIDE negotiation. Using 8bit transfers and, as you can tell from this mail - everything seems to have recovered.... - Dave Rivers - From owner-freebsd-hackers Mon Nov 4 21:33:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA05599 for hackers-outgoing; Mon, 4 Nov 1996 21:33:38 -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 VAA05592 for ; Mon, 4 Nov 1996 21:33:30 -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 GAA15754 for ; Tue, 5 Nov 1996 06:33:21 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id GAA30511 for FreeBSD-hackers@FreeBSD.org; Tue, 5 Nov 1996 06:32:50 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id BAA05293; Tue, 5 Nov 1996 01:11:44 +0100 (MET) Message-Id: <199611050011.BAA05293@keltia.freenix.fr> Date: Tue, 5 Nov 1996 01:11:44 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: FreeBSD-hackers@FreeBSD.org (FreeBSD-hackers) Subject: Re: frefall connectivity from europe References: <199611042157.WAA01638@gvr.win.tue.nl> X-Mailer: Mutt 0.49.07 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2632 In-Reply-To: <199611042157.WAA01638@gvr.win.tue.nl>; from Guido van Rooij on Nov 4, 1996 22:57:51 +0100 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Guido van Rooij: > It's really horrible lately...Is the cause known? Probably Sprint having router and routing table problems as usual I'd say. David is probably more up-to-date as he receive Sprint ticket I think. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #26: Sun Oct 27 19:39:11 MET 1996 From owner-freebsd-hackers Mon Nov 4 21:44:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06536 for hackers-outgoing; Mon, 4 Nov 1996 21:44:13 -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 VAA06529 for ; Mon, 4 Nov 1996 21:44:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id VAA28065; Mon, 4 Nov 1996 21:42:43 -0800 (PST) Message-Id: <199611050542.VAA28065@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: roberto@keltia.freenix.fr (Ollivier Robert) cc: FreeBSD-hackers@FreeBSD.org (FreeBSD-hackers) Subject: Re: frefall connectivity from europe In-reply-to: Your message of "Tue, 05 Nov 1996 01:11:44 +0100." <199611050011.BAA05293@keltia.freenix.fr> From: David Greenman Reply-To: dg@root.com Date: Mon, 04 Nov 1996 21:42:43 -0800 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >According to Guido van Rooij: >> It's really horrible lately...Is the cause known? > >Probably Sprint having router and routing table problems as usual I'd say. >David is probably more up-to-date as he receive Sprint ticket I think. In this case the problem is actually mostly due to problems with the Stratacom ATM switch at the PB-NAP "losing sync" with CRL's ATM interface. This coupled with another problem that started happening when the Cisco IOS was upgraded in one or more of CRL's routers has caused route instability and packet lossage. I'm told that this should be resolved later tonight with an IOS patch, and more permanently in the next few days. If all this weren't enough, we're having problems with the WC T1 being overloaded due to congestion, losing packets because of input CRC errors, and occasionally losing carrier on the CSU/DSU. I'm on it... -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Nov 4 21:46:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06707 for hackers-outgoing; Mon, 4 Nov 1996 21:46: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 VAA06698 for ; Mon, 4 Nov 1996 21:46:54 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id QAA22535 for freebsd-hackers@FreeBSD.org; Tue, 5 Nov 1996 16:16:51 +1030 From: Michael Smith Message-Id: <199611050546.QAA22535@genesis.atrad.adelaide.edu.au> Subject: Re: atapi errors To: freebsd-hackers@FreeBSD.org Date: Tue, 5 Nov 1996 16:16:51 +1030 (CST) In-Reply-To: <199611050512.AAA00885@netrover.com> from "Brian Campbell" at Nov 5, 96 00:12:20 am 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 Brian Campbell stands accused of saying: > > Hmmm ... it'd be nice to blame it on the hardware, but I don't think I > can this time. Booting the same machine into windows 95 or qnx enables > the CD to be read without any problems. It's been pretty clearly established that the FBSD atapi driver isn't the hottest. Nobody much here takes ATAPI CDroms seriously, for what seem to us to be good reasons. If you do, or you can help motivate someone else, then consider it in your interest to do so. Note that NEC CDroms are notorious for being bad behavers, so it's quite possible that the different firmware revisions behave differently. > I was hoping someone would say "oh, that's been fixed in -current, grab > atapi.c" or "oh, looks like it timed out too soon, adjust flarg to plib" Well, it's possible that it has. Have you tried the latest SNAP boot floppy? Have you checked to see the differences (if any) between the atapi driver you're using and the most current? -- ]] 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 Mon Nov 4 22:04:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA07692 for hackers-outgoing; Mon, 4 Nov 1996 22:04:08 -0800 (PST) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA07684; Mon, 4 Nov 1996 22:04:03 -0800 (PST) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id WAA11365; Mon, 4 Nov 1996 22:04:04 -0800 (PST) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id WAA11992; Mon, 4 Nov 1996 22:03:50 -0800 (PST) Message-Id: <199611050603.WAA11992@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Mark Mayo cc: Terry Lambert , Warner Losh , jmb@freefall.freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: /usr/obj size In-reply-to: Your message of Mon, 04 Nov 96 18:42:20 -0500. Date: Mon, 04 Nov 1996 22:03:49 -0800 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >On the topic of hard-disks, I obviously need a new one, so what do you all >recomend for a FAST-SCSI-2 drive. I just have an NCR c810 controller, so I >don't need the Ultra-Wide stuff. My local store is telling me that a 2GB >Quantum Atlas is about $900 CDN!!! And his price on a Seagate Hawk 2.1GB >is $700. Seems high to me, and I remember Terry and others debating the >equal cost of IDE and SCSI a while ago.. The exchange rate is about 0.76 >right now, so my local guy wants about $500 US for the Hawk. Like I said, >seems high.. The IBM drives are very reasonable right now. Check out http://www.basoncomputer.com/ ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Mon Nov 4 22:33:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA08983 for hackers-outgoing; Mon, 4 Nov 1996 22:33:23 -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 WAA08955 for ; Mon, 4 Nov 1996 22:33:05 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id RAA16574; Tue, 5 Nov 1996 17:29:48 +1100 Date: Tue, 5 Nov 1996 17:29:48 +1100 From: Bruce Evans Message-Id: <199611050629.RAA16574@godzilla.zeta.org.au> To: hasty@rah.star-gate.com, mtaylor@cybernet.com Subject: RE: Geomview, Mbone and FreeBSD... Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Already done. I've submitted the patches to the Geometry Center. They >were developed with the help of one of their workers. >... >diff -c -r Geomview.orig/src/bin/geomview/x11/gvmain.c Geomview/src/bin/geomview >/x11/gvmain.c >*** Geomview.orig/src/bin/geomview/x11/gvmain.c Thu Nov 17 18:45:03 1994 >--- Geomview/src/bin/geomview/x11/gvmain.c Wed Jul 24 16:19:58 1996 >*************** >*** 10,18 **** > #ifdef __linux__ > #include > #endif >! #ifdef __osf__ > #include > #endif > > /* xgv main - global variables */ > /***************************************************************************** >/ >--- 10,21 ---- > #ifdef __linux__ > #include > #endif >! #if defined(__osf__) || defined(__FreeBSD__) > #include > #endif >+ #ifdef __FreeBSD__ >+ #include >+ #endif > > /* xgv main - global variables */ > /***************************************************************************** >/ >*************** >*** 40,46 **** > __setfpucw(_FPU_IEEE); > #endif > >! #ifdef __osf__ > signal(SIGFPE, SIG_IGN); /* Ignore e.g. divide-by-zero traps */ > #endif > >--- 43,53 ---- > __setfpucw(_FPU_IEEE); > #endif > >! #ifdef __FreeBSD__ >! fpsetmask(fpgetmask()&(~FP_X_DZ)); >! #endif >! >! #if defined(__osf__) || defined(__FreeBSD__) > signal(SIGFPE, SIG_IGN); /* Ignore e.g. divide-by-zero traps */ > #endif The fpsetmask() call should probably mask all floating point exceptions like the __setfpucw() call apparently does. The signal stuff would then be unnecessary. It is broken anyway. Masking SIGFPE is rarely correct and is never correct for FreeBSD on i386's since it causes the following behaviour: - if the signal is for integer division by zero, then the faulting division is restarted endlessly. - if the signal is for a floating point exception, then the result will usually be wrong and the stack will usually pile up. E.g., for 1/+0, where 1 is in %st(0) and +0 is in %st(1), the operands will be left on the stack and the result will be 1 (sort of) and +0 will remain as junk on the stack. >diff -c -r Geomview.orig/src/lib/oogl/refcomm/streampool.c Geomview/src/lib/oogl >/refcomm/streampool.c >*** Geomview.orig/src/lib/oogl/refcomm/streampool.c Sun Oct 16 19:11:55 1994 >--- Geomview/src/lib/oogl/refcomm/streampool.c Thu Jul 11 22:39:50 1996 >*************** >*** 218,227 **** >--- 218,235 ---- > p->otype = PO_ALL; > p->next = NULL; > p->mode = rw; >+ #ifndef __FreeBSD__ > p->seekable = (p->inf && tell(fileno(p->inf)) != -1 && >+ #else >+ p->seekable = (p->inf && ftell(p->inf) != -1 && >+ #endif ftell() is ANSI standard, while tell() is nonstandard, so the "__FreeBSD__" case should be the normal case. Bruce From owner-freebsd-hackers Mon Nov 4 22:34:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09077 for hackers-outgoing; Mon, 4 Nov 1996 22:34:41 -0800 (PST) Received: from light.pine.ncu.edu.tw (light.pine.ncu.edu.tw [140.115.210.83]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA09070 for ; Mon, 4 Nov 1996 22:34:36 -0800 (PST) Received: (from root@localhost) by light.pine.ncu.edu.tw (8.8.2/8.7.3) id VAA00569 for hackers@FreeBSD.ORG; Tue, 5 Nov 1996 21:35:10 +0800 (CST) Date: Tue, 5 Nov 1996 21:35:10 +0800 (CST) From: ¤p¤ò Message-Id: <199611051335.VAA00569@light.pine.ncu.edu.tw> To: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe From owner-freebsd-hackers Mon Nov 4 22:43:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09715 for hackers-outgoing; Mon, 4 Nov 1996 22:43:58 -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 WAA09710 for ; Mon, 4 Nov 1996 22:43:55 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id AAA10370 for ; Tue, 5 Nov 1996 00:43:54 -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 AAA02375 for ; Tue, 5 Nov 1996 00:43:53 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id AAA01076 for hackers@freebsd.org; Tue, 5 Nov 1996 00:43:52 -0600 (CST) From: Karl Denninger Message-Id: <199611050643.AAA01076@Jupiter.Mcs.Net> Subject: Funny behavior in NFS To: hackers@freebsd.org Date: Tue, 5 Nov 1996 00:43:52 -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, We're seeing some funny NFS behavior... Specifically, if a fileserver is reset or loses connectivity (ie: you get a warning about "unreachable") any process which has a binary on that disk is dead meat (vm errors). "soft" mounted disks can't be ^Cd out of a "df", for example (that should work) and don't time out and fail. I am beginning to wonder if the "soft" switch is backwards! Anyone have any ideas or thoughts? -- -- 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 4 22:45:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09819 for hackers-outgoing; Mon, 4 Nov 1996 22:45:20 -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 WAA09798; Mon, 4 Nov 1996 22:45:14 -0800 (PST) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id WAA06435; Mon, 4 Nov 1996 22:45:46 -0800 Date: Mon, 4 Nov 1996 22:45:45 -0800 (PST) From: Veggy Vinny To: "Michael L. VanLoon -- HeadCandy.com" cc: Mark Mayo , Terry Lambert , Warner Losh , jmb@freefall.freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: /usr/obj size In-Reply-To: <199611050603.WAA11992@MindBender.serv.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 the topic of hard disks, what are the minimum requirements to run a FreeBSD machine as a news server with a full news feed in terms of CPU, memory, HD Storage and does it have to be on several HD instead of multiple large capacity drives such as 9 gig drives? Vince GaiaNet Corporation - Unix Networking Operations - GUS Mailing Lists Admin From owner-freebsd-hackers Mon Nov 4 23:02:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA10483 for hackers-outgoing; Mon, 4 Nov 1996 23:02:41 -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 XAA10476 for ; Mon, 4 Nov 1996 23:02:38 -0800 (PST) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0vKfWP-000I9MC; Tue, 5 Nov 96 08:02 MET Received: by ernie.kts.org (Smail3.1.29.1 #5) id m0vKewu-00001bC; Tue, 5 Nov 96 07:25 MET Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: driver problem To: amir@comtrol.com (Amir Farah) Date: Tue, 5 Nov 1996 07:25:24 +0100 (MET) Cc: hackers@FreeBSD.org In-Reply-To: <199611042200.QAA15788@rocket.comtrol.com> from "Amir Farah" at Nov 4, 96 04:00:12 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 Amir Farah wrote: > 1) Does FreeBSD have CAPI support?? To my knowledge no manuacturer has done support for a FreeBSD CAPI. A CAPI (Common Application Programming Interface, an widely used i/f to ISDN equipment here in Europe) is in most cases supplied by the manufacturer of ISDN hardware and it is a special piece of software for a hardware/OS combination. > Has anyone written little CAPI > applications that I could use to test a driver?? What driver ? hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe (A)bort, (R)etry, (I)nstall BSD ? From owner-freebsd-hackers Mon Nov 4 23:36:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA12660 for hackers-outgoing; Mon, 4 Nov 1996 23:36:56 -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 XAA12643 for ; Mon, 4 Nov 1996 23:36:50 -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 IAA24368; Tue, 5 Nov 1996 08:37:49 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id IAA01990; Tue, 5 Nov 1996 08:47:08 +0100 From: Christoph Kukulies Message-Id: <199611050747.IAA01990@gilberto.physik.rwth-aachen.de> Subject: Re: COFF->BSD converter In-Reply-To: <199611050003.TAA00489@netrover.com> from Brian Campbell at "Nov 4, 96 07:03:17 pm" To: brianc@pobox.com Date: Tue, 5 Nov 1996 08:47:08 +0100 (MET) Cc: freebsd-hackers@FreeBSD.org Reply-To: Christoph Kukulies 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 > Is there an objdump for FreeBSD? Unless you compile e.g. binutils-2.7, I think no. I compiled it recently with nearly all formats compiled in. If you want the binary, let me know. > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Mon Nov 4 23:49:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA13519 for hackers-outgoing; Mon, 4 Nov 1996 23:49: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 XAA13508 for ; Mon, 4 Nov 1996 23:49:07 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.6/8.6.9) with ESMTP id XAA14745; Mon, 4 Nov 1996 23:48:59 -0800 (PST) To: Michael Smith cc: freebsd-hackers@FreeBSD.org Subject: Re: atapi errors In-reply-to: Your message of "Tue, 05 Nov 1996 16:16:51 +1030." <199611050546.QAA22535@genesis.atrad.adelaide.edu.au> Date: Mon, 04 Nov 1996 23:48:59 -0800 Message-ID: <14743.847180139@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > It's been pretty clearly established that the FBSD atapi driver isn't > the hottest. Nobody much here takes ATAPI CDroms seriously, for what > seem to us to be good reasons. If you do, or you can help motivate > someone else, then consider it in your interest to do so. Actually, even those of us who take it very seriously, as Walnut Creek CDROM does, are somewhat handicapped by still not really knowing what the heck to do about it. :-( I'm no kernel hacker, dipping into that area of the system only very occasionally, and yet WC has no one else on tap to deal with this. Soren and others have kindly volunteered to try and do *something* about it, but they're so overloaded already that this doesn't necessarily guarantee any forward progress. We need an ATAPI god to come along and pick this up more than anything else, and any failure to do so really doesn't have a lot to do with hardware elitism at all - these people are simply rare and we just haven't found one yet. This also hasn't been helped by the fact that a local company volunteered to provide hardware then faded away. I'm about to the point where I'm going to ask WC for about $2K to buy all the IDE CDROMS I can find, using the rest as a slush fund to buy some sort of perk that an ATAPI hacker would appreciate. Maybe a Thai bride? :-) Jordan From owner-freebsd-hackers Mon Nov 4 23:53:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA13955 for hackers-outgoing; Mon, 4 Nov 1996 23:53:02 -0800 (PST) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA13950; Mon, 4 Nov 1996 23:53:01 -0800 (PST) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id XAA13918; Mon, 4 Nov 1996 23:53:07 -0800 (PST) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id XAA15011; Mon, 4 Nov 1996 23:52:45 -0800 (PST) Message-Id: <199611050752.XAA15011@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Veggy Vinny cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: /usr/obj size In-reply-to: Your message of Mon, 04 Nov 96 22:45:45 -0800. Date: Mon, 04 Nov 1996 23:52:45 -0800 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On the topic of hard disks, what are the minimum requirements to >run a FreeBSD machine as a news server with a full news feed in terms of >CPU, memory, HD Storage and does it have to be on several HD instead of >multiple large capacity drives such as 9 gig drives? You'd serve yourself well to peruse http://www.freebsd.org/ and look for the newsgroup archives. Joe Greco, and others, have posted much invaluable information about running large news servers. My guess is that you'd want to start with the isp list, then maybe hackers and/or stable. Look specifically for posts from Joe Greco, as he has been the most vocal on this topic, lately. To get you started, he recommends many smaller drives, probably 2GB each, striped with ccd, across multiple SCSI controllers, if possible. NCR/Symbios 53c8xx cards or Adaptec 2940/3940 cards would work best (until the BusLogic driver gets tagged-command-queuing, at which time it theoretically should be as good as the other two). ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Tue Nov 5 00:09:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA14947 for hackers-outgoing; Tue, 5 Nov 1996 00:09:27 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA14899; Tue, 5 Nov 1996 00:08:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id BAA09221; Tue, 5 Nov 1996 01:08:02 -0700 Message-Id: <199611050808.BAA09221@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Bruce Evans cc: dg@root.com, hackers@freefall.freebsd.org, smp@freefall.freebsd.org Subject: Re: ed0 timeouts In-reply-to: Your message of "Tue, 05 Nov 1996 15:56:31 +1100." <199611050456.PAA10694@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Nov 1996 01:08:02 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >>However system IO seemed to get hosed when I entered ddb to check >>the values of a few checkpoints I keep for debug. >>I went in/out of ddb several times (I think) but then going out the system >>"semi-hung": I could not get back to my virtual term, nor could I loggin >>anywhere else. I could ping the system so at least part of it lived... >> >>Have you ever seen similar problems with this code on your system? > >ISTR remember that the non-masking of interrupts in ddb became critical >when I implemented lazy masking. It was at least difficult to debug. I just had the same hang without entering ddb. I was running emacs via an X session on another system, with light load on the system. Looked like it might be something unique to the SMP kernel, appeared to be stuck in get_mplock(). Hopefully next time it happens I will be able to spend some time in the debugger to find more clues... In general it appears to be working well, I was up for 3-4 hours b4 this occured without a single lost INT (that I noticed, anyways!) -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Tue Nov 5 01:30:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21354 for hackers-outgoing; Tue, 5 Nov 1996 01:30:24 -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 BAA21334 for ; Tue, 5 Nov 1996 01:30:07 -0800 (PST) Received: from truk.brandinnovators.com (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 4383 on Tue, 5 Nov 1996 10:07:59 +0100; id KAA04383 efrom: hans@truk.brandinnovators.com; eto: freebsd-hackers@freebsd.org Received: by truk.brandinnovators.com (8.6.12/BI96070101) for id KAA27393; Tue, 5 Nov 1996 10:06:41 +0100 Message-Id: <199611050906.KAA27393@truk.brandinnovators.com> From: hans@brandinnovators.com (Hans Zuidam) Subject: SCSI floppy To: freebsd-hackers@freebsd.org Date: Tue, 5 Nov 1996 10:06:40 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, We're putting together a VMEbus based system using a Pentium CPU board and a bunch of SCSI disks. Although the CPU board has an on-board SCSI controller and support for a (NEC based) floppy disk, we would really like to use SCSI based floppy disk. Does anyone know of a BIOS that can make a SCSI LUN look like drive `A:', i.e. allow you to boot of a SCSI floppy instead of the normal FDC? Thanks in advance, 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 Tue Nov 5 01:42:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA22375 for hackers-outgoing; Tue, 5 Nov 1996 01:42:16 -0800 (PST) Received: from mpool.st.simbirsk.su (root@mpool.st.simbirsk.su [193.124.96.129]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA22096 for ; Tue, 5 Nov 1996 01:39:26 -0800 (PST) Received: by mpool.st.simbirsk.su id AA26920 (5.65/IDA-simtel); Tue, 5 Nov 1996 12:30:09 +0300 From: Viacheslav Andreev Message-Id: <199611050930.AA26920@mpool.st.simbirsk.su> Subject: ip_fw.c - bug or feature ? To: freebsd-hackers@FreeBSD.ORG Date: Tue, 5 Nov 1996 12:30:08 +0300 (MVW) Organization: Systemotechnika Center, Dimitrovgrad X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! I am not shure, this is a bug or feature. While trying to disable tcp traffic for some port, f.e. ipfw add 1070 deny log tcp from any to 192.168.0.1 80 , there are false dropping of fragmented (i.e. 2-nd and next-s without tcp port info) packets of ftp traffic. IMHO, it is a result of matching fragments over firewall rules with tcp port specs : -----------/sys/netinet/ip_fw.c----------------------------- /* Check TCP flags and TCP/UDP ports only if packet is not fragment */ if (!(ip->ip_off & IP_OFFMASK)) { /* TCP, a little more checking */ if (prt == IP_FW_F_TCP && (f->fw_tcpf != f->fw_tcpnf) && (!tcpflg_match(tcp, f))) continue; if (!port_match(&f->fw_pts[0], f->fw_nsp, src_port, f->fw_flg & IP_FW_F_SRNG)) continue; if (!port_match(&f->fw_pts[f->fw_nsp], f->fw_ndp, dst_port, f->fw_flg & IP_FW_F_DRNG)) continue; } !!! fragmented packets matches here with rules with tcp port spec. got_match: f->fw_pcnt++; f->fw_bcnt+=ip->ip_len; f->timestamp = time.tv_sec; if (f->fw_flg & IP_FW_F_PRN) { IMHO, to sovle this porblem, source should look like this : /* Check TCP flags and TCP/UDP ports only if packet is not fragment */ if (!(ip->ip_off & IP_OFFMASK)) { /* TCP, a little more checking */ if (prt == IP_FW_F_TCP && (f->fw_tcpf != f->fw_tcpnf) && (!tcpflg_match(tcp, f))) continue; if (!port_match(&f->fw_pts[0], f->fw_nsp, src_port, f->fw_flg & IP_FW_F_SRNG)) continue; if (!port_match(&f->fw_pts[f->fw_nsp], f->fw_ndp, dst_port, f->fw_flg & IP_FW_F_DRNG)) continue; } else { /* fragment here */ if (f->fw_ndp > 0 || f->fw_nsp > 0) { continue; /* don't match fragment with "precize" rule */ } } -- Viacheslav Andreev Dimitrovgrad town, Middle Volga, Russia. From owner-freebsd-hackers Tue Nov 5 01:45:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA22581 for hackers-outgoing; Tue, 5 Nov 1996 01:45:52 -0800 (PST) Received: from mpool.st.simbirsk.su (root@mpool.st.simbirsk.su [193.124.96.129]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA22543 for ; Tue, 5 Nov 1996 01:44:34 -0800 (PST) Received: by mpool.st.simbirsk.su id AA27044 (5.65/IDA-simtel); Tue, 5 Nov 1996 12:39:25 +0300 From: Viacheslav Andreev Message-Id: <199611050939.AA27044@mpool.st.simbirsk.su> Subject: ip_fw.c - bug or feature ? (fwd) To: freebsd-hackers@FreeBSD.ORG Date: Tue, 5 Nov 1996 12:39:24 +0300 (MVW) Organization: Systemotechnika Center, Dimitrovgrad X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry :( I forgot to say, that i use fbsd 2.1.5 -- Viacheslav Andreev Dimitrovgrad town, Middle Volga, Russia. From owner-freebsd-hackers Tue Nov 5 02:14:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA23533 for hackers-outgoing; Tue, 5 Nov 1996 02:14:47 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA23528 for ; Tue, 5 Nov 1996 02:14:41 -0800 (PST) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id KAA03873; Tue, 5 Nov 1996 10:14:25 GMT Date: Tue, 5 Nov 1996 10:14:22 +0000 (GMT) From: Doug Rabson To: Karl Denninger cc: hackers@FreeBSD.org Subject: Re: Funny behavior in NFS In-Reply-To: <199611050643.AAA01076@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 On Tue, 5 Nov 1996, Karl Denninger wrote: > Hi folks, > > We're seeing some funny NFS behavior... > > Specifically, if a fileserver is reset or loses connectivity (ie: you get a > warning about "unreachable") any process which has a binary on that disk > is dead meat (vm errors). I have been working on improving the asynchronous i/o code in NFS and it is possible but not likely that my changes might affect this. I will probably commit these changes tomorrow. > > "soft" mounted disks can't be ^Cd out of a "df", for example (that should > work) and don't time out and fail. > > I am beginning to wonder if the "soft" switch is backwards! > > Anyone have any ideas or thoughts? Don't you need the "intr" flag to be able to ^C out of an operation? The "soft" flag gives up the operation after a number of retries but isn't necessarily interruptable -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-hackers Tue Nov 5 03:02:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25166 for hackers-outgoing; Tue, 5 Nov 1996 03:02:35 -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 DAA25149 for ; Tue, 5 Nov 1996 03:02:32 -0800 (PST) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0vKjGd-000I9QC; Tue, 5 Nov 96 12:02 MET Received: by ernie.kts.org (Smail3.1.29.1 #5) id m0vKj0m-00001lC; Tue, 5 Nov 96 11:45 MET Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: vx driver(s) - bad powerup behaviour To: nao@sbl.cl.nec.co.jp (Naoki Hamada) Date: Tue, 5 Nov 1996 11:45:40 +0100 (MET) Cc: freebsd-hackers@freebsd.org, guido@gvr.win.tue.nl In-Reply-To: <199611030507.OAA29066@sirius.sbl.cl.nec.co.jp> from "Naoki Hamada" at Nov 3, 96 02:07:20 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 Naoki Hamada wrote: > >The new vx driver supports 3C590 Etherlink III PCI, 3C595 Fast > >Etherlink PCI, 3C592 Etherlink III EISA and 3C597 Fast Etherlink > >EISA. Early support for 3C900 Etherlink XL PCI and 3C905 Fast > >Etherlink XL PCI is also incorporated. Hey, after Naoki kindly put this driver onto freefall i was able to fetch it and install and test it under 2.1.5R - and it works !!!!! Now it says on every cold- or warmboot "Warning! Defective early revision adapter!" but it works all the time. Is this now _really_ an early revision adapter ? (Just curious ...) Thanks a lot, hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe (A)bort, (R)etry, (I)nstall BSD ? From owner-freebsd-hackers Tue Nov 5 03:28:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA26308 for hackers-outgoing; Tue, 5 Nov 1996 03:28:39 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA26301 for ; Tue, 5 Nov 1996 03:28:16 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id MAA03396; Tue, 5 Nov 1996 12:27:40 +0100 (MET) From: Guido van Rooij Message-Id: <199611051127.MAA03396@gvr.win.tue.nl> Subject: Re: vx driver(s) - bad powerup behaviour In-Reply-To: from Hellmuth Michaelis at "Nov 5, 96 11:45:40 am" To: hm@kts.org Date: Tue, 5 Nov 1996 12:27:40 +0100 (MET) Cc: nao@sbl.cl.nec.co.jp, 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 Hellmuth Michaelis wrote: > Naoki Hamada wrote: > > > >The new vx driver supports 3C590 Etherlink III PCI, 3C595 Fast > > >Etherlink PCI, 3C592 Etherlink III EISA and 3C597 Fast Etherlink > > >EISA. Early support for 3C900 Etherlink XL PCI and 3C905 Fast > > >Etherlink XL PCI is also incorporated. > > Hey, after Naoki kindly put this driver onto freefall i was able to > fetch it and install and test it under 2.1.5R - and it works !!!!! > > Now it says on every cold- or warmboot "Warning! Defective early revision > adapter!" but it works all the time. > > Is this now _really_ an early revision adapter ? (Just curious ...) > Yes. Almost definately. This means you should still implement the stuf I sent you ;-() -Guido From owner-freebsd-hackers Tue Nov 5 03:53:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA27268 for hackers-outgoing; Tue, 5 Nov 1996 03:53:07 -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 DAA27263 for ; Tue, 5 Nov 1996 03:53:02 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id WAA03814; Tue, 5 Nov 1996 22:47:50 +1100 Date: Tue, 5 Nov 1996 22:47:50 +1100 From: Bruce Evans Message-Id: <199611051147.WAA03814@godzilla.zeta.org.au> To: karl@mcs.net, matt@lkg.dec.com Subject: Re: Blargh - BSDI disk labels Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> FreeBSD doesn't understand BSDI disk labels. Like at all. >> >> There's no fix for this, is there? > >Here's a patch I made for 2.1.0 so I could mount my BSD/OS labels. >It's ugly but it works... It depends on the BSD/OS label having a 'c' partition that starts at absolute offset 0 even when the BSD/OS slice doesn't start at offset 0, right? This is like the old FreeBSD 'd' partition. How are bad144 tables handled in BSD/OS? Karl's problem was that the BSD/OS bootstrap on the MBR is incompatible with a standard MBR. Bruce From owner-freebsd-hackers Tue Nov 5 04:08:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27916 for hackers-outgoing; Tue, 5 Nov 1996 04:08:04 -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 EAA27875; Tue, 5 Nov 1996 04:07:55 -0800 (PST) Message-Id: <199611051207.EAA27875@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA274375393; Tue, 5 Nov 1996 23:03:13 +1100 From: Darren Reed Subject: Re: ip_fw.c - bug or feature ? To: cliff@st.simbirsk.su (Viacheslav Andreev) Date: Tue, 5 Nov 1996 23:03:13 +1100 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-security@freebsd.org In-Reply-To: <199611050930.AA26920@mpool.st.simbirsk.su> from "Viacheslav Andreev" at Nov 5, 96 12:30:08 pm 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 Viacheslav Andreev, sie said: > > Hi! > > I am not shure, this is a bug or feature. > While trying to disable tcp traffic for some port, f.e. > > ipfw add 1070 deny log tcp from any to 192.168.0.1 80 > > , there are false dropping of fragmented (i.e. 2-nd and next-s without > tcp port info) packets of ftp traffic. IMHO, it is a result of > matching fragments over firewall rules with tcp port specs : bug. A rule with port fields or TCP flags to match should not match a fragment. Darren From owner-freebsd-hackers Tue Nov 5 04:09:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA28004 for hackers-outgoing; Tue, 5 Nov 1996 04:09:18 -0800 (PST) Received: from sergio.lenzi ([200.247.23.106]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA27997 for ; Tue, 5 Nov 1996 04:09:03 -0800 (PST) Received: (from lenzi@localhost) by sergio.lenzi (8.7.5/8.7.3) id KAA03683; Tue, 5 Nov 1996 10:09:50 GMT Date: Tue, 5 Nov 1996 10:09:49 +0000 () From: "Lenzi, Sergio" X-Sender: lenzi@sergio To: "Serge A. Babkin" cc: hackers@freebsd.org Subject: Re: COFF->BSD converter In-Reply-To: <199611041930.AAA12170@hq.icb.chel.su> 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, 5 Nov 1996, Serge A. Babkin wrote: > I wrote the COFF -> BSD object file converter. It needs more extensive > testing but it works for now. Now the compatibility library and > set of headers are needed to use it. I don't know how long would it > take from me to write them. So if anyone can suggest any help > it will be gladly accepted. The possible benefits from this project are: Congratulations, what such a good idea. I am working in interfacing dbms with www servers and your project will have a great application in mine. Sergio Lenzi. Unix consult. From owner-freebsd-hackers Tue Nov 5 04:39:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA29770 for hackers-outgoing; Tue, 5 Nov 1996 04:39:52 -0800 (PST) Received: from pegasus.com (pegasus.com [140.174.243.13]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA29761; Tue, 5 Nov 1996 04:39:49 -0800 (PST) Received: by pegasus.com (8.6.8/PEGASUS-2.2) id CAA15591; Tue, 5 Nov 1996 02:39:27 -1000 Date: Tue, 5 Nov 1996 02:39:27 -1000 From: richard@pegasus.com (Richard Foulk) Message-Id: <199611051239.CAA15591@pegasus.com> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: isp@freebsd.org, hackers@freebsd.org Subject: nettty? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone gotten nettty to work with FreeBSD? bast.livingston.com:/pub/le/contrib/nettty.c It's a tool for connecting to a Portmaster port via a pseudo tty. Richard From owner-freebsd-hackers Tue Nov 5 04:46:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA00295 for hackers-outgoing; Tue, 5 Nov 1996 04:46:59 -0800 (PST) Received: from doris.estnet.ee (doris.estnet.ee [193.40.248.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA00288 for ; Tue, 5 Nov 1996 04:46:45 -0800 (PST) Received: (from uucaf@localhost) by doris.estnet.ee (8.6.12/8.6.12) id OAA18176 for hackers@FreeBSD.org; Tue, 5 Nov 1996 14:45:59 +0200 >Received: by mail.caf.estnet.ee (UUPC/extended 1.12j/sm); Tue, 05 Nov 1996 14:45:16 +0200 Message-ID: <327f36dc.caf@mail.caf.estnet.ee> From: vladimir@caf.estnet.ee (Vladimir Loiterstein) To: hackers@FreeBSD.org Date: Tue, 5 Nov 1996 13:52:49 MSK-3MSD MIME-Version: 1.0 Content-transfer-encoding: 7BIT Subject: mount msdos partition problem Priority: normal X-mailer: Pegasus Mail v3.22 Content-Type: text/plain; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I have 1.2Gb WD E-IDE hard drive. There are two partition on it: MSDOS and FreeBSD. For mounting use command mount_msdos. When I mounted msdos partition to FreeBSD my unix filesystem damaged Sincerely, Vladimir Loiterstein ---------------------------------------------------------------- | | | | |/\/\/\/\/\/\/\/\/\/\/| Vladimir Loiterstein |\/\/\/\/\/\/\/| | | | | |----------------------------------------------------------------| | AS CAF | | JOT Robotics invest | |----------------------------------------------------------------| | Work Phone : +372+6560220 | | Home Phone : +371+2253524 | |----------------------------------------------------------------| | Internet: vladimir@caf.estnet.ee | ---------------------------------------------------------------- From owner-freebsd-hackers Tue Nov 5 05:29:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA02289 for hackers-outgoing; Tue, 5 Nov 1996 05:29:34 -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 FAA02284 for ; Tue, 5 Nov 1996 05:29:27 -0800 (PST) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 19364 on Tue, 5 Nov 1996 14:21:04 +0100; id OAA19364 efrom: marc@nietzsche.bowtie.nl; eto: hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by nietzsche.bowtie.nl (8.7.5/8.7.3) with ESMTP id OAA03669 for ; Tue, 5 Nov 1996 14:25:05 +0100 (MET) Message-Id: <199611051325.OAA03669@nietzsche.bowtie.nl> X-Mailer: exmh version 1.6.7 5/3/96 To: hackers@freebsd.org Subject: linking fbsd prog with sco lib? Date: Tue, 05 Nov 1996 14:25:04 +0100 From: Marc van Kempen Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm want to develop a database program with the sco version of Solid Server (http://www.solidtech.com). I'm trying to un'ar the supplied library, but have had little success so far, so ... Is there any point in trying this at all? I mean will the library, when I put it back together as a freebsd library, work when linked with my own application? And, how do I un'ar it? I tried the following: ar x solcli.a ar Tx solcli.a ar x solcli.a su0rbtr2.o None of these work and give me errors about not finding the object files in the archive. It can read the names of the archives however. All of this is on a 2.2-960801-SNAP system. Regards, Marc. ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ---------------------------------------------------- From owner-freebsd-hackers Tue Nov 5 05:56:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA03616 for hackers-outgoing; Tue, 5 Nov 1996 05:56:07 -0800 (PST) Received: from solar.tlk.com (root@solar.tlk.com [194.97.84.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA03587 for ; Tue, 5 Nov 1996 05:56:01 -0800 (PST) Received: by solar.tlk.com id ; Tue, 5 Nov 96 14:55 MET Message-Id: From: torstenb@solar.tlk.com (Torsten Blum) Subject: Re: driver problem In-Reply-To: from Hellmuth Michaelis at "Nov 5, 96 07:25:24 am" To: hm@kts.org Date: Tue, 5 Nov 1996 14:55:31 +0100 (MET) Cc: amir@comtrol.com, hackers@FreeBSD.org Reply-To: torstenb@tlk.com X-Mailer: ELM [version 2.4ME+ PL26 (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 wrote: > > 1) Does FreeBSD have CAPI support?? > > To my knowledge no manuacturer has done support for a FreeBSD CAPI. Not directly, but Bintec Communications (http://www.bintec.de/) sells a ISDN Router called "Brick" which support "remote capi". The CAPI runs on the router, but you can access it over TCP. They include a capi library (including sources !) to access the remote-capi. I started playing with that and "porting" the library to FreeBSD is easy. You just have to replace poll() with select() two times (I can send you patches if you want). I'll feed them back to bintec of course. The Bricks support Germany's 1TR6, Euro-ISDN (DSS1), Swissnet and US N-ISDN-1. -tb From owner-freebsd-hackers Tue Nov 5 06:48:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA05200 for hackers-outgoing; Tue, 5 Nov 1996 06:48:04 -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 GAA05141 for ; Tue, 5 Nov 1996 06:46:56 -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 PAA02224; Tue, 5 Nov 1996 15:41:00 +0100 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id PAA03712; Tue, 5 Nov 1996 15:50:19 +0100 From: Christoph Kukulies Message-Id: <199611051450.PAA03712@gilberto.physik.rwth-aachen.de> Subject: Re: linking fbsd prog with sco lib? In-Reply-To: <199611051325.OAA03669@nietzsche.bowtie.nl> from Marc van Kempen at "Nov 5, 96 02:25:04 pm" To: marc@bowtie.nl (Marc van Kempen) Date: Tue, 5 Nov 1996 15:50:18 +0100 (MET) Cc: hackers@freebsd.org Reply-To: Christoph Kukulies 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 > > Hi, > > I'm want to develop a database program with the sco version > of Solid Server (http://www.solidtech.com). > > I'm trying to un'ar the supplied library, but have had > little success so far, so ... > > Is there any point in trying this at all? I mean will > the library, when I put it back together as a freebsd > library, work when linked with my own application? When they are using streams sockets you're out of luck. > > And, how do I un'ar it? I tried the following: > > ar x solcli.a > ar Tx solcli.a > ar x solcli.a su0rbtr2.o You have to unar under SCO (ar xv solcli.a `ar t solcli.a`) (not sure about SCOs ar switches though). You may also try the binutils-2.7 ar. > > None of these work and give me errors about not finding the > object files in the archive. It can read the names of the archives > however. > > All of this is on a 2.2-960801-SNAP system. > > Regards, > Marc. > > ---------------------------------------------------- > Marc van Kempen BowTie Technology > Email: marc@bowtie.nl WWW & Databases > tel. +31 40 2 43 20 65 > fax. +31 40 2 44 21 86 http://www.bowtie.nl > ---------------------------------------------------- > > > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Tue Nov 5 08:01:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA07573 for hackers-outgoing; Tue, 5 Nov 1996 08:01:53 -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 IAA07562 for ; Tue, 5 Nov 1996 08:01:42 -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 KAA03522 for ; Tue, 5 Nov 1996 10:00:36 -0600 (CST) Received: by bio-5.bsd.uchicago.edu (5.0/SMI-SVR4) id AA07042; Tue, 5 Nov 1996 10:00:34 +0600 Date: Tue, 5 Nov 1996 10:00:34 +0600 Message-Id: <9611051600.AA07042@bio-5.bsd.uchicago.edu> To: hackers@freebsd.org Subject: wrong unit number when wiring down st0 From: Tim Pierce Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here's an interesting one. I tried wiring down my SCSI tape in my 2.1.5 kernel config as follows: controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr controller scbus0 at aha0 device st0 at scbus0 target 2 The DAT deck is properly set up as target 2 (or so says the little number window on the back of the box), and I'm pretty sure that this syntax worked in 2.0.5. However, when I booted my machine, the kernel assigned the tape drive to st1, not st0. Removing `at stbus0 target 2' and recompiling the kernel corrected the problem. Is this a bug in the SCSI sense code, or my own confusion about how wiring down SCSI devices works? From owner-freebsd-hackers Tue Nov 5 08:05:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA07715 for hackers-outgoing; Tue, 5 Nov 1996 08:05:58 -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 IAA07710 for ; Tue, 5 Nov 1996 08:05:55 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA02492; Tue, 5 Nov 1996 10:05:36 -0600 (CST) Received: from Venus.mcs.net (karl@Venus.mcs.com [192.160.127.92]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA04931; Tue, 5 Nov 1996 10:05:35 -0600 (CST) Received: (from karl@localhost) by Venus.mcs.net (8.8.2/8.8.2) id KAA05286; Tue, 5 Nov 1996 10:05:34 -0600 (CST) From: Karl Denninger Message-Id: <199611051605.KAA05286@Venus.mcs.net> Subject: Re: Funny behavior in NFS To: dfr@render.com (Doug Rabson) Date: Tue, 5 Nov 1996 10:05:33 -0600 (CST) Cc: karl@Mcs.Net, hackers@FreeBSD.org In-Reply-To: from "Doug Rabson" at Nov 5, 96 10:14:22 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > On Tue, 5 Nov 1996, Karl Denninger wrote: > > > Hi folks, > > > > We're seeing some funny NFS behavior... > > > > Specifically, if a fileserver is reset or loses connectivity (ie: you get a > > warning about "unreachable") any process which has a binary on that disk > > is dead meat (vm errors). > > I have been working on improving the asynchronous i/o code in NFS and it > is possible but not likely that my changes might affect this. I will > probably commit these changes tomorrow. OK.. > > "soft" mounted disks can't be ^Cd out of a "df", for example (that should > > work) and don't time out and fail. > > > > I am beginning to wonder if the "soft" switch is backwards! > > > > Anyone have any ideas or thoughts? > > Don't you need the "intr" flag to be able to ^C out of an operation? The > "soft" flag gives up the operation after a number of retries but isn't > necessarily interruptable Yes, but you can sit with a "soft" mount for hours and it never times out.. -- -- 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 Tue Nov 5 08:08:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA07897 for hackers-outgoing; Tue, 5 Nov 1996 08:08:40 -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 IAA07892 for ; Tue, 5 Nov 1996 08:08:37 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA02525; Tue, 5 Nov 1996 10:07:12 -0600 (CST) Received: from Venus.mcs.net (karl@Venus.mcs.com [192.160.127.92]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA05212; Tue, 5 Nov 1996 10:07:07 -0600 (CST) Received: (from karl@localhost) by Venus.mcs.net (8.8.2/8.8.2) id KAA05340; Tue, 5 Nov 1996 10:07:06 -0600 (CST) From: Karl Denninger Message-Id: <199611051607.KAA05340@Venus.mcs.net> Subject: Re: Blargh - BSDI disk labels To: bde@zeta.org.au (Bruce Evans) Date: Tue, 5 Nov 1996 10:07:06 -0600 (CST) Cc: karl@Mcs.Net, matt@lkg.dec.com, hackers@FreeBSD.org In-Reply-To: <199611051147.WAA03814@godzilla.zeta.org.au> from "Bruce Evans" at Nov 5, 96 10:47:50 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > >> FreeBSD doesn't understand BSDI disk labels. Like at all. > >> > >> There's no fix for this, is there? > > > >Here's a patch I made for 2.1.0 so I could mount my BSD/OS labels. > >It's ugly but it works... > > It depends on the BSD/OS label having a 'c' partition that starts > at absolute offset 0 even when the BSD/OS slice doesn't start at > offset 0, right? This is like the old FreeBSD 'd' partition. How > are bad144 tables handled in BSD/OS? > > Karl's problem was that the BSD/OS bootstrap on the MBR is incompatible > with a standard MBR. > > Bruce Uh, I'm not trying to BOOT the disk, just MOUNT it. -- -- 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 Tue Nov 5 08:15:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA08112 for hackers-outgoing; Tue, 5 Nov 1996 08:15:12 -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 IAA08107 for ; Tue, 5 Nov 1996 08:15:07 -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 RAA23676 for ; Tue, 5 Nov 1996 17:13:37 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0vKo8v-00021LC; Tue, 5 Nov 96 17:14 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA157530400; Tue, 5 Nov 1996 17:13:20 +0100 From: "Hr.Ladavac" Message-Id: <199611051613.AA157530400@ws2301.gud.siemens.co.at> Subject: Re: [Fwd: usr.sbin.inetd] To: julian@whistle.com (Julian Elischer) Date: Tue, 5 Nov 1996 17:13:20 +0100 (MEZ) Cc: hackers@freebsd.org In-Reply-To: <327E8DDA.59E2B600@whistle.com> from "Julian Elischer" at Nov 4, 96 04:44:10 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 Julian Elischer contained: > Here is a compatible but useful addition to inetd. > I've wanted this for a long time.. > > one change... > in the man page it describes tha option as [something I forget] > but we decided that it should be better > described as: > > {wait|nowait}[/maxclients] > > does anyone see a reason this is bad? > > does anyone else thonk it's useful? This is probably the one most useful improvement for our cross-compile environment which presently does not allow enough rsh accesses. I was about to do the same and then replace the SINIX inetd with the BSD one. I'm now certain to do so :) /Marino From owner-freebsd-hackers Tue Nov 5 08:16:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA08195 for hackers-outgoing; Tue, 5 Nov 1996 08:16:49 -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 IAA08188 for ; Tue, 5 Nov 1996 08:16:44 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id DAA18563; Wed, 6 Nov 1996 03:13:29 +1100 Date: Wed, 6 Nov 1996 03:13:29 +1100 From: Bruce Evans Message-Id: <199611051613.DAA18563@godzilla.zeta.org.au> To: bde@zeta.org.au, karl@Mcs.Net Subject: Re: Blargh - BSDI disk labels Cc: hackers@FreeBSD.org, matt@lkg.dec.com Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Karl's problem was that the BSD/OS bootstrap on the MBR is incompatible >> with a standard MBR. > >Uh, I'm not trying to BOOT the disk, just MOUNT it. It has a BSD/OS bootstrap anyway, and the data in the bootstrap is incompatible with a normal MBR. Bruce From owner-freebsd-hackers Tue Nov 5 09:20:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA11380 for hackers-outgoing; Tue, 5 Nov 1996 09:20:46 -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 JAA11375 for ; Tue, 5 Nov 1996 09:20:40 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA14591; Tue, 5 Nov 1996 12:20:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 5 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 HAA17771; Tue, 5 Nov 1996 07:37:06 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id HAA01113; Tue, 5 Nov 1996 07:38:00 -0500 (EST) Date: Tue, 5 Nov 1996 07:38:00 -0500 (EST) From: Thomas David Rivers Message-Id: <199611051238.HAA01113@lakes.water.net> To: michaelh@cet.co.jp, ponds!ponds!rivers Subject: Re: More info on the daily panics... Cc: ponds!FreeBSD.ORG!Hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I think you're on the right track. > > Continue looking at the initialization code of the inode allocation > code and also start looking at deallocation. > /sys/ufs/ufs/ufs_inode.c:ufs_reclaim() and /sys/kern/vfs_subr.c:vclean(). > > It could also be a nasty race condition. Terry was thinking, I believe, that it's a problem in vfs_subr.c. His latest post was a discussion of that possibility. > > Also, please provide some stats on your system including the size of RAM, > Size of Disk, %Free Disk Space, %Free Inodes, the number of fictitious > cylinders, etc. I've provided that (in much detail) in a previous message.... including the output of disklable, newfs -n, etc... basically this is an 8-meg machine with a 1.2gig IDE (although I've also seen the problem on a SCSI machine, and J"org recently reported it on MFS.) > > Regards, > > > Mike Hancock - Thanks for the pointers! - - Dave Rivers - From owner-freebsd-hackers Tue Nov 5 09:34:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA11851 for hackers-outgoing; Tue, 5 Nov 1996 09:34: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 JAA11809; Tue, 5 Nov 1996 09:34:09 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA06955; Tue, 5 Nov 1996 11:29:12 -0600 From: Joe Greco Message-Id: <199611051729.LAA06955@brasil.moneng.mei.com> Subject: Re: /usr/obj size To: richardc@CSUA.Berkeley.EDU (Veggy Vinny) Date: Tue, 5 Nov 1996 11:29:12 -0600 (CST) Cc: michaelv@MindBender.serv.net, mark@quickweb.com, terry@lambert.org, imp@village.org, jmb@freefall.freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org In-Reply-To: from "Veggy Vinny" at Nov 4, 96 10:45:45 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On the topic of hard disks, what are the minimum requirements to > run a FreeBSD machine as a news server with a full news feed in terms of > CPU, memory, HD Storage and does it have to be on several HD instead of > multiple large capacity drives such as 9 gig drives? Vince, IMHO it depends on what you are going to do with the machine. Are you going to have lots of readers? Lots of inbound and/or outbound feeds? (Remember that many sites these days feed via "innfeed", and this counts as multiple feeds)... It also depends on how long you want to retain news, how many groups are in your active file (how "full" the feed is), whether or not you want to support other things on the system, etc. If you are going to have one user reading news and have a single inbound feed, sorted, held for half a week, and nothing else, you might be able to do it on a fairly skimpy system. My idea of fairly skimpy would be 486DX/133, 64MB RAM (maybe 48MB), a fast disk for root/var/newslib, and a big disk for spool. You might be able to get away with less memory by using C-News. My standard cuff calculation formula for RAM is: 1MB * active readers + 2MB * number of feeds + 8MB for system + 2 * sizeof(history.pag) I consider this to be a minimum. News will make very good use of as much memory as you can give it. One of my clients considered it to be an excessive maximum and learned a very expensive lesson when their news service sucked. For a CPU, I have not found a significant need to go beyond a P133. 'newspump.sol.net' is a P133, and is a dedicated feeds machine. It ranks #25 in the Freenix ratings this month. A large client has 100-150 nnrp sessions reading news on their P133 boxes, with CPU to spare. This game isn't really about CPU, it is more about memory, caching, and I/O. Besides, CPU is cheap. Chipset is ultimately important. You WILL not be successful if you buy a cruddy motherboard/chipset. Buy Triton-II. I recommend the ASUS P/I-P55T2P4, or P/E-P55T2P4D (see http://www.asus.com.tw). I recommend buying hardware from Rod Grimes, I have never been disappointed by his services and support. . Do not compromise on your I/O system. News is extremely taxing on a machine's disks. Buy multiple SCSI busses. It is much better to buy three $70 ASUS SC-200 NCR-810 controllers than one $220 AHA-2940 SCSI controller (but if you want to spend $660 on three AHA-2940's, that is not a bad solution either). Buy lots of disks. Stripe them with CCD. The reader machines noted above have 12 disks each: ---------------- ---------------- ---------------- | sd0 root | | sd10 var | | sd20 newslib | | 2G ST32550N | | 2G ST32550N | | CCD 1G 31055N| |--------------| |--------------| |--------------| | sd1 newslib | | sd11 nov | | sd21 nov | | CCD 1G 31055N| | CCD 1G 31055N| | CCD 1G 31055N| |--------------| |--------------| |--------------| | sd2 news | | sd12 news | | sd22 alt | | CCD 2G 32550N| | CCD 2G 32550N| | CCD 2G 32550N| |--------------| |--------------| |--------------| | sd3 alt | | sd13 binaries| | sd23 binaries| | CCD 2G 32550N| | CCD 4G 15150N| | CCD 4G 15150N| ---------------- ---------------- ---------------- Notice I stripe across controllers... also note the rants I have posted in the past on CCD stripe sizes. Use large ones except for the newslib disk. With 150 readers, this is DAMN BUSY... Rule #1) People always try to cheap out on news servers. Rule #2) They fail. Remember those rules and you have a chance of designing a good news service... ... JG From owner-freebsd-hackers Tue Nov 5 09:43:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA12343 for hackers-outgoing; Tue, 5 Nov 1996 09:43: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 JAA12338 for ; Tue, 5 Nov 1996 09:42:58 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA06573; Tue, 5 Nov 1996 10:33:22 -0700 From: Terry Lambert Message-Id: <199611051733.KAA06573@phaeton.artisoft.com> Subject: Re: XFree86 3.2 now available. To: proff@suburbia.net (Julian Assange) Date: Tue, 5 Nov 1996 10:33:22 -0700 (MST) Cc: jmz@cabri.obs-besancon.fr, hackers@freebsd.org In-Reply-To: <199611050201.NAA29354@suburbia.net> from "Julian Assange" at Nov 5, 96 01:01:05 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 > BTW, is there some particular reason why there isn't a binary x11 port > in ports? One with the misc fonts.dir fixed so the JDK will "just work"? 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 5 10:09:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA13984 for hackers-outgoing; Tue, 5 Nov 1996 10:09:02 -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 KAA13977; Tue, 5 Nov 1996 10:08:59 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA11771 ; Tue, 5 Nov 1996 10:08:58 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06616; Tue, 5 Nov 1996 11:00:11 -0700 From: Terry Lambert Message-Id: <199611051800.LAA06616@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: ponds!rivers@dg-rtp.dg.com (Thomas David Rivers) Date: Tue, 5 Nov 1996 11:00:11 -0700 (MST) Cc: terry@lambert.org, dyson@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: <199611050428.XAA00313@lakes.water.net> from "Thomas David Rivers" at Nov 4, 96 11:28: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 > > Time for a repost, it seems... > > > ... description delete ... > > Err, umm, ... doesn't that only fix the "free vnode isn't" > panic? That's really not what I'm seeing... I'm seeing > inode allocation panics coming from ffs_valloc.c. No. It fixes the freelist wrap error. > I'm seeing panics in ffs_vfree() that seem to be that the > inode is clear when it shouldn't be. vclean() will cause it to be marked clear if: 1) The overflow occurs by exactly *1*; this will cause the new inode to overwrite the old. 2) The vnode that is reallocated is freed by the original owner; this will cause the [new] inode to be cleared. 3) You attempt a second operation on the scond vnode reference to the same object. If the overflow occurs by 2 or more (alloc a/alloc b/alloc c/free b/free a) then you will get "free vnode isn't"... you will see this during a directory lookup operation for a create, especially in msdosfs. It tends to be hacked around on a per FS basis because the VOP_LOCK code is duplicated instead of shared, and everyone implements it slightly differently because the lock data area is off the inode instead of the vnode. Like I said in the patch, understand what the patch is working around and you will understand why it's needed. The patch to the create op in vfs_vnops.c that was made a bit ago only hacks around the problem. > I'm thinking the problem is either the inode allocation bit > (cg_inosused) is being cleared when it shouldn't be, or it > isn't being set when it shouldn't be... That would readily > explain the panic's I'm seeing... Consider instead what would happen if ffs reused a vnode when it was not truly free... it would rewrite the inode data pointer. But the original inode data pointer would point to the same object, but the inode that the vnode that the original inode pointed to could be free. So a reference by inode "works" (but gives the wrong vnode and buffers), but a reference by vnode fails. This also explains the occasional write warnings, and the occasional library corruption, FWIW. Cleaning an inode from the hash with an associated vnode would cause the data buffers from the second file to be applied to the first. I believe this is the source of a number of MSDOSFS "bugs"; MSDOSFS is more sensitive because an inode *is* a directory entry. The buffer swapping means that even a read-only mounted FS can get writes on overflow. You can verify this by ASSERT'ing that the inode reference in the vnode the inode points to points to the inode in question (this may fail on null-layer stacking, however, since the vnode data pointer points to another vnode). Part of "the true fix" must be to zone devices and pass writes through zone filtering... this is partially done anyway, but there are currently four or five logical device interfaces, and not all of them do it... only the disklabel devices really get it. Basically, there is a need for a common "logical device descriptor" which applies to all partitioning mechanisms. > Now, could the vfs_subr.c changes you suggest cause this > to happen? If the ffs_xxxx routines and data are properly > isolated - seems like that wouldn't be the case... But, > I'm not file-system guru. Yes, it can cause the error. Try the ASSERT. I've been loathe to discuss this in detail without patches in hand, since it's a serious reliability problem... unfortunately, patches require an orthogonal infrastructure (layering fixes to make everyone lock the same way so it can be worked around, then logical to physical device mapping by descriptor through a mapping layer for a real fix to simply disallow out-of-zone writes, then per fs allocation of the vnode as a subelement of the in core inode and a VOP_VRELE, etc.). 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 5 10:14:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA14270 for hackers-outgoing; Tue, 5 Nov 1996 10:14:53 -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 KAA14265 for ; Tue, 5 Nov 1996 10:14:50 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06636; Tue, 5 Nov 1996 11:06:16 -0700 From: Terry Lambert Message-Id: <199611051806.LAA06636@phaeton.artisoft.com> Subject: Re: atapi errors To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 5 Nov 1996 11:06:16 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.org In-Reply-To: <14743.847180139@time.cdrom.com> from "Jordan K. Hubbard" at Nov 4, 96 11:48:59 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 > We need an ATAPI god to come along and pick this up more than anything > else, and any failure to do so really doesn't have a lot to do with > hardware elitism at all - these people are simply rare and we just > haven't found one yet. These people are rare because of hardware elitism. *-). 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 5 10:21:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA14579 for hackers-outgoing; Tue, 5 Nov 1996 10:21: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 KAA14574 for ; Tue, 5 Nov 1996 10:21:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA06655; Tue, 5 Nov 1996 11:12:33 -0700 From: Terry Lambert Message-Id: <199611051812.LAA06655@phaeton.artisoft.com> Subject: Re: mount msdos partition problem To: vladimir@caf.estnet.ee (Vladimir Loiterstein) Date: Tue, 5 Nov 1996 11:12:33 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: <327f36dc.caf@mail.caf.estnet.ee> from "Vladimir Loiterstein" at Nov 5, 96 01:52:49 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 1.2Gb WD E-IDE hard drive. There are two partition on it: > MSDOS and FreeBSD. > For mounting use command mount_msdos. When I mounted msdos > partition to FreeBSD my unix filesystem damaged The msdosfs is damaged. Do not use the msdosfs, or mount only read-only. There is a cluster size problem when you use disks larger than 512 that aren't on a wide bus (ie: IDE > 512M). On very active machines, there are additional problems, and you should not use msdosfs on those machines at all. 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 5 11:54:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20299 for hackers-outgoing; Tue, 5 Nov 1996 11:54:11 -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 LAA20294 for ; Tue, 5 Nov 1996 11:54:09 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA05359; Tue, 5 Nov 1996 11:52:38 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma005355; Tue Nov 5 11:52:24 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id LAA04943; Tue, 5 Nov 1996 11:52:24 -0800 (PST) From: Archie Cobbs Message-Id: <199611051952.LAA04943@bubba.whistle.com> Subject: Re: fsck for embedded systems? In-Reply-To: <199611050147.MAA20974@genesis.atrad.adelaide.edu.au> from Michael Smith at "Nov 5, 96 12:17:42 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 5 Nov 1996 11:52:24 -0800 (PST) Cc: 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 > One I've been waiting to be bitten by for a while has finally come up; > > How do people out there building embedded BSD systems get around the > fact that fsck won't take -p and -y simultaneously? Leave out the -p ... it works fine just as "fsck -y". -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Nov 5 11:59:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20608 for hackers-outgoing; Tue, 5 Nov 1996 11:59:58 -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 LAA20602 for ; Tue, 5 Nov 1996 11:59:55 -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 UAA18411 for ; Tue, 5 Nov 1996 20:59:36 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id UAA22366 for hackers@FreeBSD.org; Tue, 5 Nov 1996 20:59:02 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id UAA00320; Tue, 5 Nov 1996 20:35:31 +0100 (MET) Message-Id: <199611051935.UAA00320@keltia.freenix.fr> Date: Tue, 5 Nov 1996 20:35:30 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: wrong unit number when wiring down st0 References: <9611051600.AA07042@bio-5.bsd.uchicago.edu> X-Mailer: Mutt 0.49.07 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2632 In-Reply-To: <9611051600.AA07042@bio-5.bsd.uchicago.edu>; from Tim Pierce on Nov 5, 1996 10:00:34 +0600 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Tim Pierce: > controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr > controller scbus0 at aha0 > device st0 at scbus0 target 2 Use ``tape'' instead of ``device'' is working for me: controller eisa0 controller bt0 controller ahb0 controller scbus0 at bt0 controller scbus1 at ahb0 # BT: ibm + tandberg + hp disk sd0 at scbus0 target 0 unit 0 disk sd1 at scbus0 target 1 disk sd2 at scbus0 target 2 disk sd3 at scbus0 target 3 tape st1 at scbus0 target 4 tape st0 at scbus0 target 5 device cd0 at scbus0 target 6 # 1742: conner + seagate + micropolis + CD disk sd10 at scbus1 target 0 disk sd11 at scbus1 target 1 disk sd12 at scbus1 target 2 disk sd13 at scbus1 target 3 device cd1 at scbus1 target 6 -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #26: Sun Oct 27 19:39:11 MET 1996 From owner-freebsd-hackers Tue Nov 5 13:01:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA24393 for hackers-outgoing; Tue, 5 Nov 1996 13:01:16 -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 NAA24388 for ; Tue, 5 Nov 1996 13:01:12 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA05769; Tue, 5 Nov 1996 13:00:40 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma005767; Tue Nov 5 13:00:29 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id NAA05158; Tue, 5 Nov 1996 13:00:29 -0800 (PST) From: Archie Cobbs Message-Id: <199611052100.NAA05158@bubba.whistle.com> Subject: mount panics & hangs To: freebsd-hackers@freebsd.org Date: Tue, 5 Nov 1996 13:00:29 -0800 (PST) Cc: julian@whistle.com (Julian Elischer) 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 Here is a way to crash a fairly -current system... I'd be interested to hear if this works for anyone else, and what the cause may be. The system eventually either goes into some sort of deadlock, or else panics: ervisor read, page not present instruction pointer = 0x8:0xf012ee00 stack pointer = 0x10:0xefbfff28 frame pointer = 0x10:0xefbfff30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 585 (mount) interrupt mask = kernel: type 12 trap, code=0 Stopped at _vfs_busy+0x8: testb $0x40,0x1a(%ebx) I've seen deadlocks wrt. mounting and unmounting before, but the panic is something new. The scenario is: I have two idential partitions each containing a FreeBSD-2.2 image.. one is the root partition, the other gets mounted under "/mnt". The /etc/fstab contains: /dev/wd0a / ufs ro 1 1 /dev/wd0e /mnt ufs rw,noauto 1 2 The /mnt partition has a short file in its root directory called "foo". Now create these two shell scripts: #!/bin/sh while /usr/bin/true; do mount /mnt cat /mnt/foo > /dev/null umount /mnt done and #!/bin/sh while /usr/bin/true; do mount done Then start them both running in the background.. after a few seconds I get either a deadlock or a panic. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Nov 5 13:21:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA25561 for hackers-outgoing; Tue, 5 Nov 1996 13:21:45 -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 NAA25553 for ; Tue, 5 Nov 1996 13:21:37 -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 WAA26119 for ; Tue, 5 Nov 1996 22:21:31 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA29032 for freebsd-hackers@freebsd.org; Tue, 5 Nov 1996 22:21:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id WAA26017 for freebsd-hackers@freebsd.org; Tue, 5 Nov 1996 22:16:30 +0100 (MET) From: J Wunsch Message-Id: <199611052116.WAA26017@uriah.heep.sax.de> Subject: Re: XFree86 3.2 now available. To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Tue, 5 Nov 1996 22:16:30 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611051733.KAA06573@phaeton.artisoft.com> from Terry Lambert at "Nov 5, 96 10:33:22 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 Terry Lambert wrote: > > BTW, is there some particular reason why there isn't a binary x11 port > > in ports? > > One with the misc fonts.dir fixed so the JDK will "just work"? There's no ``fonts.dir'' fix generally applicable. The fonts from the `misc' directory have been split among various packages for convenience. That's why you are _supposed_ to run a mkfontdir after installation, and that's what the postinstall.sh script of XFree86 3.2 does. (Only one out of 16 or so possible installation cases will end up with the correct fonts.dir otherwise.) Btw., for those who haven't seen it yet, the new ``XF86Setup'' utility looks really great! Give it a try... hint: you need the VGA16 server installed for it. But it's really worth the while. -- 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 Tue Nov 5 13:24:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA25707 for hackers-outgoing; Tue, 5 Nov 1996 13:24:18 -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 NAA25598 for ; Tue, 5 Nov 1996 13:22:14 -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 WAA26115; Tue, 5 Nov 1996 22:21:29 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA29030; Tue, 5 Nov 1996 22:21:29 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id WAA25992; Tue, 5 Nov 1996 22:13:19 +0100 (MET) From: J Wunsch Message-Id: <199611052113.WAA25992@uriah.heep.sax.de> Subject: Re: wrong unit number when wiring down st0 To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Tue, 5 Nov 1996 22:13:19 +0100 (MET) Cc: twpierce@midway.uchicago.edu (Tim Pierce) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9611051600.AA07042@bio-5.bsd.uchicago.edu> from Tim Pierce at "Nov 5, 96 10:00:34 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 Tim Pierce wrote: > The DAT deck is properly set up as target 2 (or so says the little > number window on the back of the box), and I'm pretty sure that > this syntax worked in 2.0.5. However, when I booted my machine, > the kernel assigned the tape drive to st1, not st0. Removing `at > stbus0 target 2' and recompiling the kernel corrected the > problem. Switches on the back are a primary source of mistrust. Why didn't you simply quote us the boot message for the tape? It should clearly identify on which target ID it has been found. -- 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 Tue Nov 5 14:34:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA00576 for hackers-outgoing; Tue, 5 Nov 1996 14:34: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 OAA00566 for ; Tue, 5 Nov 1996 14:34:33 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA06942; Tue, 5 Nov 1996 15:14:08 -0700 From: Terry Lambert Message-Id: <199611052214.PAA06942@phaeton.artisoft.com> Subject: Re: XFree86 3.2 now available. To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 5 Nov 1996 15:14:08 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199611052116.WAA26017@uriah.heep.sax.de> from "J Wunsch" at Nov 5, 96 10:16:30 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 with the misc fonts.dir fixed so the JDK will "just work"? > > There's no ``fonts.dir'' fix generally applicable. > > The fonts from the `misc' directory have been split among various > packages for convenience. That's why you are _supposed_ to run a > mkfontdir after installation, and that's what the postinstall.sh > script of XFree86 3.2 does. (Only one out of 16 or so possible > installation cases will end up with the correct fonts.dir otherwise.) How about running it in the postinstall script for each of the packages it might affect, then? Also: the default fonts.dir could be made to not include the optional items by default, so that it *will* work by default. The only catch to doing it this way is that you may add fonts in a packages, and if they have bogus post-installs that don't do mkfontdir, the new fonts won't be available. Better that optional components not be available without user action than "unrelated" software fails to operate without user interaction. Fail safe or don't fail. Either way, it's still bogus to not do the mkfontdir as part of the package postinstall... it can be done, it should be done. 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 5 16:22:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA05155 for hackers-outgoing; Tue, 5 Nov 1996 16:22:25 -0800 (PST) Received: from viking.ucsalf.ac.uk (viking.ucsalf.ac.uk [192.195.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA05150 for ; Tue, 5 Nov 1996 16:22:22 -0800 (PST) Received: by viking.ucsalf.ac.uk (Smail3.1.29.1 #4) id m0vKvl1-00037TC; Wed, 6 Nov 96 00:22 GMT Message-Id: From: sbolting@nemonet.com (Stephen Boltinghouse) Subject: cmsg cancel <624.051093963906@news.nemonet.com> To: freebsd-hackers@freebsd.org Date: Tue, 05 Nov 1996 22:56:54 +1 X-Gated-To-News-By: news@ucsalf.ac.uk X-Cancelled-By: hw@atlantic.FB12.TU-Berlin.DE X-No-Archive: Yes Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk MMF chain letter cancelled by hw@atlantic.fb12.tu-berlin.de . This is an ongoing spam with huge Breidbart indices. See my 2 reports "Boltinghouse" in news.admin.net-abuse.announce. Subject was: Just try this, it will work. From owner-freebsd-hackers Tue Nov 5 17:23:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA07291 for hackers-outgoing; Tue, 5 Nov 1996 17:23:45 -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 RAA07283 for ; Tue, 5 Nov 1996 17:23:40 -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 RAA01157; Tue, 5 Nov 1996 17:22:12 -0800 (PST) Message-ID: <327FE834.167EB0E7@whistle.com> Date: Tue, 05 Nov 1996 17:21:56 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs CC: freebsd-hackers@freebsd.org Subject: Davidg bug (was: mount panics & hangs) References: <199611052100.NAA05158@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Archie Cobbs wrote: > > Here is a way to crash a fairly -current system... I'd be interested > to hear if this works for anyone else, and what the cause may be. The > system eventually either goes into some sort of deadlock, or else panics: > an analysis of this problem yields.. A filesystem is being unmounted. The unmount sleeps for some reason in the function below (reason not known). this leaves teh mount point with teh MNT_BUSY flag set. int dounmount(mp, flags, p) register struct mount *mp; int flags; struct proc *p; { struct vnode *coveredvp; int error; coveredvp = mp->mnt_vnodecovered; if (vfs_busy(mp)) return (EBUSY); mp->mnt_flag |= MNT_UNMOUNT; error = vfs_lock(mp); if (error) return (error); <-------line "C" mp->mnt_flag &=~ MNT_ASYNC; vfs_msync(mp, MNT_NOWAIT); vnode_pager_umount(mp); /* release cached vnodes */ cache_purgevfs(mp); /* remove cache entries for this file sys */ if ((error = VFS_SYNC(mp, MNT_WAIT, p->p_ucred, p)) == 0 || (flags & MNT_FORCE)) error = VFS_UNMOUNT(mp, flags, p); mp->mnt_flag &= ~MNT_UNMOUNT; vfs_unbusy(mp); <----- line "D" if (error) { vfs_unlock(mp); } else { vrele(coveredvp); CIRCLEQ_REMOVE(&mountlist, mp, mnt_list); mp->mnt_vnodecovered->v_mountedhere = (struct mount *)0; vfs_unlock(mp); mp->mnt_vfc->vfc_refcount--; if (mp->mnt_vnodelist.lh_first != NULL) panic("unmount: dangling vnode"); free((caddr_t)mp, M_MOUNT); } return (error); } someone else does a 'mount' to see what is mounted. this does a getfsstat() in getfsstat(), it does the loop: for (mp = mountlist.cqh_first; mp != (void *)&mountlist; mp = nmp) { if (vfs_busy(mp)) { <----------line "B" nmp = mp->mnt_list.cqe_next; continue; } if (sfsp && count < maxcount && ((mp->mnt_flag & MNT_MLOCK) == 0)) { sp = &mp->mnt_stat; /* * If MNT_NOWAIT is specified, do not refresh the * fsstat cache. MNT_WAIT overrides MNT_NOWAIT. */ if (((uap->flags & MNT_NOWAIT) == 0 || (uap->flags & MNT_WAIT)) && (error = VFS_STATFS(mp, sp, p))) { nmp = mp->mnt_list.cqe_next; vfs_unbusy(mp); continue; } sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; error = copyout((caddr_t)sp, sfsp, sizeof(*sp)); if (error) { vfs_unbusy(mp); return (error); } sfsp += sizeof(*sp); } count++; nmp = mp->mnt_list.cqe_next; <------line "A" vfs_unbusy(mp); } .... in vfs_busy() we see. int vfs_busy(mp) register struct mount *mp; { while (mp->mnt_flag & MNT_MPBUSY) { mp->mnt_flag |= MNT_MPWANT; (void) tsleep((caddr_t) &mp->mnt_flag, PVFS, "vfsbsy", 0); } if (mp->mnt_flag & MNT_UNMOUNT) return (1); mp->mnt_flag |= MNT_MPBUSY; return (0); } unfortunatly, as the filesystem is busy the 'mount' sleeps in vfs_busy (in line "B") and is only woken up when dounmount() does a wakeup (via vfs_unbusy), (on line "D") but the other waiting process doesn't run immediatly, but only some time AFTER dounmount has done a 'free' on the mp, (and AFTER the MNT_UNMOUNT flag has been cleared). So in the 'mount' process, vfs_busy returns 0 at some later time, and the processing continues, now on a mountpoint that is no longer valid or even linked into the system. This seems to have been introduced by david in an attempt to fix a panic he was seeing on Freefall. Before that a straight "mount" woul dprobably not ahve been able to sleep and would possibly have been able to get past the mp being freed. At the next iteration of the loop, mp is undefined (often 0 in the case we see) and a page fault occurs. ( the next mp is derived on line "A") The only answer I can see is to either make the awakenned process start again from scratch, as the mp it has may no longer be valid, or to put some sort of lock on the whole mount list. BTW there is another small bug, which is.. the return at line "C" should also do a vfs_unbusy() suggestions? julian From owner-freebsd-hackers Tue Nov 5 18:42:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10186 for hackers-outgoing; Tue, 5 Nov 1996 18:42:51 -0800 (PST) Received: from intercore.com ([199.181.243.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10172 for ; Tue, 5 Nov 1996 18:42:20 -0800 (PST) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id VAA29276; Tue, 5 Nov 1996 21:35:31 -0500 (EST) Message-Id: <199611060235.VAA29276@intercore.com> Date: Tue, 5 Nov 1996 21:35:30 -0500 From: robin@intercore.com (Robin Cutshaw) To: jehamby@lightside.com (Jake Hamby) Cc: hackers@FreeBSD.ORG Subject: Re: XFree86 3.2 now available. In-Reply-To: ; from Jake Hamby on Nov 3, 1996 13:59:42 -0800 References: X-Mailer: Mutt 0.47 Mime-Version: 1.0 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jake Hamby writes: > XFree86 3.2 was just released a few days ago. I see that binaries for > FreeBSD 2.1.5 and FreeBSD-current are available from ftp.xfree86.org, as > well as source code. > I'd be interested in hearing any good/bad reports on the -current binary release. I built it on 2.2-960801-SNAP. robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-hackers Tue Nov 5 18:48:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10423 for hackers-outgoing; Tue, 5 Nov 1996 18:48:08 -0800 (PST) Received: from intercore.com ([199.181.243.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10383 for ; Tue, 5 Nov 1996 18:47:37 -0800 (PST) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id VAA29283; Tue, 5 Nov 1996 21:40:59 -0500 (EST) Message-Id: <199611060240.VAA29283@intercore.com> Date: Tue, 5 Nov 1996 21:40:58 -0500 From: robin@intercore.com (Robin Cutshaw) To: fenner@parc.xerox.com (Bill Fenner) Cc: danny@panda.hilink.com.au (Daniel O'Callaghan), gavin@ormond.unimelb.edu.au (Gavin Cameron), freebsd-hackers@FreeBSD.org Subject: Re: ZNYX346 and FreeBSD 2.1.5 and the latest SNAP (fwd) In-Reply-To: <96Nov3.225920pst.177557@crevenia.parc.xerox.com>; from Bill Fenner on Nov 3, 1996 22:59:13 -0800 References: <96Nov3.225920pst.177557@crevenia.parc.xerox.com> X-Mailer: Mutt 0.47 Mime-Version: 1.0 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Bill Fenner writes: > Daniel, Gavin, > > Look in sys/pci/if_de.c; there is some kludgery there to handle the > ZNYX 21040 multiport cards. It's worth trying to duplicate the 21040 > special-case code and seeing if it can handle the 21140 ZNYX; it looks > fairly straightforward. > I've got the cogent equivalent of this card (which is now from adaptec). This card get the same error reports. I've looked through the srom data that's there and I haven't quite figured out how to uniquely identify the card. The card doesn't seem to follow its 21040 equivalent in programming design. As anyone finds info on these cards, I'd appreciate an update so that support can be added... Thanks, robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-817-9787 "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-hackers Tue Nov 5 19:25:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA11563 for hackers-outgoing; Tue, 5 Nov 1996 19:25: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 TAA11556; Tue, 5 Nov 1996 19:25: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 TAA16075; Tue, 5 Nov 1996 19:25:37 -0800 (PST) To: jmb@freebsd.org cc: hackers@freebsd.org Subject: George Thackray: annoying pest. Date: Tue, 05 Nov 1996 19:25:36 -0800 Message-ID: <16073.847250736@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This user is spamming me by sending my own announcements back to me whenever I make them, but doesn't appear directly in any of freefall's mailing lists. Could those of you running exploders please have a look for: From: George Thackray And remove him from anything you find? I'm not even sure it's a person, it could be some stupid script run berserk. Every time I send an announcement however, I get ten copies of this guy's crap mailed back, and even more likely it's some clueless dweeb who thinks that spamming me will get him unsubscribed somehow, even though he *isn't* subscribed on any of freefall's mailing lists and there's no way I could remove him if I could (and remove him I would, believe me). I'd procmail him, but my last 4 attempts to go to procmail have always resulted in it working fine for about a week, then dumping core all over the place and bouncing all my email back. I know that others swear by procmail, but I've never gotten it to be reliable for me and I've tried every "canned" example in the book. Nothing fancy in my .procmailrc - it just starts catching sig 11's after awhile and becomes unusable. Thanks! Jordan From owner-freebsd-hackers Tue Nov 5 19:28:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA11748 for hackers-outgoing; Tue, 5 Nov 1996 19:28:21 -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 TAA11715 for ; Tue, 5 Nov 1996 19:27:42 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id OAA05852; Wed, 6 Nov 1996 14:26:10 +1100 (EST) Date: Wed, 6 Nov 1996 14:26:08 +1100 (EST) From: "Daniel O'Callaghan" To: Robin Cutshaw cc: Bill Fenner , Gavin Cameron , freebsd-hackers@freebsd.org Subject: Re: ZNYX346 and FreeBSD 2.1.5 and the latest SNAP (fwd) In-Reply-To: <199611060240.VAA29283@intercore.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 Tue, 5 Nov 1996, Robin Cutshaw wrote: > Bill Fenner writes: > > Look in sys/pci/if_de.c; there is some kludgery there to handle the > > ZNYX 21040 multiport cards. It's worth trying to duplicate the 21040 > > special-case code and seeing if it can handle the 21140 ZNYX; it looks > > fairly straightforward. > > I've got the cogent equivalent of this card (which is now from adaptec). > This card get the same error reports. I've looked through the srom data > that's there and I haven't quite figured out how to uniquely identify > the card. The card doesn't seem to follow its 21040 equivalent in > programming design. Matt is currently working on the 21140 cards (Znyx346), but the Znyx314 (10base-T only) definitely do work, reported by Joe Greco. Danny From owner-freebsd-hackers Tue Nov 5 20:42:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA15330 for hackers-outgoing; Tue, 5 Nov 1996 20:42:22 -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 UAA15325 for ; Tue, 5 Nov 1996 20:42:19 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id WAA11449 for ; Tue, 5 Nov 1996 22:42:08 -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 WAA00512 for ; Tue, 5 Nov 1996 22:42:07 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id WAA05013 for hackers@freebsd.org; Tue, 5 Nov 1996 22:42:06 -0600 (CST) From: Karl Denninger Message-Id: <199611060442.WAA05013@Jupiter.Mcs.Net> Subject: BSDI mount - - the patch posted to me works (somewhat) To: hackers@freebsd.org Date: Tue, 5 Nov 1996 22:42:06 -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, Just wanted to report that the hack/patch which Matt Thomas sent to me DOES work to allow BSDI disks to be mounted. Yes, its ugly, and I understand that it will only work for disks that are one big BSDI slice and partition (if I'm reading the code right) but that's all I need for my purposes. The kernel bitches during the mount about the magic number for the partition being wrong, but it fscks and mounts anyway, and once mounted doesn't blow up. At least not so far :-) Thanks. It isn't perfect, but it'll do what I need. Given this patch, I assume REAL support for this kind of thing wouldn't be hard to figure out and do. At the very least it doesn't look like committing the patch would hurt anything. Thoughts? -- -- 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 Tue Nov 5 20:52:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA15868 for hackers-outgoing; Tue, 5 Nov 1996 20:52:09 -0800 (PST) Received: from citrine.cyberstation.net (hannibal@citrine.cyberstation.net [205.167.0.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA15858 for ; Tue, 5 Nov 1996 20:52:04 -0800 (PST) Received: from localhost (hannibal@localhost) by citrine.cyberstation.net (8.8.2/8.8.2) with SMTP id WAA08969 for ; Tue, 5 Nov 1996 22:51:59 -0600 (CST) Date: Tue, 5 Nov 1996 22:51:58 -0600 (CST) From: Dan Walters Reply-To: Dan Walters To: hackers@freebsd.org Subject: Limiting bandwidth on a socket? (SO_RCVBUF?) 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'm trying to come up with some way to limit the amount of bandwidth on a socket, so I can have my mail and large files retrieve without slowing down a telnet session that much. I thought I could do this by setting SO_RCVBUF to a small value, but it doesn't seem to change the window size at all when I look at it with tcpdump. I saw something about patches to fix a broken SO_RCVBUF implementation in the mailing list archives, but can't seem to locate them / not sure if they made it in the kernel in the first place. If SO_RCVBUF would do what I want, I'd like a copy of them. :) I could swear I saw a "low-bandwidth ncftp" or something of the sort on sunsite.unc.edu a couple years ago, so I think this is possible (Well, at least in Linux...). It's apparently been deleted though. Anyone know how to do this? ====================================================================== Dan Walters hannibal@cyberstation.net ====================================================================== From owner-freebsd-hackers Tue Nov 5 21:26:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA18760 for hackers-outgoing; Tue, 5 Nov 1996 21:26:57 -0800 (PST) Received: from DNS.Lamb.net (root@DNS.Lamb.net [206.169.44.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA18753 for ; Tue, 5 Nov 1996 21:26:54 -0800 (PST) Received: from Gatekeeper.Lamb.net (ulf@Gatekeeper.Lamb.net [206.169.44.2]) by DNS.Lamb.net (8.8.2/8.7.3) with ESMTP id VAA29140; Tue, 5 Nov 1996 21:30:40 -0800 (PST) Received: (from ulf@localhost) by Gatekeeper.Lamb.net (8.8.2/8.7.6) id VAA24242; Tue, 5 Nov 1996 21:25:40 -0800 (PST) From: Ulf Zimmermann Message-Id: <199611060525.VAA24242@Gatekeeper.Lamb.net> Subject: Re: ZNYX346 and FreeBSD 2.1.5 and the latest SNAP (fwd) To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 5 Nov 1996 21:25:40 -0800 (PST) Cc: robin@intercore.com, fenner@parc.xerox.com, gavin@ormond.unimelb.edu.au, freebsd-hackers@FreeBSD.org In-Reply-To: from Daniel O'Callaghan at "Nov 6, 96 02:26:08 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 > > > On Tue, 5 Nov 1996, Robin Cutshaw wrote: > > > Bill Fenner writes: > > > Look in sys/pci/if_de.c; there is some kludgery there to handle the > > > ZNYX 21040 multiport cards. It's worth trying to duplicate the 21040 > > > special-case code and seeing if it can handle the 21140 ZNYX; it looks > > > fairly straightforward. > > > > I've got the cogent equivalent of this card (which is now from adaptec). > > This card get the same error reports. I've looked through the srom data > > that's there and I haven't quite figured out how to uniquely identify > > the card. The card doesn't seem to follow its 21040 equivalent in > > programming design. > > Matt is currently working on the 21140 cards (Znyx346), but the Znyx314 > (10base-T only) definitely do work, reported by Joe Greco. > > Danny > I use a 314 for more then 3 months now. Works super. Ulf. -------------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Lamb Art Internet Services | http://www.Lamb.net/ | http://www.Alameda.net From owner-freebsd-hackers Tue Nov 5 23:53:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA27502 for hackers-outgoing; Tue, 5 Nov 1996 23:53:28 -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 XAA27382 for ; Tue, 5 Nov 1996 23:52:47 -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 IAA14659 for ; Wed, 6 Nov 1996 08:51:40 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA06177 for freebsd-hackers@freebsd.org; Wed, 6 Nov 1996 08:51:40 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id IAA00573 for freebsd-hackers@freebsd.org; Wed, 6 Nov 1996 08:45:59 +0100 (MET) From: J Wunsch Message-Id: <199611060745.IAA00573@uriah.heep.sax.de> Subject: Re: XFree86 3.2 now available. To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 08:45:59 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611052214.PAA06942@phaeton.artisoft.com> from Terry Lambert at "Nov 5, 96 03:14:08 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 Terry Lambert wrote: > How about running it in the postinstall script for each of the > packages it might affect, then? Tell this to the maintainer of the port, it's the right thing to do. > Also: the default fonts.dir could be made to not include the optional > items by default, so that it *will* work by default. I'm no XFree86 release building expert, but i think the problem is that the fonts are `make install'ed first, but only split later on into several tarballs. Since the directory has been populated with all fonts before, you'd go through more hassles if you wanna reduce the fonts.dir. Running mkfontdir afterwards seems simpler. -- 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 Wed Nov 6 00:24:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA29586 for hackers-outgoing; Wed, 6 Nov 1996 00:24: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 AAA29531 for ; Wed, 6 Nov 1996 00:23:49 -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 JAA16137; Wed, 6 Nov 1996 09:21:35 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA06308; Wed, 6 Nov 1996 09:21:34 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id IAA00653; Wed, 6 Nov 1996 08:53:11 +0100 (MET) From: J Wunsch Message-Id: <199611060753.IAA00653@uriah.heep.sax.de> Subject: Re: XFree86 3.2 now available. To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 08:53:11 +0100 (MET) Cc: robin@intercore.com (Robin Cutshaw) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611060235.VAA29276@intercore.com> from Robin Cutshaw at "Nov 5, 96 09:35:30 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 Robin Cutshaw wrote: > I'd be interested in hearing any good/bad reports on the -current binary > release. I built it on 2.2-960801-SNAP. To the best of my knowledge, all the binaries are linked shared, right? Hence, the actual version of -current is quite unimportant, and this version also qualifies as `XFree86 for FreeBSD 2.2R'. I've put it as such onto my own prerelease CD yesterday, and installed it successfully on a machine (but with a plain stupid ol' ET4000 only). I'll also give this one away to a guinea pig who's going to test this CD (he's got some ATAPI CD, so i'm rather recommending him my 2.2 prerelease than 2.1.5). The XF86Setup is really great work! -- 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 Wed Nov 6 00:46:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA01809 for hackers-outgoing; Wed, 6 Nov 1996 00:46:15 -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 SMTP id AAA01798 for ; Wed, 6 Nov 1996 00:46:11 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id TAA06950; Wed, 6 Nov 1996 19:41:12 +1100 From: David Dawes Message-Id: <199611060841.TAA06950@rf900.physics.usyd.edu.au> Subject: Re: XFree86 3.2 now available. To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 6 Nov 1996 19:41:12 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199611060745.IAA00573@uriah.heep.sax.de> from "J Wunsch" at Nov 6, 96 08:45:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> How about running it in the postinstall script for each of the >> packages it might affect, then? > >Tell this to the maintainer of the port, it's the right thing to >do. Running mkfontdir after any font installation is the right thing to do. It is the only way to be sure that the fonts.dir is correct, and that it includes any other fonts that may have been present prior to the installation. >> Also: the default fonts.dir could be made to not include the optional >> items by default, so that it *will* work by default. > >I'm no XFree86 release building expert, but i think the problem is >that the fonts are `make install'ed first, but only split later on >into several tarballs. Since the directory has been populated with >all fonts before, you'd go through more hassles if you wanna reduce >the fonts.dir. Running mkfontdir afterwards seems simpler. That's right. If this proves to be too much of a problem, I would opt to not splitting the misc fonts at all. They are currently split into two pieces, and the only reason for this is to separate out the large fonts not required by people who only need support for European languages. David From owner-freebsd-hackers Wed Nov 6 01:23:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA04806 for hackers-outgoing; Wed, 6 Nov 1996 01: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 BAA04795 for ; Wed, 6 Nov 1996 01:22:56 -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 KAA18659 for ; Wed, 6 Nov 1996 10:21:34 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA06705 for freebsd-hackers@freebsd.org; Wed, 6 Nov 1996 10:21:34 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id JAA01532 for freebsd-hackers@freebsd.org; Wed, 6 Nov 1996 09:56:42 +0100 (MET) From: J Wunsch Message-Id: <199611060856.JAA01532@uriah.heep.sax.de> Subject: Re: XFree86 3.2 now available. To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 09:56:41 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611060841.TAA06950@rf900.physics.usyd.edu.au> from David Dawes at "Nov 6, 96 07:41:12 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 David Dawes wrote: > That's right. If this proves to be too much of a problem, I would opt > to not splitting the misc fonts at all. They are currently split into > two pieces, and the only reason for this is to separate out the large > fonts not required by people who only need support for European languages. I thought it's been the large Chinese fonts? I can't think of any European font that big... and even the Cyrillic fonts go into a different subdir. Anyway, i agree that running mkfontdir is the best fix. -- 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 Wed Nov 6 02:11:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA08282 for hackers-outgoing; Wed, 6 Nov 1996 02:11:26 -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 SMTP id CAA08274 for ; Wed, 6 Nov 1996 02:11:20 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id VAA07057; Wed, 6 Nov 1996 21:02:39 +1100 From: David Dawes Message-Id: <199611061002.VAA07057@rf900.physics.usyd.edu.au> Subject: Re: XFree86 3.2 now available. To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 6 Nov 1996 21:02:39 +1100 (EST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199611060856.JAA01532@uriah.heep.sax.de> from "J Wunsch" at Nov 6, 96 09:56:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> That's right. If this proves to be too much of a problem, I would opt >> to not splitting the misc fonts at all. They are currently split into >> two pieces, and the only reason for this is to separate out the large >> fonts not required by people who only need support for European languages. > >I thought it's been the large Chinese fonts? > >I can't think of any European font that big... and even the Cyrillic >fonts go into a different subdir. Yes, it is the fonts *not* required by European users. There are Japanese, Chinese, Korean and Hebrew fonts. The Cyrillic fonts are in a separate directory and separate package. David From owner-freebsd-hackers Wed Nov 6 02:53:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA10565 for hackers-outgoing; Wed, 6 Nov 1996 02:53:54 -0800 (PST) Received: from plum.cyber.com.au (plum.cyber.com.au [203.7.155.24]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA10542 for ; Wed, 6 Nov 1996 02:53:38 -0800 (PST) Received: (from darrenr@localhost) by plum.cyber.com.au (8.6.12/8.6.6) id VAA22086 for hackers@freebsd.org; Wed, 6 Nov 1996 21:53:20 +1100 From: Darren Reed Message-Id: <199611061053.VAA22086@plum.cyber.com.au> Subject: Gigabyte 586DX mb w/ 2940UW ob To: hackers@freebsd.org Date: Wed, 6 Nov 1996 21:53:19 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was wandering around town recently, when I came across a motherboard being sold that had SCSI built into it (the subject is the MB "type")! Does FreeBSD support this ? Darren From owner-freebsd-hackers Wed Nov 6 03:22:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA11592 for hackers-outgoing; Wed, 6 Nov 1996 03:22:15 -0800 (PST) Received: from bsd7.cs.sunysb.edu (bsd7.cs.sunysb.edu [130.245.1.197]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA11585 for ; Wed, 6 Nov 1996 03:22:13 -0800 (PST) Received: (from uucp@localhost) by bsd7.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id GAA13532; Wed, 6 Nov 1996 06:22:08 -0500 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.7.5/8.6.9) id GAA20346; Wed, 6 Nov 1996 06:21:34 -0500 (EST) Date: Wed, 6 Nov 1996 06:21:34 -0500 (EST) From: Gene Stark Message-Id: <199611061121.GAA20346@starkhome.cs.sunysb.edu> To: David Greenman Cc: hackers@freebsd.org, jkh@freefall.FreeBSD.org In-reply-to: David Greenman's message of Wed, 06 Nov 1996 00:20:41 -0800 Subject: SUP on sup.freebsd.org References: <55pm86$j7n@starkhome.cs.sunysb.edu> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: >point the service will be discontinued completely. So please switch to >using CVSup. It has much lighter network load and is quite a bit faster >as well. > Thanks, and sorry for the short notice, but the load problem had reached >critical and something had to be done immediately. I can well sympathize with the need to do something about your network load problems, but I just tried (unsuccessfully) to build CVSup and I have the following *major* complaints, which I hope you will consider: (1) CVSup, being written in Modula3, requires the importation of a *GIANT*, *BLOATED* language subsystem, which is not currently a standard part of FreeBSD (nor should it be). As it happens, I have a Modula3 already installed on some systems we are using for educational purposes. However, where I want to sup from is a server system that students don't use, and I'm not thrilled about copying vast quantities of shared libraries and other cruft yet to be determined over to that system so that I can run this one Modula3 program on the server. (2) CVSup will not compile (at least not out of the box from the ports/net/cvsup directory on FreeBSD 2.1.5, due to it apparently wanting some "-lz" option from ld, which doesn't seem to exist on the 2.1.5 ld. This effectively cuts off anyone running 2.1.5/stable from tracking the FreeBSD source tree and ports via sup. Given the above problems, it's no surprise that people have not flocked in droves to CVSup. - Gene Stark From owner-freebsd-hackers Wed Nov 6 04:20:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA14061 for hackers-outgoing; Wed, 6 Nov 1996 04:20:55 -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 EAA14048 for ; Wed, 6 Nov 1996 04:20:50 -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 EAA01109; Wed, 6 Nov 1996 04:20:40 -0800 (PST) To: Gene Stark cc: David Greenman , hackers@freebsd.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 06:21:34 EST." <199611061121.GAA20346@starkhome.cs.sunysb.edu> Date: Wed, 06 Nov 1996 04:20:40 -0800 Message-ID: <1107.847282840@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > (1) CVSup, being written in Modula3, requires the importation > of a *GIANT*, *BLOATED* language subsystem, which is not > currently a standard part of FreeBSD (nor should it be). Yarrgggh. Why does this keep coming up once a week, like clockwork? :-( Maybe we need to post a CVSup FAQ to -hackers once a week, just as preventive medicine. As has been stated oh-so-many-times before, the package versions in ftp://freefall.freebsd.org/pub/CVSup make it thoroughly unnecessary to build CVSup from the port, and in fact I've only done so once (just out of interest) since I started BETA testing the very earliest versions of CVSup. Install the binary distributions, be happy, don't even worry about the implementation language! > Given the above problems, it's no surprise that people have not flocked > in droves to CVSup. Actually, the binary dists make it phenominally easy to switch, and John has referred to them at least 4 or 5 times (*at least*) in very public postings. The bigger problem is simply that people aren't reading anymore. :-( Jordan From owner-freebsd-hackers Wed Nov 6 04:27:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA14569 for hackers-outgoing; Wed, 6 Nov 1996 04:27:49 -0800 (PST) Received: from relay4.smtp.psi.net (relay4.smtp.psi.net [38.9.52.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA14559 for ; Wed, 6 Nov 1996 04:27:45 -0800 (PST) Received: from tatung by relay4.smtp.psi.net (8.7.5/SMI-5.4-PSI) id HAA22746; Wed, 6 Nov 1996 07:27:42 -0500 (EST) Received: from netcbsd (h-admire.x31.infi.net) by tatung (5.x/SMI-SVR4) id AA05659; Wed, 6 Nov 1996 07:21:20 -0600 Message-Id: <328077F6.D47@netcon.com> Date: Wed, 06 Nov 1996 06:35:18 -0500 From: Tony Ardolino Organization: NetCon Corp. X-Mailer: Mozilla 2.0 (Win16; I) Mime-Version: 1.0 To: hackers@freebsd.org Subject: Loadable Kernel Modules Docs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! Could someone help me with Documentation or explanation on FreeBSD Loadable Kernel Modules. We have a VFS File system and a Protocol stack that we want to make loadable modules. We think we have added all the code thats required but we are just guessing. We have done the same loadable modules for SunOS, Solaris and AIX before, so just a litte help is all thats required. We like to try to avoid making this a lifetime occupation. Thank for all you help. Tony -- Tony Ardolino, President NetCon Corp. 605 North Lake Circle Crystal River, Florida 34429 Voice: 352/563-5300 Fax: 352/795-6783 http://www.netcon.com Email: tony@netcon.com From owner-freebsd-hackers Wed Nov 6 04:31:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA14825 for hackers-outgoing; Wed, 6 Nov 1996 04:31:02 -0800 (PST) Received: from bsd7.cs.sunysb.edu (bsd7.cs.sunysb.edu [130.245.1.197]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA14808 for ; Wed, 6 Nov 1996 04:30:55 -0800 (PST) Received: (from uucp@localhost) by bsd7.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id HAA13549; Wed, 6 Nov 1996 07:30:51 -0500 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.7.5/8.6.9) id HAA20646; Wed, 6 Nov 1996 07:30:14 -0500 (EST) Date: Wed, 6 Nov 1996 07:30:14 -0500 (EST) From: Gene Stark Message-Id: <199611061230.HAA20646@starkhome.cs.sunysb.edu> To: jkh@time.cdrom.com CC: root@implode.root.com, hackers@freebsd.org In-reply-to: <1107.847282840@time.cdrom.com> (jkh@time.cdrom.com) Subject: Re: SUP on sup.freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Actually, the binary dists make it phenominally easy to switch, and >John has referred to them at least 4 or 5 times (*at least*) in very >public postings. The bigger problem is simply that people aren't >reading anymore. :-( Dunno where exactly these postings were. The traffic on the hackers group is so great that unfortunately I don't often get the time to tackle it anymore. -Questions is even worse -- I had to stop reading that one a couple of years ago. Lately, I've been reading mostly -bugs, -security, and -announce, though I still get all the lists. - Gene Stark From owner-freebsd-hackers Wed Nov 6 04:45:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA15621 for hackers-outgoing; Wed, 6 Nov 1996 04:45:25 -0800 (PST) Received: from escape.cs.ibank.ru (igor@escape.cs.ibank.ru [194.58.131.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA15612; Wed, 6 Nov 1996 04:45:11 -0800 (PST) Received: (from igor@localhost) by escape.cs.ibank.ru (8.7.5/8.7.3/Zynaps) id PAA02502; Wed, 6 Nov 1996 15:44:20 +0300 (MSK) From: Igor Vinokurov Message-Id: <199611061244.PAA02502@escape.cs.ibank.ru> Subject: compile sendmail from /usr/src/usr.sbin/sendmail To: questions@freebsd.org, hackers@freebsd.org Date: Wed, 6 Nov 1996 15:44:19 +0300 (MSK) 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! Anybody can explain me why sendmail does not compile from source distribution (/usr/src/usr.sbin/sendmail) properly? I run make in this directory and have got some fatal errors then... :( P.S: In other words, I would like to upgrade sendmail at my 2.1.5R box. I was compiling sendmail myself before this day, but now I would like try to do it in the standard way. How did you compile sendmail to prepare release version? -- Igor Vinokurov From owner-freebsd-hackers Wed Nov 6 04:55:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA16153 for hackers-outgoing; Wed, 6 Nov 1996 04:55:59 -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 EAA16147 for ; Wed, 6 Nov 1996 04:55:55 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id XAA04215; Wed, 6 Nov 1996 23:25:32 +1030 From: Michael Smith Message-Id: <199611061255.XAA04215@genesis.atrad.adelaide.edu.au> Subject: Re: SUP on sup.freebsd.org To: gene@starkhome.cs.sunysb.edu (Gene Stark) Date: Wed, 6 Nov 1996 23:25:31 +1030 (CST) Cc: jkh@time.cdrom.com, root@implode.root.com, hackers@FreeBSD.org In-Reply-To: <199611061230.HAA20646@starkhome.cs.sunysb.edu> from "Gene Stark" at Nov 6, 96 07:30:14 am 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 Gene Stark stands accused of saying: > > Dunno where exactly these postings were. The traffic on the hackers > group is so great that unfortunately I don't often get the time to tackle > it anymore. -Questions is even worse -- I had to stop reading that one > a couple of years ago. Lately, I've been reading mostly -bugs, -security, > and -announce, though I still get all the lists. Announce and current (the latter is where I fauxed on the topic) at least. Now that JDP has put SOCKS support in, I have no excuse not to switch 8) > - Gene Stark > -- ]] 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 Wed Nov 6 05:50:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA19717 for hackers-outgoing; Wed, 6 Nov 1996 05:50: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 FAA19710 for ; Wed, 6 Nov 1996 05:50:36 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA16999; Wed, 6 Nov 1996 08:50:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 6 Nov 1996 08: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 HAA20268; Wed, 6 Nov 1996 07:59:34 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id IAA02838; Wed, 6 Nov 1996 08:00:35 -0500 (EST) Date: Wed, 6 Nov 1996 08:00:35 -0500 (EST) From: Thomas David Rivers Message-Id: <199611061300.IAA02838@lakes.water.net> To: terry@lambert.org, ponds!ponds!rivers Subject: Re: More info on the daily panics... Cc: ponds!freebsd.org!dyson, ponds!freebsd.org!freebsd-hackers, ponds!lambert.org!terry Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > Time for a repost, it seems... > > > > > ... description delete ... > > > > Err, umm, ... doesn't that only fix the "free vnode isn't" > > panic? That's really not what I'm seeing... I'm seeing > > inode allocation panics coming from ffs_valloc.c. > > No. It fixes the freelist wrap error. Ahh... I see... I was going to elide your description, but I'll leave it in case others missed it... Although this isn't the complete patch you discuss below, I believe it to be the proper fix for 2.1.5-STABLE.... I'm providing to a) Let others acquire it, b) Get this into 2.1.6, c) Ensure I understand the intent of your change. This patch doesn't use the nice macro, but it changes getnewvnode() to allocate a totally new node when we've wrapped around the end of the list... After Terry signs off on this, can someone get it committed to 2.1.6 (nee 2.1.5-STABLE)... - Thanks - - Dave Rivers - *** vfs_subr.c.ori Thu Aug 15 16:36:16 1996 --- vfs_subr.c Wed Nov 6 07:57:02 1996 *************** *** 339,345 **** */ if (freevnodes < (numvnodes >> 2) || numvnodes < desiredvnodes || ! vp == NULL) { vp = (struct vnode *) malloc((u_long) sizeof *vp, M_VNODE, M_WAITOK); bzero((char *) vp, sizeof *vp); --- 339,347 ---- */ if (freevnodes < (numvnodes >> 2) || numvnodes < desiredvnodes || ! vp == NULL || /* list empty */ ! vp->v_usecount) /* queue wrapped */ ! { vp = (struct vnode *) malloc((u_long) sizeof *vp, M_VNODE, M_WAITOK); bzero((char *) vp, sizeof *vp); *************** *** 347,355 **** } else { TAILQ_REMOVE(&vnode_free_list, vp, v_freelist); freevnodes--; - - if (vp->v_usecount) - panic("free vnode isn't"); /* see comment on why 0xdeadb is set at end of vgone (below) */ vp->v_freelist.tqe_prev = (struct vnode **) 0xdeadb; --- 349,354 ---- > > > I'm seeing panics in ffs_vfree() that seem to be that the > > inode is clear when it shouldn't be. > > vclean() will cause it to be marked clear if: > > 1) The overflow occurs by exactly *1*; this will cause the > new inode to overwrite the old. > 2) The vnode that is reallocated is freed by the original > owner; this will cause the [new] inode to be cleared. > 3) You attempt a second operation on the scond vnode > reference to the same object. > > If the overflow occurs by 2 or more (alloc a/alloc b/alloc c/free b/free a) > then you will get "free vnode isn't"... you will see this during a > directory lookup operation for a create, especially in msdosfs. > > It tends to be hacked around on a per FS basis because the VOP_LOCK > code is duplicated instead of shared, and everyone implements it > slightly differently because the lock data area is off the inode > instead of the vnode. > > Like I said in the patch, understand what the patch is working around > and you will understand why it's needed. The patch to the create > op in vfs_vnops.c that was made a bit ago only hacks around the problem. > > > I'm thinking the problem is either the inode allocation bit > > (cg_inosused) is being cleared when it shouldn't be, or it > > isn't being set when it shouldn't be... That would readily > > explain the panic's I'm seeing... > > Consider instead what would happen if ffs reused a vnode when it > was not truly free... it would rewrite the inode data pointer. But > the original inode data pointer would point to the same object, but > the inode that the vnode that the original inode pointed to could > be free. So a reference by inode "works" (but gives the wrong > vnode and buffers), but a reference by vnode fails. > > This also explains the occasional write warnings, and the occasional > library corruption, FWIW. Cleaning an inode from the hash with an > associated vnode would cause the data buffers from the second file > to be applied to the first. I believe this is the source of a number > of MSDOSFS "bugs"; MSDOSFS is more sensitive because an inode *is* > a directory entry. The buffer swapping means that even a read-only > mounted FS can get writes on overflow. > > You can verify this by ASSERT'ing that the inode reference in the > vnode the inode points to points to the inode in question (this > may fail on null-layer stacking, however, since the vnode data > pointer points to another vnode). > > Part of "the true fix" must be to zone devices and pass writes through > zone filtering... this is partially done anyway, but there are currently > four or five logical device interfaces, and not all of them do it... > only the disklabel devices really get it. Basically, there is a need > for a common "logical device descriptor" which applies to all partitioning > mechanisms. > > > > Now, could the vfs_subr.c changes you suggest cause this > > to happen? If the ffs_xxxx routines and data are properly > > isolated - seems like that wouldn't be the case... But, > > I'm not file-system guru. > > Yes, it can cause the error. Try the ASSERT. > > > I've been loathe to discuss this in detail without patches in hand, > since it's a serious reliability problem... unfortunately, patches > require an orthogonal infrastructure (layering fixes to make everyone > lock the same way so it can be worked around, then logical to physical > device mapping by descriptor through a mapping layer for a real fix > to simply disallow out-of-zone writes, then per fs allocation of the > vnode as a subelement of the in core inode and a VOP_VRELE, etc.). > > > Regards, > Terry Lambert > terry@lambert.org From owner-freebsd-hackers Wed Nov 6 06:13:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA21094 for hackers-outgoing; Wed, 6 Nov 1996 06:13:41 -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 GAA21057 for ; Wed, 6 Nov 1996 06:13:12 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA08311; Wed, 6 Nov 1996 08:11:58 -0600 From: Joe Greco Message-Id: <199611061411.IAA08311@brasil.moneng.mei.com> Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) To: hannibal@cyberstation.net Date: Wed, 6 Nov 1996 08:11:58 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: from "Dan Walters" at Nov 5, 96 10:51:58 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm trying to come up with some way to limit the amount of bandwidth on a > socket, so I can have my mail and large files retrieve without slowing > down a telnet session that much. > > I thought I could do this by setting SO_RCVBUF to a small value, but it > doesn't seem to change the window size at all when I look at it with > tcpdump. > > I saw something about patches to fix a broken SO_RCVBUF implementation in > the mailing list archives, but can't seem to locate them / not sure if > they made it in the kernel in the first place. If SO_RCVBUF would do what > I want, I'd like a copy of them. :) > > I could swear I saw a "low-bandwidth ncftp" or something of the sort on > sunsite.unc.edu a couple years ago, so I think this is possible (Well, at > least in Linux...). It's apparently been deleted though. > > Anyone know how to do this? int s, rval; s = socket(...); while ((rval = read(..., 1024)) > 0) { sleep(1); } if (rval < 0) { perror(...); } You can adjust the number of bytes read and the sleep() value to arange for many different potential amounts of bandwidth. I have successfully applied this concept numerous times before... and it applies to UDP as well as TCP (I have done this with tftp, once, when someone was trying to convince me that tftp "cannot be slowed down" (for a specific application where this was a requirement. 1K/sec is painful). The downside is that it generally requires C code modifications. I am not aware of any general way to do this without code modifications, without the introduction of specialized code such as ET's bandwidth manager (and I am by no means certain that BWMGR can handle this). I will note that some PPP/SLIP software allows prioritization of certain types of traffic, by way of "TOS" (type of service) queue reordering. This works moderately well when the MTU is small and the amount of data being buffered by the modem is very small. Cheap modems generally do not give you that level of control. ... JG From owner-freebsd-hackers Wed Nov 6 06:34:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA21954 for hackers-outgoing; Wed, 6 Nov 1996 06:34:07 -0800 (PST) Received: from gw.research.megasoft.com (gw.research.megasoft.com [206.230.35.93]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA21944 for ; Wed, 6 Nov 1996 06:33:59 -0800 (PST) Received: (from uucp@localhost) by gw.research.megasoft.com (8.7.5/8.7.3-cmcurtin) id JAA08157; Wed, 6 Nov 1996 09:33:43 -0500 (EST) Received: from goffette.research.megasoft.com(192.168.1.2) by gw.research.megasoft.com via smap (V1.3) id sma008153; Wed Nov 6 09:33:36 1996 Received: by goffette.research.megasoft.com (940816.SGI.8.6.9/940406.SGI) id JAA03226; Wed, 6 Nov 1996 09:26:49 -0500 Date: Wed, 6 Nov 1996 09:26:49 -0500 Message-Id: <199611061426.JAA03226@goffette.research.megasoft.com> From: C Matthew Curtin To: Nate Williams Cc: Amancio Hasty , hackers@FreeBSD.org Subject: Re: Early Alpha: Corel Office in Java (FreeBSD!) In-Reply-To: <199611011813.LAA08937@rocky.mt.sri.com> References: <199611011729.KAA08706@rocky.mt.sri.com> <199611011802.KAA19281@rah.star-gate.com> <199611011813.LAA08937@rocky.mt.sri.com> X-Face: "&>g(&eGr?u^F:nFihL%BsyS1[tCqG7}I2rGk4{aKJ5I_5A\*6RYn4"N.`1pPF9LO!Fa<(gj:12)?=uP2l01e10Gij"7j&-)torL^iBrNf\s7PDLm=rf[PjxtSbZ{J(@@j"q2/iV9^Mx>>>> "Nate" == Nate Williams writes: Nate> Looking at my modem lights and such, it appears that it's Nate> running client/server, so much of the slowness is due to having Nate> everything go back to the server. Yeah, as an applet it's horribly slow. Someone here at work saw the thing demo'd by Corel in person a few weeks back, and said he was surprised how fast it ran. I can't wait to see the thing for myself as an application. -- Matt Curtin cmcurtin@research.megasoft.com Megasoft, Inc Chief Scientist http://www.research.megasoft.com/people/cmcurtin/ I speak only for myself. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet From owner-freebsd-hackers Wed Nov 6 07:06:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA23720 for hackers-outgoing; Wed, 6 Nov 1996 07:06:27 -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 HAA23707 for ; Wed, 6 Nov 1996 07:06:23 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id KAA29940; Wed, 6 Nov 1996 10:05:51 -0500 Date: Wed, 6 Nov 1996 10:05:50 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@freebsd.org Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) In-Reply-To: <199611061411.IAA08311@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, 6 Nov 1996, Joe Greco wrote: > (Other sender of this lost) > > I'm trying to come up with some way to limit the amount of bandwidth on a > > socket, so I can have my mail and large files retrieve without slowing > > down a telnet session that much. > > int s, rval; > s = socket(...); > while ((rval = read(..., 1024)) > 0) { > sleep(1); ooch, ouch. my brain now hurts :-) Joe's method will work fine, but we may all agree we want a little more. Well, we're working on that here. So I would like to judge interest from this group. What we're looking at is putting ioctls in at the socket layer to implement rsvp-style reservations. I.e. you would use rsvp as now for reserving qualities related to flow of data, and our code would operate at the socket layer for enforcing those reservations. We want it to be at the socket layer so the user can have the controls work the same even though a socket may at the lower level be unix-domain, tcp, and so on. We've found that this sort of control is very important for distributed computing. Any comments welcome. This work is part of a much-larger project sponsored by DARPA for metacomputing (read distributed computing). ron From owner-freebsd-hackers Wed Nov 6 07:07:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA23835 for hackers-outgoing; Wed, 6 Nov 1996 07:07:31 -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 HAA23814 for ; Wed, 6 Nov 1996 07:07:27 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id JAA28613; Wed, 6 Nov 1996 09:04:49 -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 JAA06479; Wed, 6 Nov 1996 09:04:46 -0600 (CST) Received: (from karl@localhost) by Mercury.mcs.net (8.8.2/8.8.2) id JAA07519; Wed, 6 Nov 1996 09:04:45 -0600 (CST) From: Karl Denninger Message-Id: <199611061504.JAA07519@Mercury.mcs.net> Subject: Re: SUP on sup.freebsd.org To: gene@starkhome.cs.sunysb.edu (Gene Stark) Date: Wed, 6 Nov 1996 09:04:45 -0600 (CST) Cc: root@implode.root.com, hackers@FreeBSD.org, jkh@freefall.freebsd.org In-Reply-To: <199611061121.GAA20346@starkhome.cs.sunysb.edu> from "Gene Stark" at Nov 6, 96 06:21:34 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > David Greenman wrote: > > >point the service will be discontinued completely. So please switch to > >using CVSup. It has much lighter network load and is quite a bit faster > >as well. > > Thanks, and sorry for the short notice, but the load problem had reached > >critical and something had to be done immediately. > > I can well sympathize with the need to do something about your network > load problems, but I just tried (unsuccessfully) to build CVSup and I have > the following *major* complaints, which I hope you will consider: Uh, does this mean its down as of *NOW*? Blargh. Ok, where does one get a copy of CVSup that *doesn't* require that I build other things (ie: is pre-packaged, including the Modula 3 port required)? -- -- 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 6 07:10:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA24041 for hackers-outgoing; Wed, 6 Nov 1996 07:10:36 -0800 (PST) Received: from arf.cs.sunyit.edu (arf.cs.sunyit.edu [192.52.220.99]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA24033 for ; Wed, 6 Nov 1996 07:10:34 -0800 (PST) Received: (from chuck@localhost) by arf.cs.sunyit.edu (8.7.6/8.7.3) id KAA03918 for hackers@freebsd.org; Wed, 6 Nov 1996 10:10:32 -0500 (EST) Date: Wed, 6 Nov 1996 10:10:32 -0500 (EST) From: Charles Green Message-Id: <199611061510.KAA03918@arf.cs.sunyit.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freebsd.org Subject: Phillips CDD 521 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Phillips CDD 521 - Did anyone have any luck getting this beast to work? I can get one for around $500.00 and I was seriously thinking about it. -- Charles Green, PRC Inc. Rome Laboratory, NY From owner-freebsd-hackers Wed Nov 6 07:22:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA24890 for hackers-outgoing; Wed, 6 Nov 1996 07:22:26 -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 HAA24884 for ; Wed, 6 Nov 1996 07:22:21 -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 QAA07529; Wed, 6 Nov 1996 16:21:53 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA09374; Wed, 6 Nov 1996 16:21:53 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id QAA02467; Wed, 6 Nov 1996 16:20:10 +0100 (MET) From: J Wunsch Message-Id: <199611061520.QAA02467@uriah.heep.sax.de> Subject: Re: Loadable Kernel Modules Docs To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 16:20:10 +0100 (MET) Cc: tony@netcon.com (Tony Ardolino) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <328077F6.D47@netcon.com> from Tony Ardolino at "Nov 6, 96 06:35:18 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 Tony Ardolino wrote: > Could someone help me with Documentation or explanation on FreeBSD > Loadable Kernel Modules. /usr/share/examples/lkm/. I've just verified that they still build and work ok (in preparation of the 2.2 release testing). -- 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 Wed Nov 6 07:22:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA24938 for hackers-outgoing; Wed, 6 Nov 1996 07:22:46 -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 HAA24926 for ; Wed, 6 Nov 1996 07:22:41 -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 QAA07509 for ; Wed, 6 Nov 1996 16:21:35 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA09369 for freebsd-hackers@freebsd.org; Wed, 6 Nov 1996 16:21:34 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id QAA02399 for freebsd-hackers@freebsd.org; Wed, 6 Nov 1996 16:16:04 +0100 (MET) From: J Wunsch Message-Id: <199611061516.QAA02399@uriah.heep.sax.de> Subject: Re: XFree86 3.2 now available. To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 16:16:04 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611061002.VAA07057@rf900.physics.usyd.edu.au> from David Dawes at "Nov 6, 96 09:02:39 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 David Dawes wrote: > Yes, it is the fonts *not* required by European users. Ah, sorry, confusion on my side. -- 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 Wed Nov 6 07:51:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA26930 for hackers-outgoing; Wed, 6 Nov 1996 07:51:10 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA26923 for ; Wed, 6 Nov 1996 07:50:59 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id QAA21317; Wed, 6 Nov 1996 16:46:52 +0100 Received: by donau.informatik.uni-rostock.de id QAA06698; Wed, 6 Nov 1996 16:46:51 +0100 (MET) Date: Wed, 6 Nov 1996 16:46:51 +0100 (MET) From: Gunther Hipper Message-Id: <199611061546.QAA06698@donau.informatik.uni-rostock.de> To: hackers@freefall.freebsd.org Subject: Re: Gigabyte 586DX mb w/ 2940UW ob X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I was wandering around town recently, when I came across a motherboard > being sold that had SCSI built into it (the subject is the MB "type")! > Does FreeBSD support this ? Yes, it is supported by FreeBSD (great operating system - good work and thanks for all who created FreeBSD). I'm running FreeBSD on these Boards (FreeBSD SMP and 2 CPUs) - the 2940UW is recognized by FreeBSD. Could'nt use the driver because we only have EIDE drives - no SCSI devices at this time. Bye Gunther Gunther Hipper | University of Rostock | Department of Computer Science | Tel +49 381 498 3391 Albert-Einstein-Str. 21 | Fax +49 381 498 3440 18051 Rostock - Germany | Email Gunther.Hipper@informatik.uni-rostock.de From owner-freebsd-hackers Wed Nov 6 07:52:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA27064 for hackers-outgoing; Wed, 6 Nov 1996 07:52:17 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA26981 for ; Wed, 6 Nov 1996 07:51:42 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA08319; Wed, 6 Nov 1996 16:07:40 +0100 From: Luigi Rizzo Message-Id: <199611061507.QAA08319@labinfo.iet.unipi.it> Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Wed, 6 Nov 1996 16:07:40 +0100 (MET) Cc: hannibal@cyberstation.net, hackers@freebsd.org In-Reply-To: <199611061411.IAA08311@brasil.moneng.mei.com> from "Joe Greco" at Nov 6, 96 08:11:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I'm trying to come up with some way to limit the amount of bandwidth on a > > socket, so I can have my mail and large files retrieve without slowing > > down a telnet session that much. > > ... > > > > I could swear I saw a "low-bandwidth ncftp" or something of the sort on > > sunsite.unc.edu a couple years ago, so I think this is possible (Well, at > > least in Linux...). It's apparently been deleted though. Some ftp sites (e.g. funic.funet.fi) tell you the amount of bandwidth that has been allocated to your ftp connection. Try to look at what kind of ftp server they use. ... [code to insert sleep() between read/writes removed] > > You can adjust the number of bytes read and the sleep() value to arange for > many different potential amounts of bandwidth. ... > The downside is that it generally requires C code modifications. > > I am not aware of any general way to do this without code modifications, > without the introduction of specialized code such as ET's bandwidth > manager (and I am by no means certain that BWMGR can handle this). I think to remember this was discussed some time ago on the hackers list. Unfortunately I don't remember the outcome of the discussion. If you work inside the kernel (see the 'dummynet" stuff in my home page, it introduces bandwidth limitations on your link; with a little effort it can be configured to set different limitations on different TCP/UDP ports), you can avoid modifying program sources, which is extremely annoying. Otherwise, for servers which are launched by inetd, perhaps you can add a bandwidth-limiter process between your process and the socket and again avoid having to modify sources. Perhaps tcp_wrappers do this ? > I will note that some PPP/SLIP software allows prioritization of certain > types of traffic, by way of "TOS" (type of service) queue reordering. > This works moderately well when the MTU is small and the amount of data > being buffered by the modem is very small. Cheap modems generally do not > give you that level of control. I don't think the modem takes more than 128-256 bytes of data, so packet prioritization inside the PPP sw can serve the purpose. 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 Wed Nov 6 07:59:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA27425 for hackers-outgoing; Wed, 6 Nov 1996 07:59:48 -0800 (PST) Received: from ingenieria ([168.176.15.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA27403; Wed, 6 Nov 1996 07:59:28 -0800 (PST) Received: from unalslip.usc.unal.edu.co by ingenieria (SMI-8.6/SMI-SVR4) id KAA06744; Wed, 6 Nov 1996 10:58:16 +0600 Message-ID: <3280DF75.25B3@ingenieria.ingsala.unal.edu.co> Date: Wed, 06 Nov 1996 10:56:53 -0800 From: "Pedro Giffuni S." Reply-To: pgiffuni@fps.biblos.unal.edu.co Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Igor Vinokurov CC: questions@FreeBSD.org, hackers@FreeBSD.org Subject: Re: compile sendmail from /usr/src/usr.sbin/sendmail References: <199611061244.PAA02502@escape.cs.ibank.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Take a look at www.sendmail.org: there's a new version and security patches. You must use makesendmail (in the sources directory) instead of make. It is worthy to read the latest CERT and correctly configure sendmail. It is not necesary tu use the default deamon, and you MUST install smrsh. I had some problems due to that in the past, and even now crackers love to read my mail and forward it all over ! Pedro. Igor Vinokurov wrote: > > Hello! > > Anybody can explain me why sendmail does not compile from source > distribution (/usr/src/usr.sbin/sendmail) properly? > > I run make in this directory and have got some fatal errors then... :( > > P.S: In other words, I would like to upgrade sendmail at my 2.1.5R box. > I was compiling sendmail myself before this day, but now I would like > try to do it in the standard way. How did you compile sendmail to > prepare release version? > > -- > Igor Vinokurov From owner-freebsd-hackers Wed Nov 6 08:07:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27961 for hackers-outgoing; Wed, 6 Nov 1996 08:07:17 -0800 (PST) Received: from escape.cs.ibank.ru (igor@escape.cs.ibank.ru [194.58.131.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA27946; Wed, 6 Nov 1996 08:06:56 -0800 (PST) Received: (from igor@localhost) by escape.cs.ibank.ru (8.7.5/8.7.3/Zynaps) id TAA04231; Wed, 6 Nov 1996 19:05:45 +0300 (MSK) From: Igor Vinokurov Message-Id: <199611061605.TAA04231@escape.cs.ibank.ru> Subject: Re: compile sendmail from /usr/src/usr.sbin/sendmail In-Reply-To: <199611061535.JAA10008@night.primate.wisc.edu> from Paul DuBois at "Nov 6, 96 09:35:08 am" To: dubois@primate.wisc.edu (Paul DuBois) Date: Wed, 6 Nov 1996 19:05:44 +0300 (MSK) Cc: questions@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 Quoting Paul DuBois: > Igor Vinokurov writes: > > Anybody can explain me why sendmail does not compile from source > > distribution (/usr/src/usr.sbin/sendmail) properly? > > > > I run make in this directory and have got some fatal errors then... :( > > Errors such as? Ok, look there, please: ===> mailstats "Makefile", line 7: Could not find ../../Makefile.inc Fatal errors encountered -- cannot continue *** Error code 1 Stop. And so on. Yes, I know how to fix it, but its /usr/src/ stuff in not ready to compile? > > P.S: In other words, I would like to upgrade sendmail at my 2.1.5R box. > > I was compiling sendmail myself before this day, but now I would like > > try to do it in the standard way. How did you compile sendmail to > > prepare release version? > > You might try getting the current version (8.8.2) from ftp.sendmail.org. > I've had no trouble with that on a 2.1.5 box. I've too. But this behaviour (does not compile properly) strange to me. BTW, /usr/src/usr.sbin/sendmail not strong equal sendmail original dist. As example, some pathnames in manuals has changed, sendmail from 2.1.5R patched a bit for more support FreeBSD, etc, etc... If interested, see `diff -ru sendmail sendmail.dist` for more details. -- Igor Vinokurov, JSB "Inkombank" From owner-freebsd-hackers Wed Nov 6 08:34:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA00357 for hackers-outgoing; Wed, 6 Nov 1996 08:34: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 IAA00351 for ; Wed, 6 Nov 1996 08:34:29 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id KAA08735; Wed, 6 Nov 1996 10:28:42 -0600 From: Joe Greco Message-Id: <199611061628.KAA08735@brasil.moneng.mei.com> Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 6 Nov 1996 10:28:41 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, hannibal@cyberstation.net, hackers@freebsd.org In-Reply-To: <199611061507.QAA08319@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 6, 96 04:07:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I could swear I saw a "low-bandwidth ncftp" or something of the sort on > > > sunsite.unc.edu a couple years ago, so I think this is possible (Well, at > > > least in Linux...). It's apparently been deleted though. > > Some ftp sites (e.g. funic.funet.fi) tell you the amount of bandwidth > that has been allocated to your ftp connection. Try to look at what > kind of ftp server they use. The ones I have seen implement this with a sleep() mechanism. > > I am not aware of any general way to do this without code modifications, > > without the introduction of specialized code such as ET's bandwidth > > manager (and I am by no means certain that BWMGR can handle this). > > I think to remember this was discussed some time ago on the hackers list. > Unfortunately I don't remember the outcome of the discussion. Yeah, and I think I mentioned the sleep() thing last time too. > If you work inside the kernel (see the 'dummynet" stuff in my > home page, it introduces bandwidth limitations on your link; with a > little effort it can be configured to set different limitations on > different TCP/UDP ports), you can avoid modifying program sources, > which is extremely annoying. Yes, absolutely agree (at least for end users). > Otherwise, for servers which are launched > by inetd, perhaps you can add a bandwidth-limiter process between your > process and the socket and again avoid having to modify sources. > Perhaps tcp_wrappers do this ? I do not know. I have a tool that could perhaps be used in this sort of application, however... I have a little gimmick called "throttle" which accepts an argument of "K" that accepts input on stdin and outputs on stdout, and guarantees that a maximum of "n" K per second goes through it. It is a really trivial algorithm, and it is important to realize that the guarantee IS a maximum, but actual throughput may be substantially less. All it does is size = 1024 * argv[1] mem = malloc(size) while (data) { read(mem, size, stdin) write(mem, size, stdout) sleep(1) } "Duhhhhmb" but works. One could go to a very small bit of work to make it bidirectional, more suited to general inetd-type services. > > I will note that some PPP/SLIP software allows prioritization of certain > > types of traffic, by way of "TOS" (type of service) queue reordering. > > This works moderately well when the MTU is small and the amount of data > > being buffered by the modem is very small. Cheap modems generally do not > > give you that level of control. > > I don't think the modem takes more than 128-256 bytes of data, so > packet prioritization inside the PPP sw can serve the purpose. I have seen modems which appear to buffer well over a kilobyte of data.. ... JG From owner-freebsd-hackers Wed Nov 6 08:38:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA00880 for hackers-outgoing; Wed, 6 Nov 1996 08:38:36 -0800 (PST) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA00861 for ; Wed, 6 Nov 1996 08:38:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id IAA27500; Wed, 6 Nov 1996 08:23:54 -0800 (PST) Message-Id: <199611061623.IAA27500@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Gene Stark Cc: David Greenman , hackers@freebsd.org, jkh@freefall.freebsd.org Subject: Re: SUP on sup.freebsd.org Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 06 Nov 1996 08:23:53 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 6 Nov 1996 06:21:34 -0500 (EST) Gene Stark wrote: > (2) CVSup will not compile (at least not out of the box from > the ports/net/cvsup directory on FreeBSD 2.1.5, due to it > apparently wanting some "-lz" option from ld, which doesn't > seem to exist on the 2.1.5 ld. This effectively cuts off > anyone running 2.1.5/stable from tracking the FreeBSD source > tree and ports via sup. Uhh, that would be "libz" ... Just install that library. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From owner-freebsd-hackers Wed Nov 6 08:40:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA01129 for hackers-outgoing; Wed, 6 Nov 1996 08:40:54 -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 IAA01115 for ; Wed, 6 Nov 1996 08:40:50 -0800 (PST) Received: (from jkh@localhost) by time.cdrom.com (8.8.2/8.6.9) id IAA22367 for hackers@freebsd.org; Wed, 6 Nov 1996 08:40:49 -0800 (PST) Date: Wed, 6 Nov 1996 08:40:49 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199611061640.IAA22367@time.cdrom.com> To: hackers@freebsd.org Subject: port 106 in /etc/services Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has Qualcom really taken over port 106 for poppassd? 3COM gave it up fair and square? :-) If so, maybe we want to update our default services and inetd.conf files, so that the poppassd port is a drop-in. Jordan From owner-freebsd-hackers Wed Nov 6 08:57:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA02907 for hackers-outgoing; Wed, 6 Nov 1996 08:57:43 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA02897 for ; Wed, 6 Nov 1996 08:57:34 -0800 (PST) Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA29146; Wed, 6 Nov 1996 11:47:24 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA24277; Wed, 6 Nov 1996 11:47:25 -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 MAA16602; Wed, 6 Nov 1996 12:53:43 GMT Message-Id: <199611061253.MAA16602@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: Karl Denninger Cc: hackers@freebsd.org Subject: Re: BSDI mount - - the patch posted to me works (somewhat) In-Reply-To: Your message of "Tue, 05 Nov 1996 22:42:06 CST." <199611060442.WAA05013@Jupiter.Mcs.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 12:53:42 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just a nit. I use the patch on a disk with 3 slices (one of which is BSD/OS and one is FreeBSD). It allows me to use BSD/OS partitions just fine from FreeBSD. ******* Working on device /dev/rsd0 ******* parameters extracted from in-core disklabel are: cylinders=522 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=522 heads=255 sectors/track=63 (16065 blks/cyl) Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 3261132 (1592 Meg), flag 80 beg: cyl 0/ sector 1/ head 1; end: cyl 202/ sector 63/ head 254 The data for partition 1 is: sysid 6,(Primary 'big' DOS (> 32MB)) start 3261195, size 1445850 (705 Meg), flag 0 beg: cyl 203/ sector 1/ head 0; end: cyl 292/ sector 63/ head 254 The data for partition 2 is: sysid 159,(unknown) start 4707045, size 1429785 (698 Meg), flag 0 beg: cyl 293/ sector 1/ head 0; end: cyl 381/ sector 63/ head 254 The data for partition 3 is: -- 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 Wed Nov 6 09:00:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA03218 for hackers-outgoing; Wed, 6 Nov 1996 09:00:49 -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 JAA03206 for ; Wed, 6 Nov 1996 09:00:43 -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 SAA12083; Wed, 6 Nov 1996 18:00:18 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA10101; Wed, 6 Nov 1996 18:00:17 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id QAA02914; Wed, 6 Nov 1996 16:57:02 +0100 (MET) From: J Wunsch Message-Id: <199611061557.QAA02914@uriah.heep.sax.de> Subject: Re: Phillips CDD 521 To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 16:57:02 +0100 (MET) Cc: green@arf.cs.sunyit.edu (Charles Green) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611061510.KAA03918@arf.cs.sunyit.edu> from Charles Green at "Nov 6, 96 10:10:32 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 Charles Green wrote: > Phillips CDD 521 - > Did anyone have any luck getting this beast to work? I can > get one for around $500.00 and I was seriously thinking about it. Is this a CD-R drive? I think chances are good. I've just committed the changes for recognizing the CDD2000 series drives. I think you could clone the entry in sys/scsi/scsiconfig.c for the CDD521. Perhaps it's even save to reduce the match string from "CDD2000*" to "CDD*". -- 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 Wed Nov 6 09:21:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA04959 for hackers-outgoing; Wed, 6 Nov 1996 09:21:23 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA04951 for ; Wed, 6 Nov 1996 09:21:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA18040; Wed, 6 Nov 1996 10:20:52 -0700 Message-Id: <199611061720.KAA18040@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: hackers@freefall.freebsd.org cc: Darren Reed Subject: Re: Gigabyte 586DX mb w/ 2940UW ob Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 10:20:51 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >I was wandering around town recently, when I came across a motherboard >being sold that had SCSI built into it (the subject is the MB "type")! >Does FreeBSD support this ? works great, both single and dual CPU. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-hackers Wed Nov 6 10:34:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00362 for hackers-outgoing; Wed, 6 Nov 1996 10:34:25 -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 KAA00321 for ; Wed, 6 Nov 1996 10:34:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA14070 for ; Wed, 6 Nov 1996 10:31:40 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08499; Wed, 6 Nov 1996 11:19:33 -0700 From: Terry Lambert Message-Id: <199611061819.LAA08499@phaeton.artisoft.com> Subject: Re: port 106 in /etc/services To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 6 Nov 1996 11:19:33 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199611061640.IAA22367@time.cdrom.com> from "Jordan K. Hubbard" at Nov 6, 96 08:40:49 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 > Has Qualcom really taken over port 106 for poppassd? 3COM gave it > up fair and square? :-) > > If so, maybe we want to update our default services and inetd.conf > files, so that the poppassd port is a drop-in. Eudora and most other POP mail clients with a "change password" pulldown use it. You can see what they want for their /etc/services in the poppasswd sources on their FTP site (/pub/unix/servers/...). The real question is: who is the official maintainer of /etc/services? That's where it should be reported. Doesn't IANA "own" port assignment? 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 6 10:34:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00378 for hackers-outgoing; Wed, 6 Nov 1996 10:34:26 -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 KAA00343 for ; Wed, 6 Nov 1996 10:34:22 -0800 (PST) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA14022 for ; Wed, 6 Nov 1996 10:25:17 -0800 (PST) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id NAA22804; Wed, 6 Nov 1996 13:26:44 -0500 Date: Wed, 6 Nov 1996 13:26:44 -0500 Message-Id: <199611061826.NAA22804@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: Luigi Rizzo From: dennis@etinc.com (dennis) Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > I'm trying to come up with some way to limit the amount of bandwidth on a >> > socket, so I can have my mail and large files retrieve without slowing >> > down a telnet session that much. >> > >... >> > >> > I could swear I saw a "low-bandwidth ncftp" or something of the sort on >> > sunsite.unc.edu a couple years ago, so I think this is possible (Well, at >> > least in Linux...). It's apparently been deleted though. > >Some ftp sites (e.g. funic.funet.fi) tell you the amount of bandwidth >that has been allocated to your ftp connection. Try to look at what >kind of ftp server they use. They're not real...Linux has what they call a "shaper", but its almost totally bogus. Calling anything that you are talking about a "bandwidth limiter" is inaccurate anyway.......its really a throughput limiter....the bandwidth is always the same.... Dennis From owner-freebsd-hackers Wed Nov 6 10:34:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00398 for hackers-outgoing; Wed, 6 Nov 1996 10:34:29 -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 KAA00351 for ; Wed, 6 Nov 1996 10:34:24 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA13986 for ; Wed, 6 Nov 1996 10:20:31 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id KAA10565; Wed, 6 Nov 1996 10:19:13 -0800 (PST) Message-Id: <199611061819.KAA10565@austin.polstra.com> To: thorpej@nas.nasa.gov Subject: Re: SUP on sup.freebsd.org Newsgroups: polstra.freebsd.hackers In-Reply-To: <199611061623.IAA27500@lestat.nas.nasa.gov> References: <199611061623.IAA27500@lestat.nas.nasa.gov> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org, gene@starkhome.cs.sunysb.edu Date: Wed, 06 Nov 1996 10:19:13 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199611061623.IAA27500@lestat.nas.nasa.gov> thorpej@nas.nasa.gov writes: > On Wed, 6 Nov 1996 06:21:34 -0500 (EST) > Gene Stark wrote: > > > (2) CVSup will not compile (at least not out of the box from > > the ports/net/cvsup directory on FreeBSD 2.1.5, due to it > > apparently wanting some "-lz" option from ld, which doesn't > > seem to exist on the 2.1.5 ld. This effectively cuts off > > anyone running 2.1.5/stable from tracking the FreeBSD source > > tree and ports via sup. > > Uhh, that would be "libz" ... Just install that library. This morning I tagged "libz" into the -stable branch in order to get rid of this common complaint. -- 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 Wed Nov 6 10:34:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00424 for hackers-outgoing; Wed, 6 Nov 1996 10:34:31 -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 KAA00390 for ; Wed, 6 Nov 1996 10:34:28 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA14075 for ; Wed, 6 Nov 1996 10:34:04 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA08899; Wed, 6 Nov 1996 12:31:47 -0600 From: Joe Greco Message-Id: <199611061831.MAA08899@brasil.moneng.mei.com> Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Wed, 6 Nov 1996 12:31:47 -0600 (CST) Cc: hackers@freebsd.org In-Reply-To: from "Ron G. Minnich" at Nov 6, 96 10:05:50 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > int s, rval; > > s = socket(...); > > while ((rval = read(..., 1024)) > 0) { > > sleep(1); > > ooch, ouch. my brain now hurts :-) Whazzamatta? Don't tell me you have never executed a gross hack before!! > Joe's method will work fine, but we may all agree we want a little more. > Well, we're working on that here. So I would like to judge interest from > this group. > > What we're looking at is putting ioctls in at the socket layer to > implement rsvp-style reservations. I.e. you would use rsvp as now for > reserving qualities related to flow of data, and our code would operate at > the socket layer for enforcing those reservations. We want it to be at the > socket layer so the user can have the controls work the same even though a > socket may at the lower level be unix-domain, tcp, and so on. We've found > that this sort of control is very important for distributed computing. That is nice at an upper level, but I can see at least as much usefulness at a more administrative level as well. A particular application may certainly know that it wishes for bandwidth of 'X' and it can arrange that through some mechanism. A socket level mechanism can provide a maximum cap, certainly... However, it would also be nice to be able to deal with this at the network level, and while some things are already available to allow this (ET's bandwidth manager for example), it would be something that I recommend you at least consider and be aware of. ... JG From owner-freebsd-hackers Wed Nov 6 10:34:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00465 for hackers-outgoing; Wed, 6 Nov 1996 10:34: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 KAA00439 for ; Wed, 6 Nov 1996 10:34:33 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA13950 for ; Wed, 6 Nov 1996 10:16:14 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id KAA10529; Wed, 6 Nov 1996 10:14:55 -0800 (PST) Message-Id: <199611061814.KAA10529@austin.polstra.com> To: karl@Mcs.Net Subject: Re: SUP on sup.freebsd.org Newsgroups: polstra.freebsd.hackers In-Reply-To: <199611061504.JAA07519@Mercury.mcs.net> References: <199611061504.JAA07519@Mercury.mcs.net> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Wed, 06 Nov 1996 10:14:54 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199611061504.JAA07519@Mercury.mcs.net> karl@Mcs.Net writes: > Ok, where does one get a copy of CVSup that *doesn't* require that I build > other things (ie: is pre-packaged, including the Modula 3 port required)? >From the announcement: Where to Get CVSup ------------------ CVSup is free software. It is available from the following FTP sites: ftp://freefall.freebsd.org/pub/CVSup/ ftp://ftp.polstra.com/pub/FreeBSD/CVSup/ (slow; avoid if possible) Full sources as well as FreeBSD binaries are available: cvsup-bin-13.5.tar.gz FreeBSD static binaries for the client cvsupd-bin-13.5.tar.gz FreeBSD static binaries for the server cvsup-13.5.tar.gz Sources ** MD5 signatures for these files are: MD5 (cvsup-bin-13.5.tar.gz) = 6ee6a4b335c18d0d00b2f140928d6a3d MD5 (cvsupd-bin-13.5.tar.gz) = 005791d8483570f2a093b7e202876d95 MD5 (cvsup-13.5.tar.gz) = 82c6dc9290fb1ce055a6027670af57f6 An updated port will appear in the FreeBSD ports and packages collections soon: ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup/ ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/net/cvsup-13.5.tgz The FreeBSD package now depends only on the "modula-3-lib" package, a subset of the Modula-3 installation consisting of only the shared libraries. Because of this, you can now install and use the "cvsup" package in a reasonable amount of disk space. The package is much smaller than the statically linked binary distribution, so updates to new versions of CVSup should be more convenient now. The package is the recommended distribution for binary-only users. The static binary distributions will probably be phased out soon. If you want SOCKS support, you must also install the "modula-3-socks" port or package: ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/lang/modula-3-socks/ ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/lang/modula-3-socks-1.0.tgz SOCKS is supported only under FreeBSD, and only with dynamically linked executables. The static binary distributions do not support SOCKS. -- 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 Wed Nov 6 10:34:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00498 for hackers-outgoing; Wed, 6 Nov 1996 10:34:41 -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 KAA00462 for ; Wed, 6 Nov 1996 10:34:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA13946 for ; Wed, 6 Nov 1996 10:16:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08471; Wed, 6 Nov 1996 11:06:44 -0700 From: Terry Lambert Message-Id: <199611061806.LAA08471@phaeton.artisoft.com> Subject: Re: Loadable Kernel Modules Docs To: tony@netcon.com (Tony Ardolino) Date: Wed, 6 Nov 1996 11:06:44 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <328077F6.D47@netcon.com> from "Tony Ardolino" at Nov 6, 96 06:35: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 > Hi! > Could someone help me with Documentation or explanation on FreeBSD > Loadable Kernel Modules. We have a VFS File system and a Protocol stack > that we want to make loadable modules. We think we have added all the > code thats required but we are just guessing. We have done the > same loadable modules for SunOS, Solaris and AIX before, so just a litte > help is all thats required. We like to try to avoid making this a > lifetime occupation. > Thank for all you help. Hi Tony, long time, no hear! If the VFS adds VOP calls, you will need to rebuild the kernel. The design of the VFS framework supports adding VOP calls, but vfs_init() uses the contents of the UFS/FFS struct vnops in order to set the number of VOP calls instead of the size of the structure in vnode_if.c. I have submitted patches to fix this, but no one has integrated them. At a minimum, you will have to build a new vnode_if.c and recompile UFS and FFS to understand and FS extensions. Since you have a history of putting NetWare Clients into UNIX OS's, I suspect you may need to force a recompile of the client machine, even if you use binary modules. If you aren't assing VOP's, then the source examples in /usr/src/lkm for mfs and procfs are probably your best bet. If you consume functions from your protocol module in the FS, you will need to load the protocol module first. If the protocol module is IPX, I'd suggest using the built in IPX. The other two possibilities are SPX (since you also have a history of building NVT -- NetWare Virtual Terminal -- support for UNIX boxes 8-)) and a MUX and/or client services device. For the SPX, you may have a problem. Protocol stacks and socksys layers are problematically interfaced. The best you could hope for is to submit some patches for adding blank slots, which your LKM would then fill in. If you do this, then the ipfw code is probably your best example. If you want to discuss LKM consumer interfaces for protocol stacks, you should start with the discussion Garrett Wollman and I had on the -current list when the ISO networking was removed (this was the libc version bump). The discussion is archives in the -current list archives on www.freebsd.org. I have some stub code I built during the discussion which uses socket classes with some generic routines, and has backward compatability code to implement the stubs for inet_*(), etc.. Basically, it provides some generic socket top-end interfacing, and the libc opens a shared object via dlopen, one per supported socket class, from a table of protocol families vs. modules. The idea is that you can dump a protocol family in the kernel, add an object to /usr/lib, and add a table entry to /usr/lib/protocols, and you ,agically can add back support for ISO and XNS protocol families. It would work for SPX or DECNet Phase V or whtever you wanted to add to the kernel dynamically, as well. Unfortunately it's only stub code. 8-(. For a MUX (which you might need for "Server Busy" NCP turnaround, or to support "hot engine scheduling" if your user space server uses a "work to do model" with anonymous engines), the IPFW code is your best bet. The reason for this is that a mux is a consumer interface more than it is a provider, and you should be able to push everything you need in user space over a standard device node. The only tricky part will be creating the device. I suggest breaking the module into a "device" piece and a "mux" piece, and loading them in [mux,device] order. Alternately, you could use the device table code in /sys/kern/kern_lkm.c to handle the device creation as part of the init strategy. I recommend breaking it up, since the LKM number for a device can be determined from user space (see the "modstat" sources), and this is its index in the bdev/cdev table (depending on the device type). I could have guess wrong on all this, and if so, at least you have some pointers for a basic strategy for the types of modules you want to load. 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 6 10:35:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00731 for hackers-outgoing; Wed, 6 Nov 1996 10:35:25 -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 KAA00683 for ; Wed, 6 Nov 1996 10:35:16 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA13747 for ; Wed, 6 Nov 1996 09:49:08 -0800 (PST) Received: from irz301.inf.tu-dresden.de by mail.crl.com with SMTP id AA28272 (5.65c/IDA-1.5 for ); Wed, 6 Nov 1996 10:48:57 -0700 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 SAA13774; Wed, 6 Nov 1996 18:40:22 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA10385; Wed, 6 Nov 1996 18:40:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id SAA17533; Wed, 6 Nov 1996 18:25:22 +0100 (MET) From: J Wunsch Message-Id: <199611061725.SAA17533@uriah.heep.sax.de> Subject: Re: BSDI mount - - the patch posted to me works (somewhat) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 18:25:20 +0100 (MET) Cc: karl@Mcs.Net, matt@lkg.dec.com (Matt Thomas) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611061253.MAA16602@whydos.lkg.dec.com> from Matt Thomas at "Nov 6, 96 12:53:42 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 Matt Thomas wrote: > Just a nit. I use the patch on a disk with 3 slices (one of which is > BSD/OS and one is FreeBSD). It allows me to use BSD/OS partitions just > fine from FreeBSD. Yes, i figured this from the patch. However, Karl's problem was of different nature: his disks don't have valid fdisk tables. Your patch should be worth considering for the future, though i would hesitate to crunch it into the 2.2 branch now that it's already 3 minutes to 12. I'll leave the integration to Bruce, he's the most knowledgable guy regarding all that disklabel stuff... ;) -- 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 Wed Nov 6 10:35:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00804 for hackers-outgoing; Wed, 6 Nov 1996 10:35:42 -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 KAA00775 for ; Wed, 6 Nov 1996 10:35:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA13718 for ; Wed, 6 Nov 1996 09:42:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08415; Wed, 6 Nov 1996 10:33:12 -0700 From: Terry Lambert Message-Id: <199611061733.KAA08415@phaeton.artisoft.com> Subject: Re: Davidg bug (was: mount panics & hangs) To: julian@whistle.com (Julian Elischer) Date: Wed, 6 Nov 1996 10:33:11 -0700 (MST) Cc: archie@whistle.com, freebsd-hackers@freebsd.org In-Reply-To: <327FE834.167EB0E7@whistle.com> from "Julian Elischer" at Nov 5, 96 05:21:56 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 > dounmount(mp, flags, p) > register struct mount *mp; > int flags; > struct proc *p; > { > struct vnode *coveredvp; > int error; > > coveredvp = mp->mnt_vnodecovered; > if (vfs_busy(mp)) > return (EBUSY); ^^^^^^^^^^^^^^^^^^^^^^^ > mp->mnt_flag |= MNT_UNMOUNT; > error = vfs_lock(mp); > if (error) > return (error); <-------line "C" ^^^^^^^^^^^^^^^^^^^^^^^ > BTW there is another small bug, which is.. the return at line "C" > should also do a vfs_unbusy() > > suggestions? Add a "NOWAIT" flags value, obey it at the indicated locations, and don't pass it in this case (only on shutdown). In reality, there should be a mutex for the VFS structures, the list of mounted fs's being one of them, where "dounmount" is called, so you never have more than one process in the mount code. The problem is that the vfs_busy/vfs_lock pair create a race condition because there is not an imposed order of operation. That comes from mixing the vfsop and vop layers without regard to structural call layering (vfsop is hierarchically above vop). So you're right: it's a "thundering herd" problem, where the wrong process happens to win the race. I suspect that this requires the while loop to happen so that the priority becomes inverted when both processes are marked ready-to-run. Has this problem *ever* been repeated without that while loop to torture it into happening? 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 6 10:41:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01644 for hackers-outgoing; Wed, 6 Nov 1996 10:41:41 -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 KAA01634 for ; Wed, 6 Nov 1996 10:41:38 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id KAA10633; Wed, 6 Nov 1996 10:39:03 -0800 (PST) Message-Id: <199611061839.KAA10633@austin.polstra.com> To: gene@starkhome.cs.sunysb.edu Subject: Re: SUP on sup.freebsd.org Newsgroups: polstra.freebsd.hackers In-Reply-To: <199611061121.GAA20346@starkhome.cs.sunysb.edu> References: <55pm86$j7n@starkhome.cs.sunysb.edu> <199611061121.GAA20346@starkhome.cs.sunysb.edu> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Wed, 06 Nov 1996 10:39:03 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199611061121.GAA20346@starkhome.cs.sunysb.edu> gene@starkhome.cs.sunysb.edu writes: > I can well sympathize with the need to do something about your network > load problems, but I just tried (unsuccessfully) to build CVSup and I have > the following *major* complaints, which I hope you will consider: > > (1) CVSup, being written in Modula3, requires the importation > of a *GIANT*, *BLOATED* language subsystem, which is not > currently a standard part of FreeBSD (nor should it be). Other people have already pointed out the availability of statically linked binary releases, so I won't beat that dead horse. As to the "*GIANT*, *BLOATED* language subsystem," you are out of date on that. The current CVSup package (the one from the packages collection, not the static binary release which is completely stand-alone) depends only on the "modula-3-lib" package, whose tarball is < 1 MB and which occupies 3.2 MB when fully installed. That is *slightly* larger than the static binary installation, which weighs in at 2.5 MB. However, I expect to update CVSup more frequently than the Modula-3 ports, so in the long run you'll be better off to install "modula-3-lib" and use the package version of CVSup. BTW, if you think 3.2 MB is still too giant and bloated, well, welcome to the 1980's, Bubba. ;-) > As it happens, I have a Modula3 already installed on some > systems we are using for educational purposes. However, > where I want to sup from is a server system that students > don't use, and I'm not thrilled about copying vast quantities > of shared libraries and other cruft yet to be determined > over to that system so that I can run this one Modula3 program > on the server. You have options. Use the static binary, use the package, or use CTM. > (2) CVSup will not compile (at least not out of the box from > the ports/net/cvsup directory on FreeBSD 2.1.5, due to it > apparently wanting some "-lz" option from ld, which doesn't > seem to exist on the 2.1.5 ld. This effectively cuts off > anyone running 2.1.5/stable from tracking the FreeBSD source > tree and ports via sup. I brought "libz" into the -stable branch this morning. I also retroactively zapped it onto all existing 2.1.5 CDs. (Just kidding about that last part. :-) -- 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 Wed Nov 6 11:21:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA12608 for hackers-outgoing; Wed, 6 Nov 1996 11:21:19 -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 LAA12528; Wed, 6 Nov 1996 11:21:11 -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 LAA09162; Wed, 6 Nov 1996 11:15:25 -0800 (PST) Message-ID: <3280E3BC.15FB7483@whistle.com> Date: Wed, 06 Nov 1996 11:15:08 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Terry Lambert CC: archie@whistle.com, freebsd-hackers@freebsd.org, davidg@freebsd.org Subject: Re: Davidg bug (was: mount panics & hangs) References: <199611061733.KAA08415@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 Terry Lambert wrote: > > > dounmount(mp, flags, p) > > register struct mount *mp; > > int flags; > > struct proc *p; > > { > > struct vnode *coveredvp; > > int error; > > > > coveredvp = mp->mnt_vnodecovered; > > if (vfs_busy(mp)) > > return (EBUSY); > ^^^^^^^^^^^^^^^^^^^^^^^ > > mp->mnt_flag |= MNT_UNMOUNT; > > error = vfs_lock(mp); > > if (error) > > return (error); <-------line "C" > ^^^^^^^^^^^^^^^^^^^^^^^ > > > BTW there is another small bug, which is.. the return at line "C" > > should also do a vfs_unbusy() > > > > suggestions? > > Add a "NOWAIT" flags value, obey it at the indicated locations, and > don't pass it in this case (only on shutdown). > > In reality, there should be a mutex for the VFS structures, the list > of mounted fs's being one of them, where "dounmount" is called, so you > never have more than one process in the mount code. > > The problem is that the vfs_busy/vfs_lock pair create a race condition > because there is not an imposed order of operation. That comes from > mixing the vfsop and vop layers without regard to structural call > layering (vfsop is hierarchically above vop). > > So you're right: it's a "thundering herd" problem, where the wrong > process happens to win the race. > > I suspect that this requires the while loop to happen so that the > priority becomes inverted when both processes are marked ready-to-run. > > Has this problem *ever* been repeated without that while loop to > torture it into happening? yes it happens regularly to us which is why we wrote the test case to isolate it. David, do you have any suggested fix? If you want I can try work a patch and send it to you for comments. (though I don't yet understand why there needs to be both vfs_busy and vfs_lock) From owner-freebsd-hackers Wed Nov 6 11:32:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA19294 for hackers-outgoing; Wed, 6 Nov 1996 11:32:37 -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 LAA19267 for ; Wed, 6 Nov 1996 11:32:30 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.2/8.7.3) id UAA02640; Wed, 6 Nov 1996 20:29:52 +0100 (MET) Message-Id: <199611061929.UAA02640@ravenock.cybercity.dk> Subject: Re: SUP on sup.freebsd.org To: jdp@polstra.com (John Polstra) Date: Wed, 6 Nov 1996 20:29:52 +0100 (MET) From: "Soren Schmidt" Cc: gene@starkhome.cs.sunysb.edu, hackers@FreeBSD.org In-Reply-To: <199611061839.KAA10633@austin.polstra.com> from "John Polstra" at Nov 6, 96 10:39:03 am 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 John Polstra who wrote: > > As to the "*GIANT*, *BLOATED* language subsystem," you are out of > date on that. The current CVSup package (the one from the packages > collection, not the static binary release which is completely > stand-alone) depends only on the "modula-3-lib" package, whose > tarball is < 1 MB and which occupies 3.2 MB when fully installed. > That is *slightly* larger than the static binary installation, > which weighs in at 2.5 MB. However, I expect to update CVSup more > frequently than the Modula-3 ports, so in the long run you'll be > better off to install "modula-3-lib" and use the package version > of CVSup. > > BTW, if you think 3.2 MB is still too giant and bloated, well, > welcome to the 1980's, Bubba. ;-) Erhm, why on earth did you chose Modula3 ?? I newer got the warm fuzzies by mr. Wirth's languages , they are maybe good educational tools, but for real world apps, nah.... :) Oh and yes I have seen apps written in modula3, all of which was horrible performers, and impossible to port to new platforms, so the management decide a complete rewrite in, guess what, C! (I ducking now and jumping into the asbestos suit) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 6 11:48:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20307 for hackers-outgoing; Wed, 6 Nov 1996 11:48:20 -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 LAA20302 for ; Wed, 6 Nov 1996 11:48:18 -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 LAA14167 for ; Wed, 6 Nov 1996 11:48:17 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17195(4)>; Wed, 6 Nov 1996 11:43:54 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177557>; Wed, 6 Nov 1996 11:43:34 -0800 X-Mailer: exmh version 1.6.7 5/3/96 To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: port 106 in /etc/services In-reply-to: Your message of "Wed, 06 Nov 1996 08:40:49 PST." <199611061640.IAA22367@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 6 Nov 1996 11:43:22 PST From: Bill Fenner Message-Id: <96Nov6.114334pst.177557@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611061640.IAA22367@time.cdrom.com> Jordan wrote: >Has Qualcom really taken over port 106 for poppassd? Apparently. >3COM gave it up fair and square? :-) Apparently not; check ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers . ("but I've never heard of '3com-tsmux', and we sell the biggest POP client in the universe, so what do we care?") Bill From owner-freebsd-hackers Wed Nov 6 11:52:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20586 for hackers-outgoing; Wed, 6 Nov 1996 11:52: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 LAA20581 for ; Wed, 6 Nov 1996 11:52:17 -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 LAA23244; Wed, 6 Nov 1996 11:52:12 -0800 (PST) To: Bill Fenner cc: hackers@freebsd.org Subject: Re: port 106 in /etc/services In-reply-to: Your message of "Wed, 06 Nov 1996 11:43:22 PST." <96Nov6.114334pst.177557@crevenia.parc.xerox.com> Date: Wed, 06 Nov 1996 11:52:11 -0800 Message-ID: <23242.847309931@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers . Hmmmm. Still, I wonder if we want to sync our services file up with this list - theirs is a lot larger. Maybe too much, I dunno. Jordan From owner-freebsd-hackers Wed Nov 6 12:05:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA21323 for hackers-outgoing; Wed, 6 Nov 1996 12:05:02 -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 MAA21286 for ; Wed, 6 Nov 1996 12:04:46 -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 MAA09942 for ; Wed, 6 Nov 1996 12:04:04 -0800 (PST) Message-ID: <3280EF24.ABD322C@whistle.com> Date: Wed, 06 Nov 1996 12:03:48 -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: Inetd mod.. comments? Content-Type: multipart/mixed; boundary="------------2F1CF0FB237C228A31DFF4F5" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------2F1CF0FB237C228A31DFF4F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have some patches to Inetd her that I sent out for comment. the only comment I got was "Gee that's neat!, I need that" but no technical reviews or code checks.. I would like to commit this change but I don't want to do it without a reviewer to put on the commit message.. I include the patch (actually a slightly improved version) again... As I said before this provides us (whistle) with protection against a denial of service attack. reviews please..... --------------2F1CF0FB237C228A31DFF4F5 Content-Type: text/plain; charset=us-ascii; name="inetd.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="inetd.patch" Index: Makefile =================================================================== RCS file: /cvs/freebsd/src/usr.sbin/inetd/Makefile,v retrieving revision 1.3 diff -c -r1.3 Makefile *** 1.3 1996/01/01 08:42:22 --- Makefile 1996/11/06 19:02:22 *************** *** 4,9 **** --- 4,12 ---- MAN8= inetd.8 MLINKS= inetd.8 inetd.conf.5 + COPTS+= -Wall + COPTS+= -DSANITY_CHECK + DPADD+= ${LIBUTIL} LDADD+= -lutil Index: inetd.8 =================================================================== RCS file: /cvs/freebsd/src/usr.sbin/inetd/inetd.8,v retrieving revision 1.9 diff -c -r1.9 inetd.8 *** 1.9 1996/08/09 22:20:23 --- inetd.8 1996/11/06 19:02:22 *************** *** 101,107 **** service name socket type protocol ! wait/nowait user server program server program arguments --- 101,107 ---- service name socket type protocol ! {wait|nowait}[/max-child] user server program server program arguments *************** *** 260,265 **** --- 260,274 ---- requests until a timeout. TCPMUX services must use .Dq nowait . + .Pp + The maximum number of outstanding child processes (or ``threads'') + for a ``nowait'' service may be explicitly specified by appending a + ``/'' followed by the number to the ``nowait'' keyword. Normally + (or if a value of zero is specified) there is no maximum. Otherwise, + once the maximum is reached, further connection attempts will be + queued up until an existing child process exits. This also works + in the case of ``wait'' mode, although a value other than one (the + default) might not make sense in some cases. .Pp The .Em user Index: inetd.c =================================================================== RCS file: /cvs/freebsd/src/usr.sbin/inetd/inetd.c,v retrieving revision 1.15 diff -c -r1.15 inetd.c *** 1.15 1996/11/01 01:42:08 --- inetd.c 1996/11/06 19:02:22 *************** *** 32,45 **** */ #ifndef lint ! static char copyright[] = "@(#) Copyright (c) 1983, 1991, 1993, 1994\n\ The Regents of the University of California. All rights reserved.\n"; #endif /* not lint */ #ifndef lint /* from: @(#)inetd.c 8.4 (Berkeley) 4/13/94"; */ ! static char inetd_c_rcsid[] = "$Id: inetd.c,v 1.15 1996/11/01 01:42:08 alex Exp $"; #endif /* not lint */ --- 32,45 ---- */ #ifndef lint ! static char copyright[] __attribute__ ((unused)) = "@(#) Copyright (c) 1983, 1991, 1993, 1994\n\ The Regents of the University of California. All rights reserved.\n"; #endif /* not lint */ #ifndef lint /* from: @(#)inetd.c 8.4 (Berkeley) 4/13/94"; */ ! static char inetd_c_rcsid[] __attribute__ ((unused)) = "$Id: inetd.c,v 1.15 1996/11/01 01:42:08 alex Exp $"; #endif /* not lint */ *************** *** 112,117 **** --- 112,118 ---- #include #include #include + #include #include #include *************** *** 124,139 **** #include #include #include #include "pathnames.h" #define TOOMANY 256 /* don't start more than TOOMANY */ #define CNT_INTVL 60 /* servers in CNT_INTVL sec. */ #define RETRYTIME (60*10) /* retry after bind or server fail */ #define SIGBLOCK (sigmask(SIGCHLD)|sigmask(SIGHUP)|sigmask(SIGALRM)) - int debug = 0; int log = 0; int nsock, maxsock; --- 125,141 ---- #include #include #include + #include #include "pathnames.h" #define TOOMANY 256 /* don't start more than TOOMANY */ #define CNT_INTVL 60 /* servers in CNT_INTVL sec. */ #define RETRYTIME (60*10) /* retry after bind or server fail */ + #define MAX_MAXCHLD 32767 /* max allowable max children */ #define SIGBLOCK (sigmask(SIGCHLD)|sigmask(SIGHUP)|sigmask(SIGALRM)) int debug = 0; int log = 0; int nsock, maxsock; *************** *** 149,155 **** char *se_service; /* name of service */ int se_socktype; /* type of socket to use */ char *se_proto; /* protocol used */ ! short se_wait; /* single threaded server */ short se_checked; /* looked at during merge */ char *se_user; /* user name to run as */ struct biltin *se_bi; /* if built-in, description */ --- 151,159 ---- char *se_service; /* name of service */ int se_socktype; /* type of socket to use */ char *se_proto; /* protocol used */ ! short se_maxchild; /* max number of children */ ! short se_numchild; /* current number of children */ ! short *se_pids; /* array of child pids */ short se_checked; /* looked at during merge */ char *se_user; /* user name to run as */ struct biltin *se_bi; /* if built-in, description */ *************** *** 159,165 **** int se_fd; /* open descriptor */ int se_type; /* type */ struct sockaddr_in se_ctrladdr;/* bound address */ ! int se_rpc; /* ==1 if RPC service */ int se_rpc_prog; /* RPC program number */ u_int se_rpc_lowvers; /* RPC low version */ u_int se_rpc_highvers; /* RPC high version */ --- 163,170 ---- int se_fd; /* open descriptor */ int se_type; /* type */ struct sockaddr_in se_ctrladdr;/* bound address */ ! u_char se_accept; /* i.e., wait/nowait mode */ ! u_char se_rpc; /* ==1 if RPC service */ int se_rpc_prog; /* RPC program number */ u_int se_rpc_lowvers; /* RPC low version */ u_int se_rpc_highvers; /* RPC high version */ *************** *** 195,201 **** --- 200,209 ---- char *newstr __P((char *)); char *nextline __P((FILE *)); void print_service __P((char *, struct servtab *)); + void addchild __P((struct servtab *, int)); void reapchild __P((int)); + void enable __P((struct servtab *)); + void disable __P((struct servtab *)); void retry __P((int)); int setconfig __P((void)); void setup __P((struct servtab *)); *************** *** 209,215 **** char *bi_service; /* internally provided service name */ int bi_socktype; /* type of socket supported */ short bi_fork; /* 1 if should fork before call */ ! short bi_wait; /* 1 if should wait for child */ void (*bi_fn)(); /* function which performs it */ } biltins[] = { /* Echo received data */ --- 217,223 ---- char *bi_service; /* internally provided service name */ int bi_socktype; /* type of socket supported */ short bi_fork; /* 1 if should fork before call */ ! short bi_maxchild; /* max number of children (default) */ void (*bi_fn)(); /* function which performs it */ } biltins[] = { /* Echo received data */ *************** *** 298,304 **** if (!inet_aton(optarg, &bind_address)) { syslog(LOG_ERR, "-a %s: invalid IP address", optarg); ! exit(1); } break; case 'p': --- 306,312 ---- if (!inet_aton(optarg, &bind_address)) { syslog(LOG_ERR, "-a %s: invalid IP address", optarg); ! exit(EX_USAGE); } break; case 'p': *************** *** 309,315 **** syslog(LOG_ERR, "usage: inetd [-dl] [-a address] [-R rate]" " [-p pidfile] [conf-file]"); ! exit(1); } argc -= optind; argv += optind; --- 317,323 ---- syslog(LOG_ERR, "usage: inetd [-dl] [-a address] [-R rate]" " [-p pidfile] [conf-file]"); ! exit(EX_USAGE); } argc -= optind; argv += optind; *************** *** 383,389 **** if (debug) fprintf(stderr, "someone wants %s\n", sep->se_service); ! if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) { ctrl = accept(sep->se_fd, (struct sockaddr *)0, (int *)0); if (debug) --- 391,397 ---- if (debug) fprintf(stderr, "someone wants %s\n", sep->se_service); ! if (sep->se_accept && sep->se_socktype == SOCK_STREAM) { ctrl = accept(sep->se_fd, (struct sockaddr *)0, (int *)0); if (debug) *************** *** 395,401 **** sep->se_service); continue; } ! if(log) { i = sizeof peer; if(getpeername(ctrl, (struct sockaddr *) &peer, &i)) { --- 403,409 ---- sep->se_service); continue; } ! if (log) { i = sizeof peer; if(getpeername(ctrl, (struct sockaddr *) &peer, &i)) { *************** *** 456,475 **** } if (pid < 0) { syslog(LOG_ERR, "fork: %m"); ! if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) close(ctrl); sigsetmask(0L); sleep(1); continue; } ! if (pid && sep->se_wait) { ! sep->se_wait = pid; ! if (sep->se_fd >= 0) { ! FD_CLR(sep->se_fd, &allsock); ! nsock--; ! } ! } sigsetmask(0L); if (pid == 0) { if (dofork) { --- 464,478 ---- } if (pid < 0) { syslog(LOG_ERR, "fork: %m"); ! if (sep->se_accept && sep->se_socktype == SOCK_STREAM) close(ctrl); sigsetmask(0L); sleep(1); continue; } ! if (pid) ! addchild(sep, pid); sigsetmask(0L); if (pid == 0) { if (dofork) { *************** *** 478,488 **** maxsock); for (tmpint = maxsock; tmpint > 2; tmpint--) if (tmpint != ctrl) ! close(tmpint); } ! if (sep->se_bi) (*sep->se_bi->bi_fn)(ctrl, sep); ! else { if (debug) fprintf(stderr, "%d execl %s\n", getpid(), sep->se_server); --- 481,492 ---- maxsock); for (tmpint = maxsock; tmpint > 2; tmpint--) if (tmpint != ctrl) ! (void) close(tmpint); } ! if (sep->se_bi) { (*sep->se_bi->bi_fn)(ctrl, sep); ! /* NOTREACHED */ ! } else { if (debug) fprintf(stderr, "%d execl %s\n", getpid(), sep->se_server); *************** *** 497,522 **** sep->se_user); if (sep->se_socktype != SOCK_STREAM) recv(0, buf, sizeof (buf), 0); ! _exit(1); } if (setsid() < 0) { syslog(LOG_ERR, "%s: can't setsid(): %m", sep->se_service); ! /* _exit(1); not fatal yet */ } if (pwd->pw_uid) { if (setlogin(sep->se_user) < 0) { syslog(LOG_ERR, "%s: can't setlogin(%s): %m", sep->se_service, sep->se_user); ! /* _exit(1); not fatal yet */ } if (setgid(pwd->pw_gid) < 0) { syslog(LOG_ERR, "%s: can't set gid %d: %m", sep->se_service, pwd->pw_gid); ! _exit(1); } (void) initgroups(pwd->pw_name, pwd->pw_gid); --- 501,526 ---- sep->se_user); if (sep->se_socktype != SOCK_STREAM) recv(0, buf, sizeof (buf), 0); ! _exit(EX_NOUSER); } if (setsid() < 0) { syslog(LOG_ERR, "%s: can't setsid(): %m", sep->se_service); ! /* _exit(EX_OSERR); not fatal yet */ } if (pwd->pw_uid) { if (setlogin(sep->se_user) < 0) { syslog(LOG_ERR, "%s: can't setlogin(%s): %m", sep->se_service, sep->se_user); ! /* _exit(EX_OSERR); not yet */ } if (setgid(pwd->pw_gid) < 0) { syslog(LOG_ERR, "%s: can't set gid %d: %m", sep->se_service, pwd->pw_gid); ! _exit(EX_OSERR); } (void) initgroups(pwd->pw_name, pwd->pw_gid); *************** *** 524,530 **** syslog(LOG_ERR, "%s: can't set uid %d: %m", sep->se_service, pwd->pw_uid); ! _exit(1); } } execv(sep->se_server, sep->se_argv); --- 528,534 ---- syslog(LOG_ERR, "%s: can't set uid %d: %m", sep->se_service, pwd->pw_uid); ! _exit(EX_OSERR); } } execv(sep->se_server, sep->se_argv); *************** *** 532,551 **** recv(0, buf, sizeof (buf), 0); syslog(LOG_ERR, "cannot execute %s: %m", sep->se_server); ! _exit(1); } } ! if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) close(ctrl); } } } void reapchild(signo) int signo; { ! int status; pid_t pid; struct servtab *sep; --- 536,581 ---- recv(0, buf, sizeof (buf), 0); syslog(LOG_ERR, "cannot execute %s: %m", sep->se_server); ! _exit(EX_OSERR); } } ! if (sep->se_accept && sep->se_socktype == SOCK_STREAM) close(ctrl); } } } + /* + * Record a new child pid for this service. If we've reached the + * limit on children, then stop accepting incoming requests. + */ + + void + addchild(struct servtab *sep, pid_t pid) + { + #ifdef SANITY_CHECK + if (sep->se_numchild >= sep->se_maxchild) { + syslog(LOG_ERR, "%s: %d >= %d", + __FUNCTION__, sep->se_numchild, sep->se_maxchild); + exit(EX_SOFTWARE); + } + #endif + if (sep->se_maxchild == 0) + return; + sep->se_pids[sep->se_numchild++] = pid; + if (sep->se_numchild == sep->se_maxchild) + disable(sep); + } + + /* + * Some child process has exited. See if it's on somebody's list. + */ + void reapchild(signo) int signo; { ! int k, status; pid_t pid; struct servtab *sep; *************** *** 556,574 **** if (debug) fprintf(stderr, "%d reaped, status %#x\n", pid, status); ! for (sep = servtab; sep; sep = sep->se_next) ! if (sep->se_wait == pid) { ! if (status) ! syslog(LOG_WARNING, ! "%s: exit status 0x%x", ! sep->se_server, status); ! if (debug) ! fprintf(stderr, "restored %s, fd %d\n", ! sep->se_service, sep->se_fd); ! FD_SET(sep->se_fd, &allsock); ! nsock++; ! sep->se_wait = 1; ! } } } --- 586,606 ---- if (debug) fprintf(stderr, "%d reaped, status %#x\n", pid, status); ! for (sep = servtab; sep; sep = sep->se_next) { ! for (k = 0; k < sep->se_numchild; k++) ! if (sep->se_pids[k] == pid) ! break; ! if (k == sep->se_numchild) ! continue; ! if (sep->se_numchild == sep->se_maxchild) ! enable(sep); ! sep->se_pids[k] = sep->se_pids[--sep->se_numchild]; ! if (status) ! syslog(LOG_WARNING, ! "%s[%d]: exit status 0x%x", ! sep->se_server, pid, status); ! break; ! } } } *************** *** 576,582 **** config(signo) int signo; { ! struct servtab *sep, *cp, **sepp; struct passwd *pwd; long omask; --- 608,614 ---- config(signo) int signo; { ! struct servtab *sep, *new, **sepp; struct passwd *pwd; long omask; *************** *** 586,628 **** } for (sep = servtab; sep; sep = sep->se_next) sep->se_checked = 0; ! while (cp = getconfigent()) { ! if ((pwd = getpwnam(cp->se_user)) == NULL) { syslog(LOG_ERR, "%s/%s: No such user '%s', service ignored", ! cp->se_service, cp->se_proto, cp->se_user); continue; } for (sep = servtab; sep; sep = sep->se_next) ! if (strcmp(sep->se_service, cp->se_service) == 0 && ! strcmp(sep->se_proto, cp->se_proto) == 0) break; if (sep != 0) { int i; omask = sigblock(SIGBLOCK); ! /* ! * sep->se_wait may be holding the pid of a daemon ! * that we're waiting for. If so, don't overwrite ! * it unless the config file explicitly says don't ! * wait. ! */ ! if (cp->se_bi == 0 && ! (sep->se_wait == 1 || cp->se_wait == 0)) ! sep->se_wait = cp->se_wait; ! #define SWAP(a, b) { char *c = a; a = b; b = c; } ! if (cp->se_user) ! SWAP(sep->se_user, cp->se_user); ! if (cp->se_server) ! SWAP(sep->se_server, cp->se_server); for (i = 0; i < MAXARGV; i++) ! SWAP(sep->se_argv[i], cp->se_argv[i]); sigsetmask(omask); ! freeconfig(cp); if (debug) print_service("REDO", sep); } else { ! sep = enter(cp); if (debug) print_service("ADD ", sep); } --- 618,674 ---- } for (sep = servtab; sep; sep = sep->se_next) sep->se_checked = 0; ! while ((new = getconfigent())) { ! if ((pwd = getpwnam(new->se_user)) == NULL) { syslog(LOG_ERR, "%s/%s: No such user '%s', service ignored", ! new->se_service, new->se_proto, new->se_user); continue; } for (sep = servtab; sep; sep = sep->se_next) ! if (strcmp(sep->se_service, new->se_service) == 0 && ! strcmp(sep->se_proto, new->se_proto) == 0) break; if (sep != 0) { int i; + #define SWAP(a, b) { typeof(a) c = a; a = b; b = c; } omask = sigblock(SIGBLOCK); ! /* copy over outstanding child pids */ ! if (sep->se_maxchild && new->se_maxchild) { ! new->se_numchild = sep->se_numchild; ! if (new->se_numchild > new->se_maxchild) ! new->se_numchild = new->se_maxchild; ! memcpy(new->se_pids, sep->se_pids, ! new->se_numchild * sizeof(*new->se_pids)); ! } ! SWAP(sep->se_pids, new->se_pids); ! sep->se_maxchild = new->se_maxchild; ! sep->se_numchild = new->se_numchild; ! /* might need to turn on or off service now */ ! if (sep->se_fd >= 0) { ! if (sep->se_maxchild ! && sep->se_numchild == sep->se_maxchild) { ! if (FD_ISSET(sep->se_fd, &allsock)) ! disable(sep); ! } else { ! if (!FD_ISSET(sep->se_fd, &allsock)) ! enable(sep); ! } ! } ! sep->se_accept = new->se_accept; ! if (new->se_user) ! SWAP(sep->se_user, new->se_user); ! if (new->se_server) ! SWAP(sep->se_server, new->se_server); for (i = 0; i < MAXARGV; i++) ! SWAP(sep->se_argv[i], new->se_argv[i]); sigsetmask(omask); ! freeconfig(new); if (debug) print_service("REDO", sep); } else { ! sep = enter(new); if (debug) print_service("ADD ", sep); } *************** *** 673,679 **** */ omask = sigblock(SIGBLOCK); sepp = &servtab; ! while (sep = *sepp) { if (sep->se_checked) { sepp = &sep->se_next; continue; --- 719,725 ---- */ omask = sigblock(SIGBLOCK); sepp = &servtab; ! while ((sep = *sepp)) { if (sep->se_checked) { sepp = &sep->se_next; continue; *************** *** 727,733 **** timingout = 0; for (sep = servtab; sep; sep = sep->se_next) ! if (sep->se_fd == -1) setup(sep); } --- 773,779 ---- timingout = 0; for (sep = servtab; sep; sep = sep->se_next) ! if (sep->se_fd == -1 && !ISMUX(sep)) setup(sep); } *************** *** 796,805 **** } if (sep->se_socktype == SOCK_STREAM) listen(sep->se_fd, 64); ! FD_SET(sep->se_fd, &allsock); ! nsock++; ! if (sep->se_fd > maxsock) ! maxsock = sep->se_fd; if (debug) { fprintf(stderr, "registered %s on %d\n", sep->se_server, sep->se_fd); --- 842,848 ---- } if (sep->se_socktype == SOCK_STREAM) listen(sep->se_fd, 64); ! enable(sep); if (debug) { fprintf(stderr, "registered %s on %d\n", sep->se_server, sep->se_fd); *************** *** 814,831 **** struct servtab *sep; { if (sep->se_fd >= 0) { ! nsock--; ! FD_CLR(sep->se_fd, &allsock); (void) close(sep->se_fd); sep->se_fd = -1; } sep->se_count = 0; ! /* ! * Don't keep the pid of this running deamon: when reapchild() ! * reaps this pid, it would erroneously increment nsock. ! */ ! if (sep->se_wait > 1) ! sep->se_wait = 1; } struct servtab * --- 857,869 ---- struct servtab *sep; { if (sep->se_fd >= 0) { ! if (FD_ISSET(sep->se_fd, &allsock)) ! disable(sep); (void) close(sep->se_fd); sep->se_fd = -1; } sep->se_count = 0; ! sep->se_numchild = 0; /* forget about any existing children */ } struct servtab * *************** *** 838,844 **** sep = (struct servtab *)malloc(sizeof (*sep)); if (sep == (struct servtab *)0) { syslog(LOG_ERR, "Out of memory."); ! exit(-1); } *sep = *cp; sep->se_fd = -1; --- 876,882 ---- sep = (struct servtab *)malloc(sizeof (*sep)); if (sep == (struct servtab *)0) { syslog(LOG_ERR, "Out of memory."); ! exit(EX_OSERR); } *sep = *cp; sep->se_fd = -1; *************** *** 849,854 **** --- 887,954 ---- return (sep); } + void + enable(struct servtab *sep) + { + if (debug) + fprintf(stderr, + "enabling %s, fd %d", sep->se_service, sep->se_fd); + #ifdef SANITY_CHECK + if (sep->se_fd < 0) { + syslog(LOG_ERR, + "%s: %s: bad fd", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (ISMUX(sep)) { + syslog(LOG_ERR, + "%s: %s: is mux", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (FD_ISSET(sep->se_fd, &allsock)) { + syslog(LOG_ERR, + "%s: %s: not off", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + #endif + FD_SET(sep->se_fd, &allsock); + nsock++; + if (sep->se_fd > maxsock) + maxsock = sep->se_fd; + } + + void + disable(struct servtab *sep) + { + if (debug) + fprintf(stderr, + "disabling %s, fd %d", sep->se_service, sep->se_fd); + #ifdef SANITY_CHECK + if (sep->se_fd < 0) { + syslog(LOG_ERR, + "%s: %s: bad fd", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (ISMUX(sep)) { + syslog(LOG_ERR, + "%s: %s: is mux", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (!FD_ISSET(sep->se_fd, &allsock)) { + syslog(LOG_ERR, + "%s: %s: not on", __FUNCTION__, sep->se_service); + exit(EX_SOFTWARE); + } + if (nsock == 0) { + syslog(LOG_ERR, "%s: nsock=0", __FUNCTION__); + exit(EX_SOFTWARE); + } + #endif + FD_CLR(sep->se_fd, &allsock); + nsock--; + if (sep->se_fd == maxsock) + maxsock--; + } + FILE *fconfig = NULL; struct servtab serv; char line[LINE_MAX]; *************** *** 879,885 **** { struct servtab *sep = &serv; int argc; ! char *cp, *arg; char *versp; static char TCPMUX_TOKEN[] = "tcpmux/"; #define MUX_LEN (sizeof(TCPMUX_TOKEN)-1) --- 979,985 ---- { struct servtab *sep = &serv; int argc; ! char *cp, *arg, *s; char *versp; static char TCPMUX_TOKEN[] = "tcpmux/"; #define MUX_LEN (sizeof(TCPMUX_TOKEN)-1) *************** *** 959,972 **** } } arg = sskip(&cp); ! sep->se_wait = strcmp(arg, "wait") == 0; if (ISMUX(sep)) { /* ! * Silently enforce "nowait" for TCPMUX services since ! * they don't have an assigned port to listen on. */ ! sep->se_wait = 0; ! if (strcmp(sep->se_proto, "tcp")) { syslog(LOG_ERR, "%s: bad protocol for tcpmux service %s", --- 1059,1094 ---- } } arg = sskip(&cp); ! if (!strncmp(arg, "wait", 4)) ! sep->se_accept = 0; ! else if (!strncmp(arg, "nowait", 6)) ! sep->se_accept = 1; ! else { ! syslog(LOG_ERR, ! "%s: bad wait/nowait for service %s", ! CONFIG, sep->se_service); ! goto more; ! } ! sep->se_maxchild = -1; ! if ((s = strchr(arg, '/')) != NULL) { ! char *eptr; ! u_long val; ! ! val = strtoul(s + 1, &eptr, 10); ! if (eptr == s + 1 || *eptr || val > MAX_MAXCHLD) { ! syslog(LOG_ERR, ! "%s: bad max-child for service %s", ! CONFIG, sep->se_service); ! goto more; ! } ! sep->se_maxchild = val; ! } if (ISMUX(sep)) { /* ! * Silently enforce "nowait" mode for TCPMUX services ! * since they don't have an assigned port to listen on. */ ! sep->se_accept = 1; if (strcmp(sep->se_proto, "tcp")) { syslog(LOG_ERR, "%s: bad protocol for tcpmux service %s", *************** *** 994,1007 **** sep->se_service); goto more; } sep->se_bi = bi; - sep->se_wait = bi->bi_wait; } else sep->se_bi = NULL; argc = 0; for (arg = skip(&cp); cp; arg = skip(&cp)) ! if (argc < MAXARGV) sep->se_argv[argc++] = newstr(arg); while (argc <= MAXARGV) sep->se_argv[argc++] = NULL; return (sep); --- 1116,1147 ---- sep->se_service); goto more; } + sep->se_accept = 1; /* force accept mode for built-ins */ sep->se_bi = bi; } else sep->se_bi = NULL; + if (sep->se_maxchild < 0) /* apply default max-children */ + if (sep->se_bi) + sep->se_maxchild = sep->se_bi->bi_maxchild; + else + sep->se_maxchild = sep->se_accept ? 0 : 1; + if (sep->se_maxchild) { + sep->se_pids = malloc(sep->se_maxchild * sizeof(*sep->se_pids)); + if (sep->se_pids == NULL) { + syslog(LOG_ERR, "Out of memory."); + exit(EX_OSERR); + } + } argc = 0; for (arg = skip(&cp); cp; arg = skip(&cp)) ! if (argc < MAXARGV) { sep->se_argv[argc++] = newstr(arg); + } else { + syslog(LOG_ERR, + "%s: too many arguments for service %s", + CONFIG, sep->se_service); + goto more; + } while (argc <= MAXARGV) sep->se_argv[argc++] = NULL; return (sep); *************** *** 1021,1026 **** --- 1161,1168 ---- free(cp->se_user); if (cp->se_server) free(cp->se_server); + if (cp->se_pids) + free(cp->se_pids); for (i = 0; i < MAXARGV; i++) if (cp->se_argv[i]) free(cp->se_argv[i]); *************** *** 1040,1046 **** cp = skip(cpp); if (cp == NULL) { syslog(LOG_ERR, "%s: syntax error", CONFIG); ! exit(-1); } return (cp); } --- 1182,1188 ---- cp = skip(cpp); if (cp == NULL) { syslog(LOG_ERR, "%s: syntax error", CONFIG); ! exit(EX_DATAERR); } return (cp); } *************** *** 1062,1068 **** c = getc(fconfig); (void) ungetc(c, fconfig); if (c == ' ' || c == '\t') ! if (cp = nextline(fconfig)) goto again; *cpp = (char *)0; return ((char *)0); --- 1204,1210 ---- c = getc(fconfig); (void) ungetc(c, fconfig); if (c == ' ' || c == '\t') ! if ((cp = nextline(fconfig))) goto again; *cpp = (char *)0; return ((char *)0); *************** *** 1100,1109 **** newstr(cp) char *cp; { ! if (cp = strdup(cp ? cp : "")) return (cp); syslog(LOG_ERR, "strdup: %m"); ! exit(-1); } #ifdef OLD_SETPROCTITLE --- 1242,1251 ---- newstr(cp) char *cp; { ! if ((cp = strdup(cp ? cp : ""))) return (cp); syslog(LOG_ERR, "strdup: %m"); ! exit(EX_OSERR); } #ifdef OLD_SETPROCTITLE *************** *** 1439,1456 **** char *action; struct servtab *sep; { ! if(sep->se_rpc) ! fprintf(stderr, ! "%s: %s proto=%s, wait=%d, user=%s builtin=%x server=%s\n", ! action, sep->se_service, sep->se_proto, ! sep->se_wait, sep->se_user, (int)sep->se_bi, ! sep->se_server); ! else ! fprintf(stderr, ! "%s: %s proto=%s, wait=%d, user=%s builtin=%x server=%s\n", ! action, sep->se_service, sep->se_proto, ! sep->se_wait, sep->se_user, (int)sep->se_bi, ! sep->se_server); } /* --- 1581,1591 ---- char *action; struct servtab *sep; { ! fprintf(stderr, ! "%s: %s proto=%s accept=%d max=%d user=%s builtin=%x server=%s\n", ! action, sep->se_service, sep->se_proto, ! sep->se_accept, sep->se_maxchild, sep->se_user, ! (int)sep->se_bi, sep->se_server); } /* --------------2F1CF0FB237C228A31DFF4F5-- From owner-freebsd-hackers Wed Nov 6 12:20:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA22300 for hackers-outgoing; Wed, 6 Nov 1996 12:20:17 -0800 (PST) Received: from picasso.wcape.school.za (picasso.wcape.school.za [196.21.102.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA22288 for ; Wed, 6 Nov 1996 12:20:13 -0800 (PST) Received: by picasso.wcape.school.za via rmail with stdio id for freebsd-hackers@FreeBSD.org; Wed, 6 Nov 1996 22:19:28 +0200 (SAT) (Smail-3.2 1996-Jul-4 #1 built 1996-Oct-15) Received: from leftside.wcape.school.za (localhost [127.0.0.1]) by leftside.wcape.school.za (8.7.5/8.7.3) with SMTP id WAA01041; Wed, 6 Nov 1996 22:02:13 +0200 (SAT) Date: Wed, 6 Nov 1996 22:02:10 +0200 (SAT) From: Peter van Heusden To: Amancio Hasty cc: Michael Smith , freebsd-hackers@FreeBSD.org Subject: Re: Probe failing on SoundBlaster component of Phoneblasterd In-Reply-To: <199611041127.DAA00705@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, 4 Nov 1996, Amancio Hasty wrote: > His problem most likely is that his card is not configured properly. > > Curious, what does the PnP code in the kernel prints out at boot time? > > Amancio > Hm, this sounds correct, since I looked at my test code again and found a bug. Now the DSP_READ also returns 0xff - i.e. nothing there. The PnP init seems to go fine. Quoting dmesg: Checking for Plug-n-Play devices... Board Vendor ID: CTL3002 Board Serial Number: 00000adb Configuring (Logical Device 0) Configuring (Logical Device 4) Logical Device 0 is the sound card, logical dev. 4 is the modem. (Output from pnpinfo starts with: Checking for Plug-n-Play devices... Trying Read_Port at 203 Card assigned CSN #1 Board Vendor ID: CTL3002 Board Serial Number: 00000adb PnP Version: 1.0 Vendor Version: 16 Device Description: Creative Phone Blaster 28.8 Logical Device ID: CTL0031 (31008c0e) Device Description: Audio Start Dependent Function Good Configuration .... which make me think that Audio (i.e. Soundblaster) is logical dev. 0) Configuration for the logical device 0 in pnp.c reads /* Configuration for the PhoneBlaster PnP Audio */ { 0x00000adb, /* Serial Number */ 0, /* Logical Device Number */ { { 10, -1 }, /* Primary IRQ Number, Type */ { -1, -1 } /* Second IRQ Number, Type */ }, { 1, 5 }, /* DRQ Number */ { 0x220, /* Ports 1 */ 0x330, /* Ports 2 */ 0x388, /* Ports 3 */ -1, /* Ports 4 */ -1, /* Ports 5 */ -1, /* Ports 6 */ -1, /* Ports 7 */ -1, /* Ports 8 */ }, { { -1, -1, -1 }, /* Memory desc0 - base, ctrl, range */ { -1, -1, -1 }, /* Memory desc1 - base, ctrl, range */ { -1, -1, -1 }, /* Memory desc2 - base, ctrl, range */ { -1, -1, -1 } /* Memory desc3 - base, ctrl, range */ } }, Does anyone see a bug with this configuration? I'm going to try and debug the PnP stuff anyway, but if someone can spot a glaring mistake, I'd really appreciate some advice. Thanks, Peter -- Peter van Heusden | Computers Networks Greens Justice Peace Beer Africa pvh@leftside.wcape.school.za pvh@gem.co.za From owner-freebsd-hackers Wed Nov 6 12:31:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA23129 for hackers-outgoing; Wed, 6 Nov 1996 12:31:35 -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 MAA23109; Wed, 6 Nov 1996 12:31:29 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id MAA11245; Wed, 6 Nov 1996 12:31:27 -0800 (PST) Message-Id: <199611062031.MAA11245@austin.polstra.com> To: sos@FreeBSD.org cc: gene@starkhome.cs.sunysb.edu, hackers@FreeBSD.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 20:29:52 +0100." <199611061929.UAA02640@ravenock.cybercity.dk> References: <199611061929.UAA02640@ravenock.cybercity.dk> Date: Wed, 06 Nov 1996 12:31:26 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Erhm, why on earth did you chose Modula3 ?? I newer got the warm > fuzzies by mr. Wirth's languages Modula-3 came out of DEC's Systems Research Center, and as far as I know, Wirth had nothing to do with it. > they are maybe good educational tools, but for real world apps, > nah.... :) I've used the original Wirth Pascal and Algol-W, and that's certainly true of both of them. I've never used Wirth's Modula, so I can't comment on it. Modula-3 really is a different language, designed specifically for systems programming by some extremely competent and experienced people who knew what they were doing. > Oh and yes I have seen apps written in modula3, all of which was > horrible performers, and impossible to port to new platforms, so > the management decide a complete rewrite in, guess what, C! Are you sure it was Modula-3 and not something else with "Modula" in the name? The SRC Modula-3 compiler supports about 25 different platforms. (See "http://www.research.digital.com/SRC/modula-3/html/platforms.html".) Plenty of real world apps (*big* ones) have been written in Modula-3, and they perform pretty well. There's also the SPIN OS project at University of Washington, in which the kernel was written in Modula-3. It performs well, too. (See "http://www.cs.washington.edu/research/projects/spin/www/".) Now, you can always argue that a program would be somewhat faster and somewhat smaller if it had been written in C. Hey, guess what? I was around when Unix V6 came out, and the same stuff was written about it. Just substitute "C" for "Modula-3" and "assembly language" for "C". The answer is the same in both cases: Unix would not exist as we know it today if it had been written in assembly language. CVSup would not exist as we know it today if it had been written in C (or C++, for that matter). OK, so why on earth did I choose Modula-3? In no particular order: 1. I needed application level threads, and threads are an integral part of the Modula-3 language. About the only reasonable alternative was to use pthreads with C or C++. But pthreads was not well supported under FreeBSD at that time. 2. I needed a graphical display during development so that I could monitor the 3 client threads as they were running, debug them, appraise their relative performance, and find the bottlenecks. Modula-3 has a very nice toolkit for creating GUIs quickly and painlessly. (OK, so the scrollbars are as ugly as sin.) 3. Modula-3 is a compiled language that is reasonably efficient. 4. I needed to use some low level system functions, e.g., mapping files into memory. Modula-3 provides good access to such functions, and it is quite easy to add interfaces to foreign libraries such as "libz". 5. Modula-3 has good support for networking. 6. It is a mature and stable language that has been used in a number of serious, large projects. The language and compiler have been stable for about 5 years, which is more than you can say for C++. 7. It has nice support for object oriented programming, including a good type system, a nice exception model, and a modern high-performance garbage collector. These traits, IMHO, contribute powerfully to producing well-structured, maintainable programs. Now before you label me an unstudly OO weenie, please consider this. I've been programming in C professionally for 19 years. I made my living for many years writing C compilers and related tools such as assemblers, linkers, and disassemblers. I still use C and C++ when I feel they are appropriate for a project, not to mention when I have to because that's what the client wants to use. I have experience programming in many many different languages. Different languages are good for different things. I still like programming in C (and C++ for some things), but I'm glad I didn't use it for CVSup. 8. I had just come off a huge 3+ year C++ project. During that time, I learned just how much C++ sucks. I did not feel like doing it again right away "for fun." 9. I have spent my entire professional career getting paid to use the wrong tools, because, e.g., the manager read that C++ was "popular." For once, just once, on a _hobby_ project, I decided I was going to use the tool I felt was the best for the job at hand. I thought about it long and hard, evaluated several options (C and C++ among them), and eventually chose Modula-3. I have never regretted that decision. Any questions? :-) 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 Wed Nov 6 12:39:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA23653 for hackers-outgoing; Wed, 6 Nov 1996 12:39: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 MAA23647; Wed, 6 Nov 1996 12:39:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08732; Wed, 6 Nov 1996 13:31:20 -0700 From: Terry Lambert Message-Id: <199611062031.NAA08732@phaeton.artisoft.com> Subject: Re: Davidg bug (was: mount panics & hangs) To: julian@whistle.com (Julian Elischer) Date: Wed, 6 Nov 1996 13:31:19 -0700 (MST) Cc: terry@lambert.org, archie@whistle.com, freebsd-hackers@FreeBSD.org, davidg@FreeBSD.org In-Reply-To: <3280E3BC.15FB7483@whistle.com> from "Julian Elischer" at Nov 6, 96 11:15:08 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 you want I can try work a patch and send it to you > for comments. (though I don't yet understand why there needs to be > both vfs_busy and vfs_lock) Lock for drain (no additional entry is allowed, current users should exit), lock for object destruction (all current users must have exited). The idea is that there might be some latent operations that haven't completed, and you want to let them complete before you do your thing, but you want to make sure no new operations start after you decide to do your thing but before you can safely do it. 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 6 12:47:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24208 for hackers-outgoing; Wed, 6 Nov 1996 12:47:20 -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 MAA24194 for ; Wed, 6 Nov 1996 12:47:15 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA12018; Wed, 6 Nov 1996 12:46:40 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma012014; Wed Nov 6 12:46:15 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id MAA08387; Wed, 6 Nov 1996 12:46:15 -0800 (PST) From: Archie Cobbs Message-Id: <199611062046.MAA08387@bubba.whistle.com> Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) In-Reply-To: <199611061411.IAA08311@brasil.moneng.mei.com> from Joe Greco at "Nov 6, 96 08:11:58 am" To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Wed, 6 Nov 1996 12:46:15 -0800 (PST) Cc: hannibal@cyberstation.net, 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'm trying to come up with some way to limit the amount of bandwidth on a > > socket, so I can have my mail and large files retrieve without slowing > > down a telnet session that much. > > > > [ ... ] > > > > Anyone know how to do this? > > int s, rval; > > s = socket(...); > > while ((rval = read(..., 1024)) > 0) { > sleep(1); > } > > if (rval < 0) { > perror(...); > } This also might be a good application for divert(4) sockets .. just stick in a daemon that throttles the I/O on whatever connections you want to throttle... basically, doing the same as above except your exiting applications don't have to be modified. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Wed Nov 6 13:16:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA26337 for hackers-outgoing; Wed, 6 Nov 1996 13:16:14 -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 NAA26325 for ; Wed, 6 Nov 1996 13:16:10 -0800 (PST) Received: from uucp.DK.net (uucp@uucp.DK.net [193.88.44.47]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id NAA14275 for ; Wed, 6 Nov 1996 13:15:43 -0800 (PST) Received: from pingnet (uucp@localhost) by uucp.DK.net (8.6.12/8.6.12) with UUCP id WAA26773; Wed, 6 Nov 1996 22:13:21 +0100 Received: from kyklopen by ic1.ic.dk with UUCP id AA07807 (5.65c8/IDA-1.4.4j); Wed, 6 Nov 1996 22:09:02 +0100 Received: (from staff@localhost) by kyklopen.ping.dk (8.8.2/8.7.3) id WAA03132; Wed, 6 Nov 1996 22:02:25 +0100 (MET) Date: Wed, 6 Nov 1996 22:02:25 +0100 (MET) From: Thomas Sparrevohn X-Sender: staff@kyklopen To: dennis Cc: Luigi Rizzo , hackers@freebsd.org Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) In-Reply-To: <199611061826.NAA22804@etinc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 6 Nov 1996, dennis wrote: > > They're not real...Linux has what they call a "shaper", but its almost totally > bogus. Calling anything that you are talking about a "bandwidth limiter" is > inaccurate anyway.......its really a throughput limiter....the bandwidth is > always the same.... > > Not if we are talking ATM. It would actually be nice QoS and traffic descriptors for a specific socket. Regards Thomas From owner-freebsd-hackers Wed Nov 6 13:26:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA26881 for hackers-outgoing; Wed, 6 Nov 1996 13:26:32 -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 NAA26875 for ; Wed, 6 Nov 1996 13:26:28 -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 NAA11085; Wed, 6 Nov 1996 13:25:01 -0800 (PST) Message-Id: <199611062125.NAA11085@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs cc: jgreco@brasil.moneng.mei.com (Joe Greco), hannibal@cyberstation.net, hackers@freebsd.org Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) In-reply-to: Your message of "Wed, 06 Nov 1996 12:46:15 PST." <199611062046.MAA08387@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 13:25:00 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What about kernel modifications? In a commercial environment it can be very beneficial to provide rate control. QOS --- that ugly old OSI term or more recently reservation bandwith services. Amancio >From The Desk Of Archie Cobbs : > > > > I'm trying to come up with some way to limit the amount of bandwidth on a > > > socket, so I can have my mail and large files retrieve without slowing > > > down a telnet session that much. > > > > > > [ ... ] > > > > > > Anyone know how to do this? > > > > int s, rval; > > > > s = socket(...); > > > > while ((rval = read(..., 1024)) > 0) { > > sleep(1); > > } > > > > if (rval < 0) { > > perror(...); > > } > > This also might be a good application for divert(4) sockets .. just > stick in a daemon that throttles the I/O on whatever connections you > want to throttle... basically, doing the same as above except your > exiting applications don't have to be modified. > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > From owner-freebsd-hackers Wed Nov 6 14:09:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA29629 for hackers-outgoing; Wed, 6 Nov 1996 14:09:53 -0800 (PST) Received: from ravenock.cybercity.dk (disn50.cybercity.dk [194.16.57.50]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA29603; Wed, 6 Nov 1996 14:09:43 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.2/8.7.3) id XAA02882; Wed, 6 Nov 1996 23:09:49 +0100 (MET) Message-Id: <199611062209.XAA02882@ravenock.cybercity.dk> Subject: Re: SUP on sup.freebsd.org To: jdp@polstra.com (John Polstra) Date: Wed, 6 Nov 1996 23:09:37 +0100 (MET) From: "Soren Schmidt" Cc: sos@FreeBSD.org, gene@starkhome.cs.sunysb.edu, hackers@FreeBSD.org In-Reply-To: <199611062031.MAA11245@austin.polstra.com> from "John Polstra" at Nov 6, 96 12:31:26 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 John Polstra who wrote: > > OK, so why on earth did I choose Modula-3? In no particular order: > > 1. I needed application level threads, and threads are an integral > part of the Modula-3 language. About the only reasonable alternative > was to use pthreads with C or C++. But pthreads was not well > supported under FreeBSD at that time. Hmm. > 2. I needed a graphical display during development so that I could > monitor the 3 client threads as they were running, debug them, > appraise their relative performance, and find the bottlenecks. > Modula-3 has a very nice toolkit for creating GUIs quickly and > painlessly. (OK, so the scrollbars are as ugly as sin.) Hmm, xforms? tcl/tk? > 3. Modula-3 is a compiled language that is reasonably efficient. Hmm, C? > 4. I needed to use some low level system functions, e.g., mapping > files into memory. Modula-3 provides good access to such functions, > and it is quite easy to add interfaces to foreign libraries such > as "libz". Hmm, mmap? > 5. Modula-3 has good support for networking. Hmm, sockets? > 6. It is a mature and stable language that has been used in a number > of serious, large projects. The language and compiler have been > stable for about 5 years, which is more than you can say for C++. Hmm, C has been here for a _long_ time too... > 7. It has nice support for object oriented programming, including a good > type system, a nice exception model, and a modern high-performance > garbage collector. These traits, IMHO, contribute powerfully to > producing well-structured, maintainable programs. Aiiigh... > 8. I had just come off a huge 3+ year C++ project. During that time, I > learned just how much C++ sucks. I did not feel like doing it again > right away "for fun." I wouldn't use C++ either, agreed on that one.. > 9. I have spent my entire professional career getting paid to use the > wrong tools, because, e.g., the manager read that C++ was "popular." > For once, just once, on a _hobby_ project, I decided I was going to use > the tool I felt was the best for the job at hand. I thought about it > long and hard, evaluated several options (C and C++ among them), and > eventually chose Modula-3. I have never regretted that decision. Ahh, thats it, change of environment, I'll buy that one. > Any questions? :-) Well, it won't matter won't it ? :) I'm just getting a litte nervous about all the splendid new stuff that we are collecting lately. One of the reasons I _love_ **IX and BSD is that they have stayed on the KISS principle for so long. As I se our route forward we are rapidly moving away from that philosofi, and I think that is a shame. If I want big and overengineered systems I get plenty at work form using Billyboys systems there (allthough we are a UNIX shop :( ) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 6 14:18:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA01006 for hackers-outgoing; Wed, 6 Nov 1996 14:18:58 -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 OAA00990 for ; Wed, 6 Nov 1996 14:18:47 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id JAA07445; Thu, 7 Nov 1996 09:18:02 +1100 (EST) Date: Thu, 7 Nov 1996 09:17:57 +1100 (EST) From: "Daniel O'Callaghan" To: "Jordan K. Hubbard" cc: hackers@FreeBSD.org Subject: Re: port 106 in /etc/services In-Reply-To: <199611061640.IAA22367@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, 6 Nov 1996, Jordan K. Hubbard wrote: > Has Qualcom really taken over port 106 for poppassd? 3COM gave it > up fair and square? :-) > > If so, maybe we want to update our default services and inetd.conf > files, so that the poppassd port is a drop-in. Eudora has been using it since 1993. Perhaps poppass can be added as a synonym for 3com-tsmux. Danny From owner-freebsd-hackers Wed Nov 6 14:24:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA01606 for hackers-outgoing; Wed, 6 Nov 1996 14:24: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 OAA01595; Wed, 6 Nov 1996 14:24:04 -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 OAA24352; Wed, 6 Nov 1996 14:24:03 -0800 (PST) To: sos@FreeBSD.org cc: jdp@polstra.com (John Polstra), gene@starkhome.cs.sunysb.edu, hackers@FreeBSD.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 23:09:37 +0100." <199611062209.XAA02882@ravenock.cybercity.dk> Date: Wed, 06 Nov 1996 14:24:03 -0800 Message-ID: <24350.847319043@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I'm just getting a litte nervous about all the splendid new stuff > that we are collecting lately. One of the reasons I _love_ **IX I think as long as you keep it clear in your head where **IX stops and the application space starts, after which you've got everything from CDE to WordPerfect for SCO, beside which cvsup is a guppy by comparison, it's no big deal. So we use cvsup as the syncronization tool of choice, no problem, that just makes it an application handier which is handier than most, just like PowerPoint (almost my entire reason to run Win95, when I run it at all) or Quicken might be to a Win95 user :-) Jordan From owner-freebsd-hackers Wed Nov 6 14:36:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03147 for hackers-outgoing; Wed, 6 Nov 1996 14:36:01 -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 OAA03134; Wed, 6 Nov 1996 14:35:57 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id OAA12182; Wed, 6 Nov 1996 14:35:54 -0800 (PST) Message-Id: <199611062235.OAA12182@austin.polstra.com> To: sos@FreeBSD.org cc: hackers@FreeBSD.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 23:09:37 +0100." <199611062209.XAA02882@ravenock.cybercity.dk> Date: Wed, 06 Nov 1996 14:35:54 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I'm just getting a litte nervous about all the splendid new stuff > that we are collecting lately. One of the reasons I _love_ **IX > and BSD is that they have stayed on the KISS principle for so long. > As I se our route forward we are rapidly moving away from that > philosofi, and I think that is a shame. If I want big and overengineered > systems I get plenty at work form using Billyboys systems there > (allthough we are a UNIX shop :( ) An amusing anecdote: I remember sitting around over lunch one day with a small group of guys, all of them smart, modern fellows and capable programmers. This was around 1979 or 1980. We spent the entire lunch debating, heatedly and in all seriousness, the following proposition: Any software task that is worth doing can be done reasonably on a split I/D PDP-11. (That's 64K each of code and data, for those of you who don't remember.) The arguments stay the same, only the numbers change. :-) John From owner-freebsd-hackers Wed Nov 6 14:37:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03357 for hackers-outgoing; Wed, 6 Nov 1996 14:37:26 -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 OAA03350 for ; Wed, 6 Nov 1996 14:37:23 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id QAA10284; Wed, 6 Nov 1996 16:36:48 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma010259; Wed Nov 6 16:36:22 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 QAA00993; Wed, 6 Nov 1996 16:36:31 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.7.6/8.6.12) with ESMTP id QAA08354; Wed, 6 Nov 1996 16:36:43 -0600 (CST) Message-Id: <199611062236.QAA08354@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: John Polstra cc: hackers@freebsd.org Subject: Re: SUP on sup.freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 16:36:42 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk howdy John, I'm having a bit of trouble getting the socks version to work. I've built all ports/packages/etc. It times out on the `Establishing SOCKS-mode data connection' do you have any small little debugging tools for nailing this down, like a telnet or ftp? (ttyp1@jake)$ m3socks cvsup -gL2 cvs-supfile.cvsup Parsing supfile "cvs-supfile.cvsup" Looking up address of sup.FreeBSD.org Connecting to sup.FreeBSD.org Connected to sup.FreeBSD.org Exchanging collection information Establishing SOCKS-mode data connection Timed out waiting for connection from server Will retry at 16:36:12 [... more of the same follows ...] same if I point to sup3.freebsd.org. thanks, eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Wed Nov 6 14:45:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04036 for hackers-outgoing; Wed, 6 Nov 1996 14:45:21 -0800 (PST) Received: from sumter.awod.com (awod.com [198.81.225.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA04031 for ; Wed, 6 Nov 1996 14:45:18 -0800 (PST) Received: from tsunami..awod.com (chs0094.awod.com [198.81.225.93]) by sumter.awod.com (8.7.6/8.6.12) with SMTP id RAA12450; Wed, 6 Nov 1996 17:45:10 -0500 (EST) Message-Id: <3.0.32.19961106173443.0074b1a8@awod.com> X-Sender: klam@awod.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 06 Nov 1996 17:45:11 -0500 To: Dan Walters , hackers@freebsd.org From: Ken Lam Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:51 PM 11/5/96 -0600, Dan Walters wrote: >I'm trying to come up with some way to limit the amount of bandwidth on a >socket, so I can have my mail and large files retrieve without slowing >down a telnet session that much. > >I thought I could do this by setting SO_RCVBUF to a small value, but it >doesn't seem to change the window size at all when I look at it with >tcpdump. You need to limit both SNDBUF and RCVBUF since your background xfers are also pushing outgoing :) Perchance that you might drop the buffers to less than the MTU, then you only wait for one background packet ahead of your outbound . Making the buffer even smaller would lessen the wait even further, but would degrade background performance, but decrease latency. Alas, you could always upgrade to ISDN :) -ken --- Ken Lam lam@awod.com Integrated Technical Systems Systems, Networks, and Internet Solutions -- Defining Technology Today "'Plug and Play' was only applicable to the original ATARI(tm)" From owner-freebsd-hackers Wed Nov 6 14:46:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04138 for hackers-outgoing; Wed, 6 Nov 1996 14:46:32 -0800 (PST) Received: from uucp.DK.net (uucp@uucp.DK.net [193.88.44.47]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA04119 for ; Wed, 6 Nov 1996 14:46:24 -0800 (PST) Received: from pingnet (uucp@localhost) by uucp.DK.net (8.6.12/8.6.12) with UUCP id XAA02507; Wed, 6 Nov 1996 23:46:21 +0100 Received: from kyklopen by ic1.ic.dk with UUCP id AA11890 (5.65c8/IDA-1.4.4j); Wed, 6 Nov 1996 23:42:46 +0100 Received: (from staff@localhost) by kyklopen.ping.dk (8.8.2/8.7.3) id XAA03922; Wed, 6 Nov 1996 23:41:55 +0100 (MET) Date: Wed, 6 Nov 1996 23:41:55 +0100 (MET) From: Thomas Sparrevohn X-Sender: staff@kyklopen To: dennis , Luigi Rizzo , hackers@FreeBSD.org Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Charset: ISO_8859-1 X-Char-Esc: 29 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 6 Nov 1996, Thomas Sparrevohn wrote: > > Not if we are talking ATM. It would actually be nice QoS and > traffic descriptors for a specific socket. > Ups a bit to fast 8-) That should be it would be nice to be able to specify QoS and Traffic Profiles for a specific socket. > Regards > Thomas > > From owner-freebsd-hackers Wed Nov 6 14:47:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04258 for hackers-outgoing; Wed, 6 Nov 1996 14:47:38 -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 OAA04248 for ; Wed, 6 Nov 1996 14:47:35 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id OAA12257; Wed, 6 Nov 1996 14:47:23 -0800 (PST) Message-Id: <199611062247.OAA12257@austin.polstra.com> To: "Eric L. Hernes" cc: hackers@freebsd.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 16:36:42 CST." <199611062236.QAA08354@jake.lodgenet.com> References: <199611062236.QAA08354@jake.lodgenet.com> Date: Wed, 06 Nov 1996 14:47:23 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm having a bit of trouble getting the socks version to work. > I've built all ports/packages/etc. It times out on the > `Establishing SOCKS-mode data connection' > do you have any small little debugging tools > for nailing this down, like a telnet or ftp? > > (ttyp1@jake)$ m3socks cvsup -gL2 cvs-supfile.cvsup > Parsing supfile "cvs-supfile.cvsup" > Looking up address of sup.FreeBSD.org > Connecting to sup.FreeBSD.org > Connected to sup.FreeBSD.org > Exchanging collection information > Establishing SOCKS-mode data connection > Timed out waiting for connection from server I checked the server logs, and here's what I found: 1996.11.06 14:25:11 PST [1821.60]: Connection from bacall.lodgenet.com 1996.11.06 14:25:12 PST [1821.60]: User erich 1996.11.06 14:26:27 PST [1821.60]: Connect failed: Connection refused Your SOCKS server is rejecting the connections back from the server to the client. This is controlled by the people who administer your SOCKS server configuration. I have an idea or two which I'll discuss further with you in a separate mail off the hackers list. 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 Wed Nov 6 14:53:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA05017 for hackers-outgoing; Wed, 6 Nov 1996 14:53:44 -0800 (PST) Received: from ravenock.cybercity.dk (disn38.cybercity.dk [194.16.57.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA04978 for ; Wed, 6 Nov 1996 14:53:34 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.2/8.7.3) id XAA02949 for hackers@freebsd.org; Wed, 6 Nov 1996 23:53:50 +0100 (MET) Message-Id: <199611062253.XAA02949@ravenock.cybercity.dk> Subject: INSITE floptical anybody ??? To: hackers@freebsd.org (FreeBSD hackers) Date: Wed, 6 Nov 1996 23:53:39 +0100 (MET) From: "Soren Schmidt" 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 I just had one of those drop on my table so I hooked it up to the SCSI system, and well, its found but then it hangs the SCSI subsystem. I glanced through some other systems scsi files, and saw that the INSITE floptical needs some kind of "unlock" sequence in order to work proberly, anybody allready done the nessesary magic ?? or will I have to get my fingers dirty in the SCSI code too... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Nov 6 15:32:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA07268 for hackers-outgoing; Wed, 6 Nov 1996 15:32:24 -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 PAA07262 for ; Wed, 6 Nov 1996 15:32:19 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09039; Wed, 6 Nov 1996 16:21:28 -0700 From: Terry Lambert Message-Id: <199611062321.QAA09039@phaeton.artisoft.com> Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) To: hasty@rah.star-gate.com (Amancio Hasty) Date: Wed, 6 Nov 1996 16:21:28 -0700 (MST) Cc: archie@whistle.com, jgreco@brasil.moneng.mei.com, hannibal@cyberstation.net, hackers@freebsd.org In-Reply-To: <199611062125.NAA11085@rah.star-gate.com> from "Amancio Hasty" at Nov 6, 96 01:25: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 > What about kernel modifications? > In a commercial environment it can be very beneficial to provide rate > control. QOS --- that ugly old OSI term or more recently reservation > bandwith services. That's only useful if your reservation is end-to-end, isn't it? I mean if you have a T1, you know you have a T1, and you reserve 50% of the thing, then you have to be sure that you will get that rate end-to-end for it to be truly useful. What you guys are really complaining about is "Bob is eating all my bandwidth with his app, how do I throttle Bob?". I think the answer is hidden in the question "how do I *know* Bob is eating all my bandwidth in the first place? Specifically, how do I know how much I have so that 'all my bandwidth' is a meaningful idea?". It's only useful to talk about 50% of X when you know how big X is... 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 6 15:38:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA07618 for hackers-outgoing; Wed, 6 Nov 1996 15:38:27 -0800 (PST) Received: from bsd7.cs.sunysb.edu (bsd7.cs.sunysb.edu [130.245.1.197]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA07611 for ; Wed, 6 Nov 1996 15:38:21 -0800 (PST) Received: (from uucp@localhost) by bsd7.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id SAA14575; Wed, 6 Nov 1996 18:34:52 -0500 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.7.5/8.6.9) id SAA22264; Wed, 6 Nov 1996 18:30:25 -0500 (EST) Date: Wed, 6 Nov 1996 18:30:25 -0500 (EST) From: Gene Stark Message-Id: <199611062330.SAA22264@starkhome.cs.sunysb.edu> To: polstra.com!jdp@bsd7.cs.sunysb.edu CC: freebsd.org!hackers@bsd7.cs.sunysb.edu In-reply-to: <199611061839.KAA10633@austin.polstra.com> (message from John Polstra on Wed, 06 Nov 1996 10:39:03 -0800) Subject: Re: SUP on sup.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >As to the "*GIANT*, *BLOATED* language subsystem," you are out of >date on that. The current CVSup package (the one from the packages Well, sorry, but I have in fact built the Modula 3 distribution, and IMHO it is extremely large, rivaling, if not surpassing, GNU CC in bloat. >collection, not the static binary release which is completely >stand-alone) depends only on the "modula-3-lib" package, whose >tarball is < 1 MB and which occupies 3.2 MB when fully installed. >BTW, if you think 3.2 MB is still too giant and bloated, well, >welcome to the 1980's, Bubba. ;-) Yes, I do, as a drop-in replacement for something that was under 60K. I understand that it has a GUI and all sorts of functionality, but I still think it is large and bloated. Just my opinion. - Gene Stark From owner-freebsd-hackers Wed Nov 6 15:40:49 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA07806 for hackers-outgoing; Wed, 6 Nov 1996 15:40:49 -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 PAA07801 for ; Wed, 6 Nov 1996 15:40:43 -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 PAA12630; Wed, 6 Nov 1996 15:38:36 -0800 (PST) Message-Id: <199611062338.PAA12630@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: archie@whistle.com, jgreco@brasil.moneng.mei.com, hannibal@cyberstation.net, hackers@freebsd.org Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?) In-reply-to: Your message of "Wed, 06 Nov 1996 16:21:28 MST." <199611062321.QAA09039@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 15:38:36 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Terry Lambert : > > What about kernel modifications? > > In a commercial environment it can be very beneficial to provide rate > > control. QOS --- that ugly old OSI term or more recently reservation > > bandwith services. > > That's only useful if your reservation is end-to-end, isn't it? Nope, the concept is useful to limit the rate for a given connection whether the connection is udp or tcp. Of course it helps if the other side also does rate limiting but we have to start somehere .... The other bit which you hinted at is monitoring . I would look around to see if snmp fits this requirement. if not create a FreeBSD specific mib to monitor the connections 8) ( I think that the tcp/ip mibs can do the job is just that I don't have the time to go fetch them and refresh my memory). Amancio From owner-freebsd-hackers Wed Nov 6 15:43:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA08017 for hackers-outgoing; Wed, 6 Nov 1996 15:43:50 -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 PAA07983; Wed, 6 Nov 1996 15:43:30 -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 AAA24348; Thu, 7 Nov 1996 00:42:52 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA19370; Thu, 7 Nov 1996 00:42:52 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id AAA24345; Thu, 7 Nov 1996 00:33:16 +0100 (MET) From: J Wunsch Message-Id: <199611062333.AAA24345@uriah.heep.sax.de> Subject: Re: SUP on sup.freebsd.org To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Thu, 7 Nov 1996 00:33:14 +0100 (MET) Cc: sos@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611061929.UAA02640@ravenock.cybercity.dk> from "sos@FreeBSD.org" at "Nov 6, 96 08:29:52 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 sos@FreeBSD.org wrote: > Erhm, why on earth did you chose Modula3 ?? I newer got the > warm fuzzies by mr. Wirth's languages , they are maybe good > educational tools, but for real world apps, nah.... :) Well, so even if there were only CVSup, from the reputation this tools has already got during its fairly short public lifetime: you've got the best counterexample, i'd say. ;-) -- 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 Wed Nov 6 16:06:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA09873 for hackers-outgoing; Wed, 6 Nov 1996 16:06:34 -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 QAA09862 for ; Wed, 6 Nov 1996 16:06:26 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA05561; Thu, 7 Nov 1996 10:36:08 +1030 From: Michael Smith Message-Id: <199611070006.KAA05561@genesis.atrad.adelaide.edu.au> Subject: Re: SUP on sup.freebsd.org To: jdp@polstra.com (John Polstra) Date: Thu, 7 Nov 1996 10:36:08 +1030 (CST) Cc: erich@lodgenet.com, hackers@freebsd.org In-Reply-To: <199611062247.OAA12257@austin.polstra.com> from "John Polstra" at Nov 6, 96 02:47:23 pm 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 Polstra stands accused of saying: > > I checked the server logs, and here's what I found: > > 1996.11.06 14:25:11 PST [1821.60]: Connection from bacall.lodgenet.com > 1996.11.06 14:25:12 PST [1821.60]: User erich > 1996.11.06 14:26:27 PST [1821.60]: Connect failed: Connection refused > > Your SOCKS server is rejecting the connections back from the server to > the client. This is controlled by the people who administer your SOCKS > server configuration. I have an idea or two which I'll discuss further > with you in a separate mail off the hackers list. Please keep me in the loop here; I have a strong interest in SOCKS and CVSup. > John Polstra jdp@polstra.com -- ]] 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 Wed Nov 6 16:49:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA12674 for hackers-outgoing; Wed, 6 Nov 1996 16:49:41 -0800 (PST) Received: from wong.rogerswave.ca (a17b32.rogerswave.ca [204.92.17.32]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA12666 for ; Wed, 6 Nov 1996 16:49:35 -0800 (PST) Received: (from wong@localhost) by wong.rogerswave.ca (8.7.5/8.7.3) id UAA00330; Wed, 6 Nov 1996 20:44:36 -0500 (EST) Date: Wed, 6 Nov 1996 20:44:36 -0500 (EST) From: Ken Wong Reply-To: wong@rogerswave.ca To: freebsd-hackers@FreeBSD.ORG Subject: Re: atapi errors In-Reply-To: <199611050512.AAA00885@netrover.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 Tue, 5 Nov 1996, Brian Campbell wrote: > > Hmmm ... it'd be nice to blame it on the hardware, but I don't think I > can this time. Booting the same machine into windows 95 or qnx enables ^^^^ It is nice to see somebody is running a realtime OS. do you mind if I ask what are you using it for? > the CD to be read without any problems. > > I was hoping someone would say "oh, that's been fixed in -current, grab > atapi.c" or "oh, looks like it timed out too soon, adjust flarg to plib" I think the problem with your h/w is that you need some delay inbetween commands. I could have done it, but don't have your version of cdrom. perhaps you can edit the atapi_cmd(..) in atapi.c and see... good luck ken From owner-freebsd-hackers Wed Nov 6 17:19:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA14080 for hackers-outgoing; Wed, 6 Nov 1996 17:19:20 -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 RAA14071 for ; Wed, 6 Nov 1996 17:19:16 -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 RAA14661 for ; Wed, 6 Nov 1996 17:18:20 -0800 (PST) Message-ID: <328138CB.41C67EA6@whistle.com> Date: Wed, 06 Nov 1996 17:18:03 -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: still no response Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I still haven't heard back from anyone regarding the session limit addition in inetd. does everyone think it's a boring idea? doesn no one dislikr it? should I just check it in? (patch in previous email) julian From owner-freebsd-hackers Wed Nov 6 17:45:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA15555 for hackers-outgoing; Wed, 6 Nov 1996 17:45:20 -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 RAA15545 for ; Wed, 6 Nov 1996 17:45:13 -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 RAA13551; Wed, 6 Nov 1996 17:45:06 -0800 (PST) Message-Id: <199611070145.RAA13551@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Julian Elischer cc: hackers@freebsd.org Subject: Re: still no response In-reply-to: Your message of "Wed, 06 Nov 1996 17:18:03 PST." <328138CB.41C67EA6@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 17:45:06 -0800 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think that you will have to check it in and if it doesnt work just inform people of your time window to fix it 8) Regards, Amancio >From The Desk Of Julian Elischer : > I still haven't heard back from anyone regarding the > session limit addition in inetd. > > does everyone think it's a boring idea? > doesn no one dislikr it? > should I just check it in? > > > (patch in previous email) > > julian > From owner-freebsd-hackers Wed Nov 6 17:54:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA16211 for hackers-outgoing; Wed, 6 Nov 1996 17:54: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 RAA16201 for ; Wed, 6 Nov 1996 17:54:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA09269; Wed, 6 Nov 1996 18:46:19 -0700 From: Terry Lambert Message-Id: <199611070146.SAA09269@phaeton.artisoft.com> Subject: Re: still no response To: julian@whistle.com (Julian Elischer) Date: Wed, 6 Nov 1996 18:46:19 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <328138CB.41C67EA6@whistle.com> from "Julian Elischer" at Nov 6, 96 05:18: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 > I still haven't heard back from anyone regarding the > session limit addition in inetd. > > does everyone think it's a boring idea? > doesn no one dislikr it? > should I just check it in? The inetd already has a session limit. It's just not per service, it's per inetd, and it's compiled in. You can get the same effect right now by compiling another inetd and starting several inetd's with different inetd.conf files per service class. I've used multiple inetd's for several years to get different '-R' values for different things (tftpd, in particular, for a lab full of X terminals). I've only compiled up a seperate inetd with a use count restriction once, and that was for an ISP who wanted to limit FTP sessions with an old ftpd. I can see where it might be a big deal for some ISP's, or for people who want to put every service in a different limitation class. Other than that, I'm pretty non-commital -- I can take it or leave it... it's just an alternate way of doing things I can already do (but with the bonus that people who don't understand inetd can twiddle the thing, I suppose). 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 6 19:01:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA19643 for hackers-outgoing; Wed, 6 Nov 1996 19:01:46 -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 TAA19638 for ; Wed, 6 Nov 1996 19:01:42 -0800 (PST) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.8.2/Sogang) id LAA17427; Thu, 7 Nov 1996 11:55:48 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA18137; Thu, 7 Nov 96 11:59:10 KST From: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Message-Id: <9611070259.AA18137@cslsun10.sogang.ac.kr> Subject: frame allocation To: freebsd-hackers@FreeBSD.ORG Date: Thu, 7 Nov 1996 11:59:08 +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 . l have some question about FreeBSD memory management. i would that know how many memory(physical 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 model because it lacks accurate infomation about the reference pattern of a process. then, in freebsd memory management , how many physical memory is allocated about requested memory. allocated all the page allocation size is static, or allocated all the page allocation size is dynamic. l would then know. if page allocation fomula is, what function is used, what percent of requested memory is allocated, please send me a message. From owner-freebsd-hackers Wed Nov 6 19:03:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA19698 for hackers-outgoing; Wed, 6 Nov 1996 19:03:01 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA19382 for ; Wed, 6 Nov 1996 18:58:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA20771; Wed, 6 Nov 1996 19:58:33 -0700 Message-Id: <199611070258.TAA20771@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: hackers@freefall.freebsd.org cc: John Polstra Subject: Re: SUP on sup.freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 19:58:33 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Any software task that is worth doing can be done reasonably on a > split I/D PDP-11. > >(That's 64K each of code and data, for those of you who don't remember.) I still have a Unidot 11-73 in the basement. I could spin it up and setup xu if you want to port CVSup to it... Will 70 megbyte of disk be enough? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-hackers Wed Nov 6 19:19:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA21001 for hackers-outgoing; Wed, 6 Nov 1996 19:19: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 TAA20996 for ; Wed, 6 Nov 1996 19:19:48 -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 TAA17073; Wed, 6 Nov 1996 19:19:23 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id OAA21381; Thu, 7 Nov 1996 14:18:52 +1100 From: Julian Assange Message-Id: <199611070318.OAA21381@suburbia.net> Subject: Re: still no response To: julian@whistle.com (Julian Elischer) Date: Thu, 7 Nov 1996 14:18:52 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <328138CB.41C67EA6@whistle.com> from "Julian Elischer" at Nov 6, 96 05:18:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I still haven't heard back from anyone regarding the > session limit addition in inetd. > > does everyone think it's a boring idea? > doesn no one dislikr it? > should I just check it in? I like it. Now, what do you think of mine ;) --- inetd.8.orig Sat Aug 10 02:56:32 1996 +++ inetd.8 Tue Nov 5 20:35:24 1996 @@ -312,6 +312,21 @@ .Tn RFC document. .Pp +Lines starting with '/' in the configuration file are special directives to +.Nm inetd . +At present the following directives are supported: +.Bd -literal +/bind iface1|ANY...iface_n bind following service entries to + these interfaces +/bind+ iface1...iface_n as above, but add specified ifaces to + the previous bind list +.Ed +.Pp +If the iface name begins with "<", then the iface name is treated +as a file with interface addresses listed as the first word per line. +If the iface name is multi-homed in the DNS, then all addresses belonging +to that iface name will be bound. +.Pp When given the .Fl l option @@ -376,6 +391,22 @@ .Bd -literal ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l ntalk dgram udp wait root /usr/libexec/ntalkd ntalkd +tcpmux/+date stream tcp nowait guest /bin/date date +tcpmux/phonebook stream tcp nowait guest /usr/local/bin/phonebook phonebook +rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd +.Ed +.Pp +Here is a similar example with binding directives: +.Bd -literal +/bind #include #include +#include #include #include @@ -144,6 +158,10 @@ struct servent *sp; struct rpcent *rpc; struct in_addr bind_address; +struct se_bind { + struct se_bind *next; + struct in_addr addr; +} *addrs, *addrs_tail; struct servtab { char *se_service; /* name of service */ @@ -202,6 +220,7 @@ char *sskip __P((char **)); char *skip __P((char **)); struct servtab *tcpmux __P((int)); +void *xmalloc __P((int)); void unregisterrpc __P((register struct servtab *sep)); @@ -595,7 +614,8 @@ } for (sep = servtab; sep; sep = sep->se_next) if (strcmp(sep->se_service, cp->se_service) == 0 && - strcmp(sep->se_proto, cp->se_proto) == 0) + strcmp(sep->se_proto, cp->se_proto) == 0 && + memcmp(&sep->se_ctrladdr.sin_addr, &cp->se_ctrladdr.sin_addr, sizeof(struct in_addr)) == 0) break; if (sep != 0) { int i; @@ -665,7 +685,16 @@ } } if (sep->se_fd == -1) - setup(sep); + { + if (addrs) { + struct se_bind *p = addrs; + do { + sep->se_ctrladdr.sin_addr = p->addr; + setup(sep); + } while ((p = p->next) && (sep = enter(sep))); + } else + setup(sep); + } } endconfig(); /* @@ -828,6 +857,22 @@ sep->se_wait = 1; } +void * +xmalloc(int n) +{ + void *p; + int count; + for (count=0; !(p = malloc(n)); ) { + if (count++>50) { + syslog(LOG_ERR, "Out of memory. terminating!"); + exit(-1); + } + syslog(LOG_ERR, "Out of memory sleeping... retrying malloc()"); + sleep(10); + } + return p; +} + struct servtab * enter(cp) struct servtab *cp; @@ -835,11 +880,7 @@ struct servtab *sep; long omask; - sep = (struct servtab *)malloc(sizeof (*sep)); - if (sep == (struct servtab *)0) { - syslog(LOG_ERR, "Out of memory."); - exit(-1); - } + sep = xmalloc(sizeof (*sep)); *sep = *cp; sep->se_fd = -1; omask = sigblock(SIGBLOCK); @@ -874,6 +915,89 @@ } } +void +add_addr(struct in_addr *in) +{ + if (!addrs) { + addrs_tail = addrs = xmalloc (sizeof *addrs_tail); + } else { + addrs_tail->next = xmalloc (sizeof *addrs_tail); + addrs_tail = addrs->next; + } + addrs_tail->addr = *in; + addrs_tail->next = NULL; +} + +void +free_addrs() +{ + struct se_bind *p; + for (p = addrs; p; ) { + struct se_bind *p2 = p; + p = p2->next; + free (p2); + } + addrs_tail = addrs = NULL; +} + +void +add_binding(char *arg) +{ + struct in_addr in; + if (strcmp(arg, "ANY") == 0) { + free_addrs(); + return; + } + if (inet_aton(arg, &in)) + add_addr(&in); + else { + struct hostent *h; + char **inp; + h = gethostbyname(arg); + if (!h) { + syslog(LOG_ERR, "%s: couldn't resolve /bind %s [skipped binding]", CONFIG, arg); + return; + } + if (h->h_addrtype!=AF_INET) { + syslog(LOG_ERR, "%s: \"%s\" not an AF_INET address [skipped binding]", CONFIG, arg); + return; + } + /* host may be multi-homed, so attach all addresses */ + for (inp = h->h_addr_list; *inp; inp++) + add_addr((struct in_addr *)*inp); + } +} + +void +slash_bind(char *cp, int add_flag) +{ + char *arg; + if (!add_flag) + free_addrs(); + for (arg = sskip(&cp); arg; arg = skip(&cp)) { + if (*arg == '<') { + char nam[128]; + FILE *fp = fopen(++arg, "r"); + if (!fp) { + syslog(LOG_ERR, "%s: couldn't open addr file '%s': %m", CONFIG, arg); + exit(-1); + } + while (fscanf(fp, "%127s%*[^\n]", nam)==1) + { + if (*nam == '#') + continue; + add_binding(nam); + } + if (ferror(fp)) { + syslog(LOG_ERR, "%s: error reading addr file '%s': %m", CONFIG, arg); + exit(-1); + } + fclose(fp); + } else + add_binding(arg); + } +} + struct servtab * getconfigent() { @@ -883,12 +1007,30 @@ char *versp; static char TCPMUX_TOKEN[] = "tcpmux/"; #define MUX_LEN (sizeof(TCPMUX_TOKEN)-1) - + struct se_bind { + struct se_bind *next; + struct in_addr addr; + } *addrs = NULL; more: while ((cp = nextline(fconfig)) && (*cp == '#' || *cp == '\0')) ; if (cp == NULL) return ((struct servtab *)0); + + if (*cp == '/') { + /* processing directives */ + ++cp; + arg = sskip(&cp); + if (strcmp(arg, "bind") == 0) + slash_bind(cp, 0); + else if (strcmp(arg, "bind+") == 0) + slash_bind(cp, 1); + else { + syslog(LOG_ERR, "%s: invalid /directive \"%s\"", CONFIG, arg); + exit (-1); + } + goto more; + } /* * clear the static buffer, since some fields (se_ctrladdr, * for example) don't get initialized here. @@ -947,7 +1089,7 @@ break; default: syslog(LOG_ERR, - "bad RPC version specifier; %s\n", + "bad RPC version specifier; %s", sep->se_service); freeconfig(sep); goto more; From owner-freebsd-hackers Wed Nov 6 19:47:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA22556 for hackers-outgoing; Wed, 6 Nov 1996 19:47:45 -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 TAA22551 for ; Wed, 6 Nov 1996 19:47:41 -0800 (PST) Received: from pdx1.world.net by mail.crl.com with SMTP id AA10896 (5.65c/IDA-1.5 for ); Wed, 6 Nov 1996 20:48:48 -0700 Received: from suburbia.net (suburbia.net [198.142.2.24]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id TAA17480 for ; Wed, 6 Nov 1996 19:45:02 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id OAA22802 for hackers@freebsd.org; Thu, 7 Nov 1996 14:44:50 +1100 From: Julian Assange Message-Id: <199611070344.OAA22802@suburbia.net> Subject: Re: SUP on sup.freebsd.org To: hackers@freebsd.org Date: Thu, 7 Nov 1996 14:44:50 +1100 (EST) In-Reply-To: <199611061929.UAA02640@ravenock.cybercity.dk> from "sos@FreeBSD.org" at Nov 6, 96 08:29:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Oh and yes I have seen apps written in modula3, all of which > was horrible performers, and impossible to port to new platforms, > so the management decide a complete rewrite in, guess what, C! > > (I ducking now and jumping into the asbestos suit) The nicest looking language I have seen to date is UFO: http://www.cs.man.ac.uk/arch/people/s-hooton/overview/index.html I'm in love ;) -- "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 6 19:51:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA22783 for hackers-outgoing; Wed, 6 Nov 1996 19:51:32 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA22778 for ; Wed, 6 Nov 1996 19:51:28 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.2/8.7.3) with SMTP id WAA04403; Wed, 6 Nov 1996 22:51:19 -0500 (EST) Message-Id: <199611070351.WAA04403@whizzo.transsys.com> X-Mailer: exmh version 1.6.9 8/22/96 To: John Polstra cc: hackers@FreeBSD.org From: "Louis A. Mamakos" Subject: Re: SUP on sup.freebsd.org References: <199611061504.JAA07519@Mercury.mcs.net> <199611061814.KAA10529@austin.polstra.com> In-reply-to: Your message of "Wed, 06 Nov 1996 10:14:54 PST." <199611061814.KAA10529@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 22:51:19 -0500 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Is there a way to have cvsup not re-populate the Attic files? With all of the activity lately in the contrib tree with new files being added and old ones moving to Attic, my disk is becoming uncomfortably full. You'll be happy to know that if they are removed, cvsup will "fix" the "problem" and replace them.. louie From owner-freebsd-hackers Wed Nov 6 19:51:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA22803 for hackers-outgoing; Wed, 6 Nov 1996 19:51:37 -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 TAA22796 for ; Wed, 6 Nov 1996 19:51:35 -0800 (PST) Received: from pdx1.world.net by mail.crl.com with SMTP id AA11731 (5.65c/IDA-1.5 for ); Wed, 6 Nov 1996 20:52:42 -0700 Received: from suburbia.net (suburbia.net [198.142.2.24]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id TAA17542; Wed, 6 Nov 1996 19:48:44 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id OAA23081; Thu, 7 Nov 1996 14:48:22 +1100 From: Julian Assange Message-Id: <199611070348.OAA23081@suburbia.net> Subject: Re: SUP on sup.freebsd.org To: jdp@polstra.com (John Polstra) Date: Thu, 7 Nov 1996 14:48:22 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611061839.KAA10633@austin.polstra.com> from "John Polstra" at Nov 6, 96 10:39:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > In article <199611061121.GAA20346@starkhome.cs.sunysb.edu> gene@starkhome.cs.sunysb.edu writes: > > I can well sympathize with the need to do something about your network > > load problems, but I just tried (unsuccessfully) to build CVSup and I have > > the following *major* complaints, which I hope you will consider: > > > > (1) CVSup, being written in Modula3, requires the importation > > of a *GIANT*, *BLOATED* language subsystem, which is not > > currently a standard part of FreeBSD (nor should it be). I'd personally like to see a version of cvsup without all that windowing code. All a bit pointless, given that it isn't interactive. From owner-freebsd-hackers Wed Nov 6 19:51:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA22844 for hackers-outgoing; Wed, 6 Nov 1996 19:51:50 -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 TAA22811 for ; Wed, 6 Nov 1996 19:51:38 -0800 (PST) Received: from brasil.moneng.mei.com by mail.crl.com with SMTP id AA11726 (5.65c/IDA-1.5 for ); Wed, 6 Nov 1996 20:52:40 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id VAA10194; Wed, 6 Nov 1996 21:42:52 -0600 From: Joe Greco Message-Id: <199611070342.VAA10194@brasil.moneng.mei.com> Subject: Re: still no response To: terry@lambert.org (Terry Lambert) Date: Wed, 6 Nov 1996 21:42:51 -0600 (CST) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199611070146.SAA09269@phaeton.artisoft.com> from "Terry Lambert" at Nov 6, 96 06:46:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I still haven't heard back from anyone regarding the > > session limit addition in inetd. > > > > does everyone think it's a boring idea? > > doesn no one dislikr it? > > should I just check it in? > > The inetd already has a session limit. It's just not per service, it's > per inetd, and it's compiled in. I thought that was a session spawning rate limit - not a session number limit. Maybe I am wrong. ... JG From owner-freebsd-hackers Wed Nov 6 20:01:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA23557 for hackers-outgoing; Wed, 6 Nov 1996 20:01:47 -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 UAA23551 for ; Wed, 6 Nov 1996 20:01:42 -0800 (PST) Received: from misery.sdf.com ([204.244.213.33]) by misery.sdf.com with SMTP id <1354-3087>; Wed, 6 Nov 1996 20:29:42 -0800 Date: Wed, 6 Nov 1996 20:29:31 -0800 (PST) From: Tom Samplonius To: Julian Elischer cc: hackers@freebsd.org Subject: Re: Inetd mod.. comments? In-Reply-To: <3280EF24.ABD322C@whistle.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, 6 Nov 1996, Julian Elischer wrote: > I have some patches to Inetd her that I sent out for comment. > the only comment I got was > "Gee that's neat!, I need that" > > but no technical reviews or code checks.. xinetd has done this for long time already. Why not use that? Tom From owner-freebsd-hackers Wed Nov 6 20:10:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA24250 for hackers-outgoing; Wed, 6 Nov 1996 20:10:31 -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 UAA24241 for ; Wed, 6 Nov 1996 20:10:25 -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 UAA17835 for ; Wed, 6 Nov 1996 20:10:11 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id PAA23969 for hackers@freebsd.org; Thu, 7 Nov 1996 15:09:57 +1100 From: Julian Assange Message-Id: <199611070409.PAA23969@suburbia.net> Subject: limiting bandwidth on a port via forwarding To: hackers@freebsd.org Date: Thu, 7 Nov 1996 15:09:56 +1100 (EST) In-Reply-To: <199611061628.KAA08735@brasil.moneng.mei.com> from "Joe Greco" at Nov 6, 96 10:28:41 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > > I could swear I saw a "low-bandwidth ncftp" or something of the sort on > > > > sunsite.unc.edu a couple years ago, so I think this is possible (Well, at (etc) I'm more interested in the forwarding situation. Dynamic modification of the tcp window size according to ipfw rules and the current amount of backed up data seems like something that wouldn't be hard to impliment. Darren? -- "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 6 20:52:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA27015 for hackers-outgoing; Wed, 6 Nov 1996 20:52:22 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA27009 for ; Wed, 6 Nov 1996 20:52:17 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id XAA03133; Wed, 6 Nov 1996 23:50:28 -0500 (EST) From: "John S. Dyson" Message-Id: <199611070450.XAA03133@dyson.iquest.net> Subject: Re: frame allocation To: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Date: Wed, 6 Nov 1996 23:50:27 -0500 (EST) Cc: freebsd-hackers@freebsd.org, cskim@cslsun10.sogang.ac.kr In-Reply-To: <9611070259.AA18137@cslsun10.sogang.ac.kr> from "Kim Chang Seob" at Nov 7, 96 11:59:08 am 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 there . > l have some question about FreeBSD memory management. > i would that know how many memory(physical memory) to provide to each process > to minimize the latter's page fault behavior. > Right now, there isn't a closed form method for finding a processes optimum working set. > > i know, freebsd memory management does not use the working set model > because it lacks accurate infomation about the reference pattern > of a process. > Yes, you are right. > then, in freebsd memory management , how many physical memory is allocated > about requested memory. > allocated all the page allocation size is static, > or allocated all the page allocation size is dynamic. The processes compete for available memory. There are usage statistics gathered (beyond the simple LRU scheme), that help make an estimation of the probability of future use. John From owner-freebsd-hackers Wed Nov 6 21:16:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28295 for hackers-outgoing; Wed, 6 Nov 1996 21:16:43 -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 VAA28289 for ; Wed, 6 Nov 1996 21:16:38 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id VAA14817; Wed, 6 Nov 1996 21:15:08 -0800 (PST) Message-Id: <199611070515.VAA14817@austin.polstra.com> To: Julian Assange cc: hackers@freebsd.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Thu, 07 Nov 1996 14:48:22 +1100." <199611070348.OAA23081@suburbia.net> References: <199611070348.OAA23081@suburbia.net> Date: Wed, 06 Nov 1996 21:15:07 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'd personally like to see a version of cvsup without all that > windowing code. Look at the Makefile in the port: # To build the client without GUI support: #MAKE_ENV= M3FLAGS=-DNOGUI 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 Wed Nov 6 21:18:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28406 for hackers-outgoing; Wed, 6 Nov 1996 21:18:19 -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 VAA28401 for ; Wed, 6 Nov 1996 21:18:14 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id VAA14764; Wed, 6 Nov 1996 21:13:36 -0800 (PST) Message-Id: <199611070513.VAA14764@austin.polstra.com> To: "Louis A. Mamakos" cc: hackers@FreeBSD.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 22:51:19 EST." <199611070351.WAA04403@whizzo.transsys.com> References: <199611070351.WAA04403@whizzo.transsys.com> Date: Wed, 06 Nov 1996 21:13:35 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Is there a way to have cvsup not re-populate the Attic files? Yes, as a matter of fact there is. You can use "refuse" files for that. See CVSUP(1) for details, but I'll give you the recipe here. In each directory "/sup/", create a file named "refuse" containing this line: */Attic/* (where and are the corresponding settings from your supfile, of course). This will make CVSup completely ignore all Attic directories. What that means: It won't delete anything from them, but it won't repopulate them either. So, after you've set up your "refuse" files, you'll have to use something like "find ... | xargs rm" to manually delete all the "Attic/*" files. After that, they'll remain empty. > You'll be happy to know that if they are removed, cvsup will "fix" > the "problem" and replace them.. I'm smilin' :-) 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 Wed Nov 6 21:20:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28644 for hackers-outgoing; Wed, 6 Nov 1996 21:20:37 -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 VAA28631 for ; Wed, 6 Nov 1996 21:20:34 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA04721; Thu, 7 Nov 1996 00:20:02 -0500 Received: from lambert.org by dg-rtp.dg.com.rtp.dg.com; Thu, 7 Nov 1996 00:20 EST Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.7.5/8.7.3) with UUCP id SAA07220 for freebsd.org!freebsd-hackers; Wed, 6 Nov 1996 18:56:10 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA08152; Wed, 6 Nov 1996 13:34:48 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA18746; Wed, 6 Nov 96 13:34:16 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA18670; Wed, 6 Nov 96 13:27:28 -0500 Received: from stingray.mcnc.org (stingray.mcnc.org [128.109.130.74]) by ncnoc.ncren.net (8.7.4/8.7.3) with ESMTP id NAA24013; Wed, 6 Nov 1996 13:25:18 -0500 (EST) Received: from relay6.UU.NET by stingray.mcnc.org (8.7.5/MCNC/8-10-92) id NAA07841; Wed, 6 Nov 1996 13:23:51 -0500 (EST) for Received: from coyote.Artisoft.COM by relay6.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQborp10976; Wed, 6 Nov 1996 13:24:31 -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 LAA13537; Wed, 6 Nov 1996 11:22:02 -0700 (MST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08484; Wed, 6 Nov 1996 11:14:35 -0700 From: Terry Lambert Message-Id: <199611061814.LAA08484@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: ponds!ponds!rivers (Thomas David Rivers) Date: Wed, 6 Nov 1996 11:14:34 -0700 (MST) Cc: ponds!lambert.org!terry, ponds!Artisoft.COM!ponds!rivers, ponds!Artisoft.COM!ponds!freebsd.org!dyson, ponds!Artisoft.COM!ponds!freebsd.org!freebsd-hackers, ponds!Artisoft.COM!ponds!lambert.org!terry In-Reply-To: <199611061300.IAA02838@lakes.water.net> from "Thomas David Rivers" at Nov 6, 96 08:00:35 am 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 > Although this isn't the complete patch you discuss below, > I believe it to be the proper fix for 2.1.5-STABLE.... I'm > providing to a) Let others acquire it, b) Get this into 2.1.6, > c) Ensure I understand the intent of your change. > > This patch doesn't use the nice macro, but it changes getnewvnode() > to allocate a totally new node when we've wrapped around the end of > the list... > > After Terry signs off on this, can someone get it committed to > 2.1.6 (nee 2.1.5-STABLE)... > > - Thanks - > - Dave Rivers - [ ... patch elided ... ] Yes. This is an equivalent workaround. I suppose the big question is: did this fix the problem for you? -- One caution: if you do not use the macro, and the queue type is changed yet again at some later time, this will introduce a "sneaky" bug that will not be obvious. What's worse, if you are already familiar with the code, it will "look right" because it will have been right the last time you looked at it. Remember the queue type change on the mounted fs list? There was a similar bug that "looked right" (I think that's where the macro came from, FWIW). 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 6 21:25:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28982 for hackers-outgoing; Wed, 6 Nov 1996 21:25:22 -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 VAA28974 for ; Wed, 6 Nov 1996 21:25:07 -0800 (PST) Received: from cslsun10.sogang.ac.kr by ccs.sogang.ac.kr (8.8.2/Sogang) id OAA28162; Thu, 7 Nov 1996 14:19:58 +0900 (KST) Received: by cslsun10.sogang.ac.kr (4.1/SMI-4.1) id AA18509; Thu, 7 Nov 96 14:23:26 KST From: cskim@cslsun10.sogang.ac.kr (Kim Chang Seob) Message-Id: <9611070523.AA18509@cslsun10.sogang.ac.kr> Subject: memory management To: freebsd-hackers@FreeBSD.ORG Date: Thu, 7 Nov 1996 14:23: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 yes. i have thanks you to your answer. but, i can not understand about memory management . in your messages, ************************************ The processes compete for available memory. There are usage statistics gathered , that help make an estimation of the probability of future use. ************************************ but , I can not understand what is usage statistics gathered. and what is "make an estimation of the probability of future use" in first , in system booting, in startup, the what is usage statistics , and what is probability, i known that frame allocation size is static, but if in previous test, more page fault is occur, next frame allocation size about same process is increase. but I don't know how many memory size is allocated in first. if gathered data is not, how mwny memory size is allocated, I know correct usage statistics and probability. From owner-freebsd-hackers Wed Nov 6 21:49:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA00518 for hackers-outgoing; Wed, 6 Nov 1996 21:49:19 -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 VAA00510 for ; Wed, 6 Nov 1996 21:49:14 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id VAA14957; Wed, 6 Nov 1996 21:39:28 -0800 (PST) Message-Id: <199611070539.VAA14957@austin.polstra.com> To: Steve Passe cc: hackers@freefall.freebsd.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 19:58:33 MST." <199611070258.TAA20771@clem.systemsix.com> References: <199611070258.TAA20771@clem.systemsix.com> Date: Wed, 06 Nov 1996 21:39:28 -0800 From: John Polstra Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I still have a Unidot 11-73 in the basement. Heh, what a riot. :-) I still had my old Onyx machine sitting on a shelf until maybe 8 years ago. A guy in California who was still using them (!) called me up and asked to buy it for parts. It had still worked when I last turned it off, BTW. I gave it to him for $100 plus shipping. (It cost me $13000 new, no kidding!) He powered it up, and it booted and started running just like new. Then he decided to do something or other with his _only_ "system" tape. (It was probably the only one left in existence by that time.) Unfortunately, the tape drive's capstan roller had turned to tar over the years, and it totally destroyed the tape. Bummer. :-( > I could spin it up and setup xu if you want to port CVSup to it... > Will 70 megbyte of disk be enough? Oh yeah, no problem! Hell, even 69 MB would probably be enough, despite the well known fact that CVSup is a giant, bloated thing. ;-) 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 Wed Nov 6 22:00:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA01312 for hackers-outgoing; Wed, 6 Nov 1996 22:00:20 -0800 (PST) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA01303 for ; Wed, 6 Nov 1996 22:00:14 -0800 (PST) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.2/8.7.3) with SMTP id AAA04807; Thu, 7 Nov 1996 00:58:58 -0500 (EST) Message-Id: <199611070558.AAA04807@whizzo.transsys.com> X-Mailer: exmh version 1.6.9 8/22/96 To: John Polstra cc: hackers@FreeBSD.org From: "Louis A. Mamakos" Subject: Re: SUP on sup.freebsd.org References: <199611070351.WAA04403@whizzo.transsys.com> <199611070513.VAA14764@austin.polstra.com> In-reply-to: Your message of "Wed, 06 Nov 1996 21:13:35 PST." <199611070513.VAA14764@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 00:58:57 -0500 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Thanks for the hint. I actually did look at the man page, but not quite close enough, apparently. Making the suggested change, and zapping all of the Attic directories took me from 49224 blocks free to 187240 blocks free. Gaining back the 138016 blocks, or 69 megabytes was sorta nice.. Thanks again, by the way, for cvsup, which is quite a nice piece of work and a wonderful tool. It's a huge win over running sup, like I used to, even over my 56K connection. louie From owner-freebsd-hackers Wed Nov 6 22:30:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA03257 for hackers-outgoing; Wed, 6 Nov 1996 22:30:35 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA03251 for ; Wed, 6 Nov 1996 22:30:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA21750; Wed, 6 Nov 1996 23:29:53 -0700 Message-Id: <199611070629.XAA21750@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: John Polstra cc: hackers@freefall.freebsd.org Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 21:39:28 PST." <199611070539.VAA14957@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 23:29:53 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >> I still have a Unidot 11-73 in the basement. > >Heh, what a riot. :-) I still had my old Onyx machine sitting on >a shelf until maybe 8 years ago. we literaly threw out the head assembly from the 300MB washing machine last week. Its last use was to shoot steel rods from what was the head rod actuator (about 100lbs of electro-magnet). My friend Paul was moving and he decided that such functionality wasn't enough justification to drag it with him, so he had the movers toss it in the dumpster. I think the platters still had all the V6/V7 source on them! The kids are probably getting tired of us geezers remembering old times so I'll shut-up now... -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Wed Nov 6 22:36:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA03694 for hackers-outgoing; Wed, 6 Nov 1996 22:36: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 WAA03686 for ; Wed, 6 Nov 1996 22:36:22 -0800 (PST) Received: (babkin@localhost) by hq.icb.chel.su (8.7.5/8.6.5) id LAA06362; Thu, 7 Nov 1996 11:36:26 +0500 (ESK) From: "Serge A. Babkin" Message-Id: <199611070636.LAA06362@hq.icb.chel.su> Subject: Re: COFF->BSD converter To: brianc@pobox.com Date: Thu, 7 Nov 1996 11:36:26 +0500 (ESK) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199611050003.TAA00489@netrover.com> from "Brian Campbell" at Nov 4, 96 07:03:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Is there an objdump for FreeBSD? > I heard from someone that it is. If you need a disassembler you can try my dis that should be in the packages too. It has some semi-intelligence. -SB From owner-freebsd-hackers Wed Nov 6 22:48:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA04693 for hackers-outgoing; Wed, 6 Nov 1996 22:48:47 -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 WAA04684 for ; Wed, 6 Nov 1996 22:48:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id WAA18267 for ; Wed, 6 Nov 1996 22:48:33 -0800 (PST) Date: Wed, 6 Nov 1996 22:48:33 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: FreeBSD Hackers Subject: changing default sysctl values in kernel... 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... the subject says it all... I have a server that is designed to be a terminal server... and I would like a way to compile a kernel with the default of net.inet.ip.forwarding: 1... instead of 0... will allow me to not have sysctl on the machine... thanks for your 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 Wed Nov 6 22:54:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA05179 for hackers-outgoing; Wed, 6 Nov 1996 22:54:32 -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 WAA05174 for ; Wed, 6 Nov 1996 22:54:29 -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 WAA25439 for ; Wed, 6 Nov 1996 22:54:29 -0800 (PST) To: freebsd-hackers@FreeBSD.org (FreeBSD hackers) Subject: Re: SUP on sup.freebsd.org In-reply-to: Your message of "Thu, 07 Nov 1996 00:33:14 +0100." <199611062333.AAA24345@uriah.heep.sax.de> Date: Wed, 06 Nov 1996 22:54:29 -0800 Message-ID: <25437.847349669@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Well, so even if there were only CVSup, from the reputation this tools > has already got during its fairly short public lifetime: you've got > the best counterexample, i'd say. ;-) I also think it's incredibly bad form to tackle someone over his choice of implementation language *after the fact*, when it's likely to do nothing more than raise ill feelings to no good purpose. What's John supposed to do, say "Hey, gosh, you know, I just didn't think of that before. Write it in C. D'oh! What was I thinking? I'll be back in a couple of months, I'm just going to rewrite CVSup from scratch now, OK?" Clearly not, so hassling him about it is a zero-productivity activity. Moreso, it's not even fair. He wrote this in Modula-3 because he *wanted* to, and sometimes how you write something is at least as important as what you write. He wanted to do a large project in Modula-3, so he did, and he learned something from the experience - the rest of us getting a nifty-as-heck tool to use in the process. What's everybody's problem? All this carping over it is clearly out of line. Say "thanks, John!" not "why the %&*@! did you pick Modula-3, John!" Thank you. Jordan From owner-freebsd-hackers Wed Nov 6 23:16:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA07212 for hackers-outgoing; Wed, 6 Nov 1996 23:16:42 -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 XAA07204 for ; Wed, 6 Nov 1996 23:16:37 -0800 (PST) Message-Id: <199611070716.XAA07204@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA059471004; Thu, 7 Nov 1996 18:16:44 +1100 From: Darren Reed Subject: Re: still no response To: julian@whistle.com (Julian Elischer) Date: Thu, 7 Nov 1996 18:16:44 +1100 (EDT) Cc: hackers@freebsd.org In-Reply-To: <328138CB.41C67EA6@whistle.com> from "Julian Elischer" at Nov 6, 96 05:18:03 pm 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 Julian Elischer, sie said: > > I still haven't heard back from anyone regarding the > session limit addition in inetd. > > does everyone think it's a boring idea? > doesn no one dislikr it? > should I just check it in? xinetd ? From owner-freebsd-hackers Wed Nov 6 23:46:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA09174 for hackers-outgoing; Wed, 6 Nov 1996 23:46:43 -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 SMTP id XAA09169 for ; Wed, 6 Nov 1996 23:46:36 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id SAA09872 for hackers@freebsd.org; Thu, 7 Nov 1996 18:46:32 +1100 From: David Dawes Message-Id: <199611070746.SAA09872@rf900.physics.usyd.edu.au> Subject: Why multiple distfiles directories on ftp.freebsd.org? To: hackers@freebsd.org Date: Thu, 7 Nov 1996 18:46:32 +1100 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm about to re-organise and upgrade the FreeBSD mirror I maintain ({ftp,sup}.au.freebsd.org), and when checking the space requirements I see that there are two large distfiles directories. One is /pub/FreeBSD/distfiles (> 660MB), and the other is /pub/FreeBSD/FreeBSD-current/ports/distfiles (> 490MB). It seems that the latter is (with a very small number of exceptions) a subset of the former. Is there a good reason for having so much of this duplicated? I keep the former in sync with ftp mirroring, and the latter with sup. I presume that the latter will no longer be available anyway when I switch over to cvsup (and I'll be providing cvsup.au.freebsd.org when that is done). David From owner-freebsd-hackers Thu Nov 7 00:01:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA09742 for hackers-outgoing; Thu, 7 Nov 1996 00:01:32 -0800 (PST) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA09737 for ; Thu, 7 Nov 1996 00:01:29 -0800 (PST) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id JAA23103; Thu, 7 Nov 1996 09:00:33 +0100 Message-Id: <199611070800.JAA23103@ra.dkuug.dk> Subject: Re: SUP on sup.freebsd.org To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 7 Nov 1996 09:00:33 +0100 (MET) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <25437.847349669@time.cdrom.com> from "Jordan K. Hubbard" at Nov 6, 96 10:54:29 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who wrote: > > > Well, so even if there were only CVSup, from the reputation this tools > > has already got during its fairly short public lifetime: you've got > > the best counterexample, i'd say. ;-) > > I also think it's incredibly bad form to tackle someone over his > choice of implementation language *after the fact*, when it's likely > to do nothing more than raise ill feelings to no good purpose. What's > John supposed to do, say "Hey, gosh, you know, I just didn't think of > that before. Write it in C. D'oh! What was I thinking? I'll be > back in a couple of months, I'm just going to rewrite CVSup from > scratch now, OK?" Hmm, I wasn't tackling John here, I just wanted to know WHY he had chosen modula3 of all languages, maybe I had missed something when I was forced to play with it times ago. On the other hand I also think that we should have some sort of consensus on how/with what we write the stuff for our favorit OS, if we span too far, we will have a nightmare in trying to keep all the pieces together when "important" people leave the scene. I guess that these lists cannot be used for discussing anything not strictly technical, without everybody going ballistic, and putting all kinds of ill intent into the storyline, *sigh* End of story. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Thu Nov 7 00:16:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA10606 for hackers-outgoing; Thu, 7 Nov 1996 00:16:51 -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 AAA10594; Thu, 7 Nov 1996 00:16:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id AAA02988; Thu, 7 Nov 1996 00:13:48 -0800 (PST) Message-Id: <199611070813.AAA02988@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Thomas David Rivers cc: terry@lambert.org, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-reply-to: Your message of "Wed, 06 Nov 1996 08:00:35 EST." <199611061300.IAA02838@lakes.water.net> From: David Greenman Reply-To: dg@root.com Date: Thu, 07 Nov 1996 00:13:47 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> > ... description delete ... >> > >> > Err, umm, ... doesn't that only fix the "free vnode isn't" >> > panic? That's really not what I'm seeing... I'm seeing >> > inode allocation panics coming from ffs_valloc.c. >> >> No. It fixes the freelist wrap error. > > Ahh... I see... I was going to elide your description, >but I'll leave it in case others missed it... > > Although this isn't the complete patch you discuss below, >I believe it to be the proper fix for 2.1.5-STABLE.... I'm >providing to a) Let others acquire it, b) Get this into 2.1.6, >c) Ensure I understand the intent of your change. > > This patch doesn't use the nice macro, but it changes getnewvnode() >to allocate a totally new node when we've wrapped around the end of >the list... > > After Terry signs off on this, can someone get it committed to >2.1.6 (nee 2.1.5-STABLE)... I think there is a lot of misinformation being bandied about this problem. In the one case of this problem that I looked into, it was caused by the v_usecount being negative. There was clearly one too many vrele's occuring somewhere. It was not caused by any sort of "freelist wrap" condition. The patch you've provided will kludge around the problem, but it is not in any sense a "fix". Each time a vnode is deallocated too many times (and thus v_usecount goes negative), you'll end up losing all of the vnodes on the freelist that follow it (potentially several thousand) because the condition will never go away. This is bad. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Nov 7 01:35:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA15404 for hackers-outgoing; Thu, 7 Nov 1996 01:35:35 -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 BAA15390 for ; Thu, 7 Nov 1996 01:35:28 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id UAA08834; Thu, 7 Nov 1996 20:35:08 +1100 (EST) Date: Thu, 7 Nov 1996 20:35:05 +1100 (EST) From: "Daniel O'Callaghan" To: John-Mark Gurney cc: FreeBSD Hackers Subject: Re: changing default sysctl values in kernel... 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, 6 Nov 1996, John-Mark Gurney wrote: > well... the subject says it all... I have a server that is designed to be > a terminal server... and I would like a way to compile a kernel with the > default of net.inet.ip.forwarding: 1... instead of 0... will allow me to > not have sysctl on the machine... thanks for your help... ttyl.. Just put options GATEWAY in your kernel config file. Danny From owner-freebsd-hackers Thu Nov 7 03:20:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA19355 for hackers-outgoing; Thu, 7 Nov 1996 03: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 DAA19349 for ; Thu, 7 Nov 1996 03:20:34 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA21064; Thu, 7 Nov 1996 06:20:03 -0500 Received: from dg-rtp by dg-rtp.dg.com.rtp.dg.com; Thu, 7 Nov 1996 06:20 EST Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.7.5/8.7.3) with UUCP id AAA13571 for freebsd.org!freebsd-hackers; Thu, 7 Nov 1996 00:26:20 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA28901; Wed, 6 Nov 1996 18:46:11 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA22154; Wed, 6 Nov 96 18:34:48 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA22104; Wed, 6 Nov 96 18:30:13 -0500 Received: from stingray.mcnc.org (stingray.mcnc.org [128.109.130.74]) by ncnoc.ncren.net (8.7.4/8.7.3) with ESMTP id SAA29867 for ; Wed, 6 Nov 1996 18:28:46 -0500 (EST) Received: from relay5.UU.NET by stingray.mcnc.org (8.7.5/MCNC/8-10-92) id SAA09676; Wed, 6 Nov 1996 18:27:23 -0500 (EST) for Received: from coyote.Artisoft.COM by relay5.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQbosj15364; Wed, 6 Nov 1996 18:28:23 -0500 (EST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by coyote.Artisoft.COM (8.7.6/8.7.3) with SMTP id QAA22229 for ; Wed, 6 Nov 1996 16:20:37 -0700 (MST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA27423; Wed, 6 Nov 1996 18:20:05 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 6 Nov 1996 18: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 QAA05130; Wed, 6 Nov 1996 16:08:41 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id QAA00996; Wed, 6 Nov 1996 16:09:40 -0500 (EST) Date: Wed, 6 Nov 1996 16:09:40 -0500 (EST) From: Thomas David Rivers Message-Id: <199611062109.QAA00996@lakes.water.net> To: ponds!lambert.org!terry, ponds!uunet.uu.net!ponds!ponds!rivers Subject: Re: More info on the daily panics... Cc: ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!freebsd.org!dyson, ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!freebsd.org!freebsd-hackers, ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!lambert.org!terry, ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!rivers, ponds!uunet.uu.net!ponds!lambert.org!terry Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > [ ... patch elided ... ] > > Yes. This is an equivalent workaround. > > I suppose the big question is: did this fix the problem for you? > It's been running since 9:00am this morning - if it lasts a week, I will declare it a success... > > -- > > One caution: if you do not use the macro, and the queue type is changed > yet again at some later time, this will introduce a "sneaky" bug that > will not be obvious. > > What's worse, if you are already familiar with the code, it will > "look right" because it will have been right the last time you > looked at it. > > Remember the queue type change on the mounted fs list? There was a > similar bug that "looked right" (I think that's where the macro came > from, FWIW). > > Well, in all honesty - I was too lazy to look up the macro name. But, you're right; this should be rewritten to use it... - Dave R. - From owner-freebsd-hackers Thu Nov 7 03:24:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA19577 for hackers-outgoing; Thu, 7 Nov 1996 03:24:57 -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 DAA19566 for ; Thu, 7 Nov 1996 03:24:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id DAA03314; Thu, 7 Nov 1996 03:24:03 -0800 (PST) Date: Thu, 7 Nov 1996 03:24:01 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: "Daniel O'Callaghan" cc: FreeBSD Hackers Subject: Re: changing default sysctl values in kernel... 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, 7 Nov 1996, Daniel O'Callaghan wrote: > > > On Wed, 6 Nov 1996, John-Mark Gurney wrote: > > > well... the subject says it all... I have a server that is designed to be > > a terminal server... and I would like a way to compile a kernel with the > > default of net.inet.ip.forwarding: 1... instead of 0... will allow me to > > not have sysctl on the machine... thanks for your help... ttyl.. > > Just put > > options GATEWAY > > in your kernel config file. but I thought that was made obsolete by the sysctl value and didn't do anything any more... does it still enable routing? I just did a search through the kernel source (960801-SNAP) and the only place I found anything referencing GATEWAY was in some files in i386/boot/... other than that nothing... 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 7 09:36:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA06393 for hackers-outgoing; Thu, 7 Nov 1996 09:36:58 -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 JAA06364 for ; Thu, 7 Nov 1996 09:36:52 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id IAA17188 for ; Thu, 7 Nov 1996 08:39:55 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id QAA27029; Thu, 7 Nov 1996 16:39:23 GMT Date: Fri, 8 Nov 1996 01:39:23 +0900 (JST) From: Michael Hancock To: David Greenman cc: Thomas David Rivers , freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-Reply-To: <199611070813.AAA02988@root.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, 7 Nov 1996, David Greenman wrote: > In the one case of this problem that I looked into, it was caused by the > v_usecount being negative. There was clearly one too many vrele's occuring > somewhere. It was not caused by any sort of "freelist wrap" condition. The > patch you've provided will kludge around the problem, but it is not in any > sense a "fix". Each time a vnode is deallocated too many times (and thus > v_usecount goes negative), you'll end up losing all of the vnodes on the > freelist that follow it (potentially several thousand) because the condition > will never go away. This is bad. Then Thomas would be doing us a favor if he put in the following diff to help track it down: Index: vfs_subr.c =================================================================== RCS file: /jaz/cvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.50 retrieving revision 1.49 diff -c -r1.50 -r1.49 *** vfs_subr.c 1996/01/02 18:13:20 1.50 --- vfs_subr.c 1995/12/17 21:23:19 1.49 *************** *** 36,42 **** * SUCH DAMAGE. * * @(#)vfs_subr.c 8.13 (Berkeley) 4/18/94 ! * $Id: vfs_subr.c,v 1.50 1996/01/02 18:13:20 davidg Exp $ */ /* --- 36,42 ---- * SUCH DAMAGE. * * @(#)vfs_subr.c 8.13 (Berkeley) 4/18/94 ! * $Id: vfs_subr.c,v 1.49 1995/12/17 21:23:19 phk Exp $ */ /* *************** *** 835,846 **** vp->v_usecount--; if (vp->v_usecount > 0) return; - if (vp->v_usecount < 0 /* || vp->v_writecount < 0 */ ) { #ifdef DIAGNOSTIC vprint("vrele: negative ref count", vp); - #endif panic("vrele: negative reference cnt"); } if (vp->v_flag & VAGE) { TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); vp->v_flag &= ~VAGE; --- 835,846 ---- vp->v_usecount--; if (vp->v_usecount > 0) return; #ifdef DIAGNOSTIC + if (vp->v_usecount < 0 /* || vp->v_writecount < 0 */ ) { vprint("vrele: negative ref count", vp); panic("vrele: negative reference cnt"); } + #endif if (vp->v_flag & VAGE) { TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); vp->v_flag &= ~VAGE; From owner-freebsd-hackers Thu Nov 7 09:36:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA06386 for hackers-outgoing; Thu, 7 Nov 1996 09:36:57 -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 JAA06358 for ; Thu, 7 Nov 1996 09:36:51 -0800 (PST) Received: from bacall.lodgenet.com (bacall.lodgenet.com [205.138.147.242]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA17265 for ; Thu, 7 Nov 1996 09:03:52 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id KAA08836; Thu, 7 Nov 1996 10:59:46 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma008831; Thu Nov 7 10:59:44 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 KAA16821; Thu, 7 Nov 1996 10:59:54 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.7.6/8.6.12) with ESMTP id LAA24032; Thu, 7 Nov 1996 11:00:04 -0600 (CST) Message-Id: <199611071700.LAA24032@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Serge A. Babkin" cc: erich@lodgenet.com (Eric L. Hernes), hackers@FreeBSD.ORG Subject: Re: COFF->BSD converter In-reply-to: Your message of "Thu, 07 Nov 1996 21:00:37 +0500." <199611071600.VAA25791@hq.icb.chel.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 11:00:03 -0600 From: "Eric L. Hernes" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Serge A. Babkin" writes: > >Hm, I don't know. Is objcopy another thing from binutils ? > Yea, I think Mike Smith, mentioned something like ./configure --host=freebsd --target=freebsd,sco,... >> What compat libraries and headers do you need? Is the stuff from linux' >> ibcs2 any help? > >The following things can be included in a converted executable file: > >1. SCO ojbect files. Need: to be converted to BSD format (done). > >2. SCO source files. They are often used as a kind of tuning. Need: to be > >3. Compatibility libraries. They are supposed to be written in BSD > >4. BSD object files. If they want to use the functions that are > >Perhaps the iBSC2 support can't help here (except for adding some >kernel features). Unless I'm mistaken the linux ibcs2 stuff may help in 3. I was under the impression that they were distributing and/or able to build SCO shared libraries for libc/curses/..., possibly just a wrapper to their own shared libs. can anyone verify or dispell this? >> >> because the free SCO is ELF :( > >It has binary files in ELF but libraries are both for ELF and COFF. Ok, guess I didn't look close enough. > >> Is anyone working on ELF support for SCO? > >I'm wondering this too. :-) I'd be real suprised to see SOS jump on this one. Nor can I blame him for not doing so. Since we replaced his ibcs2 with NetBSD's and they seem to have SVR4 ELF compat, that's probably the place to start. > >-SB eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Thu Nov 7 09:44:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07424 for hackers-outgoing; Thu, 7 Nov 1996 09:44:35 -0800 (PST) Received: from sierra.zyzzyva.com (ppp0.zyzzyva.com [198.183.2.50]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA07396; Thu, 7 Nov 1996 09:44:23 -0800 (PST) Received: from sierra.zyzzyva.com (localhost [127.0.0.1]) by sierra.zyzzyva.com (8.7.5/8.7.3) with ESMTP id LAA17804; Thu, 7 Nov 1996 11:44:15 -0600 (CST) Message-Id: <199611071744.LAA17804@sierra.zyzzyva.com> To: freebsd-hackers@freebsd.org, freebsd-emulation@freebsd.org Subject: Virus scanning DOS software on FreeBSD X-uri: http://www.zyzzyva.com/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 11:44:15 -0600 From: Randy Terbush Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is anyone on the list aware of a way to virus scan DOS/Windoze binaries for viruses on FreeBSD? Is there a way to batch process files like this in an emulation environment? I'm not subscribed to freebsd-emulation, so please reply directly. Thanks From owner-freebsd-hackers Thu Nov 7 10:54:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA10358 for hackers-outgoing; Thu, 7 Nov 1996 10:54:32 -0800 (PST) Received: from covina.lightside.com (covina.lightside.com [207.67.176.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA10353 for ; Thu, 7 Nov 1996 10:54:30 -0800 (PST) Received: from localhost (jehamby@localhost) by covina.lightside.com (8.8.2/8.8.2) with SMTP id KAA20120 for ; Thu, 7 Nov 1996 10:54:28 -0800 (PST) Date: Thu, 7 Nov 1996 10:54:27 -0800 (PST) From: Jake Hamby To: hackers@freebsd.org Subject: Welcome to POSIX... 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 now have a copy of the NIST POSIX conformance test suite, or NIST-PCTS:151-2. Right now I'm running it on a Solaris box so I can be familiar with it before I try FreeBSD. I should note, though, two things: First, this is a test for FIPS 151-2, and not strictly POSIX.1 (it's POSIX.1 with a few additional tidbits). Second, this test suite does _NOT_ require TET to be installed, as Terry had mentioned. Perhaps I have a different test suite from what Terry was thinking of? If so, is that other test free as well? I received the test suite from Martha Gray at NIST, and as Terry mentioned, it does not yet have the proper legal notices for a more wide-spread distribution. However, as I've already discovered at least one Linux distribution which claims to be POSIX.1 and FIPS 151-2 conformant already (Linux-FT from Lasermoon), I'm going to hurry and post up my finding ASAP (it's only a matter of time before RedHat, e.g., get tested for POSIX, and we don't want to be left in the dust :-) -- Jake From owner-freebsd-hackers Thu Nov 7 10:59:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA10554 for hackers-outgoing; Thu, 7 Nov 1996 10:59:29 -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 KAA10549 for ; Thu, 7 Nov 1996 10:59:26 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10416; Thu, 7 Nov 1996 11:49:55 -0700 From: Terry Lambert Message-Id: <199611071849.LAA10416@phaeton.artisoft.com> Subject: Re: still no response To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 7 Nov 1996 11:49:55 -0700 (MST) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, julian@whistle.com, hackers@freebsd.org In-Reply-To: <199611071832.MAA11058@brasil.moneng.mei.com> from "Joe Greco" at Nov 7, 96 12:32: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 > > The session number limit is set external to the inetd (think: number of > > child processes). > > Yes, but that is not "per inetd, and it's compiled in". OK, ok: you could kludge your RC file to divorce the environment dependency. I'd prefer to see the inetd limit itself based on a parameter. 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 7 11:00:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA10657 for hackers-outgoing; Thu, 7 Nov 1996 11:00:40 -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 LAA10648 for ; Thu, 7 Nov 1996 11:00:36 -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 KAA23511; Thu, 7 Nov 1996 10:58:03 -0800 (PST) Message-ID: <32823128.446B9B3D@whistle.com> Date: Thu, 07 Nov 1996 10:57:44 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Tom Samplonius CC: hackers@freebsd.org Subject: Re: Inetd mod.. comments? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tom Samplonius wrote: > > On Wed, 6 Nov 1996, Julian Elischer wrote: > > > I have some patches to Inetd her that I sent out for comment. > > the only comment I got was > > "Gee that's neat!, I need that" > > > > but no technical reviews or code checks.. > > xinetd has done this for long time already. Why not use that? > > Tom where does one get it? From owner-freebsd-hackers Thu Nov 7 11:02:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA10794 for hackers-outgoing; Thu, 7 Nov 1996 11:02:21 -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 LAA10778 for ; Thu, 7 Nov 1996 11:02:17 -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 KAA23376; Thu, 7 Nov 1996 10:52:44 -0800 (PST) Message-ID: <32822FEA.2781E494@whistle.com> Date: Thu, 07 Nov 1996 10:52:26 -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: hackers@freebsd.org Subject: Re: limiting bandwidth on a port via forwarding References: <199611070409.PAA23969@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: > I'm more interested in the forwarding situation. Dynamic modification of the > tcp window size according to ipfw rules and the current amount of backed up > data seems like something that wouldn't be hard to impliment. Darren? As archie said... the divert code in ipfw would make this very doable.. From owner-freebsd-hackers Thu Nov 7 11:35:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA12649 for hackers-outgoing; Thu, 7 Nov 1996 11:35:09 -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 LAA12638 for ; Thu, 7 Nov 1996 11:35:06 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id LAA17788 for ; Thu, 7 Nov 1996 11:05:15 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA11112; Thu, 7 Nov 1996 13:00:57 -0600 From: Joe Greco Message-Id: <199611071900.NAA11112@brasil.moneng.mei.com> Subject: Re: still no response To: terry@lambert.org (Terry Lambert) Date: Thu, 7 Nov 1996 13:00:56 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, julian@whistle.com, hackers@freebsd.org In-Reply-To: <199611071849.LAA10416@phaeton.artisoft.com> from "Terry Lambert" at Nov 7, 96 11:49:55 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > The session number limit is set external to the inetd (think: number of > > > child processes). > > > > Yes, but that is not "per inetd, and it's compiled in". > > OK, ok: you could kludge your RC file to divorce the environment > dependency. > > I'd prefer to see the inetd limit itself based on a parameter. I am not arguing against that!! I was simply not aware that the rate limit was no longer hard coded. It would be nice to have both the rate limit AND max limit configurable from the inetd.conf file. Happy now? :-) ... JG From owner-freebsd-hackers Thu Nov 7 11:35:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA12719 for hackers-outgoing; Thu, 7 Nov 1996 11:35:25 -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 LAA12707 for ; Thu, 7 Nov 1996 11:35:24 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA17683 for ; Thu, 7 Nov 1996 10:35:55 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10376; Thu, 7 Nov 1996 11:27:25 -0700 From: Terry Lambert Message-Id: <199611071827.LAA10376@phaeton.artisoft.com> Subject: Re: still no response To: proff@suburbia.net (Julian Assange) Date: Thu, 7 Nov 1996 11:27:24 -0700 (MST) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199611070318.OAA21381@suburbia.net> from "Julian Assange" at Nov 7, 96 02:18: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 > +Lines starting with '/' in the configuration file are special directives to > +.Nm inetd . > +At present the following directives are supported: > +.Bd -literal > +/bind iface1|ANY...iface_n bind following service entries to > + these interfaces > +/bind+ iface1...iface_n as above, but add specified ifaces to > + the previous bind list > +.Ed > +.Pp > +If the iface name begins with "<", then the iface name is treated > +as a file with interface addresses listed as the first word per line. > +If the iface name is multi-homed in the DNS, then all addresses belonging > +to that iface name will be bound. Some notes on the "inetd.conf" "bind" changes... 1) Why not add an "-i" option to inetd ans start multiple inetd's? Clearly, the intent of the "<" syntax is to have seperate conf files per bound interface. 2) Why introduce state? Since a configuration for a single interface can span several pages of data, this is confusing. Did you consider an "interface:service" instead of "service" syntax instead? A single strtok() call could find the ':'. 3) Why are you binding by network number (or host name, which will be translated to network number and may in fact fail if this is run on a multi-homed host)? If you bound by interface name instead, it would be unambiguous... 4) Support for virtual hosting in inetd has already been implemented by Van Jacobsen (last I heard)... any reason to not use his code instead? I believe it requires the ability to determine the interface following an accept before the spawn via an ioctl() on the socket... 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 7 11:56:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA13878 for hackers-outgoing; Thu, 7 Nov 1996 11:56:07 -0800 (PST) Received: from love.MCCP.com (love.MCCP.com [206.86.92.190]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA13854 for ; Thu, 7 Nov 1996 11:55:57 -0800 (PST) Received: (from gena@localhost) by love.MCCP.com (8.7.6/8.6.12) id KAA00233 for hackers@freebsd.org; Thu, 7 Nov 1996 10:54:23 -0800 (PST) From: Gena Gulchin Message-Id: <199611071854.KAA00233@love.MCCP.com> Subject: IP attack To: hackers@freebsd.org Date: Thu, 7 Nov 1996 10:54:22 -0800 (PST) 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 Hello, Can somebody, please, tell me how can I increase TOLERANCE of the system for IP attacks, in other words increase number of IP connections to my system.. Any advice would be greatly appreciated -- Gena Gulchin From owner-freebsd-hackers Thu Nov 7 13:05:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16512 for hackers-outgoing; Thu, 7 Nov 1996 13:05:19 -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 NAA16490 for ; Thu, 7 Nov 1996 13:05:13 -0800 (PST) Received: from itchy.atlas.com ([206.29.170.215]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id MAA18237 for ; Thu, 7 Nov 1996 12:47:33 -0800 (PST) Received: (from brantk@localhost) by itchy.atlas.com (8.8.0/8.8.0) id MAA05939; Thu, 7 Nov 1996 12:50:20 -0800 (PST) From: Brant Katkansky Message-Id: <199611072050.MAA05939@itchy.atlas.com> Subject: Re: Inetd mod.. comments? To: julian@whistle.com (Julian Elischer) Date: Thu, 7 Nov 1996 12:50:20 -0800 (PST) Cc: tom@sdf.com, hackers@freebsd.org In-Reply-To: <32823128.446B9B3D@whistle.com> from Julian Elischer at "Nov 7, 96 10:57:44 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 > Tom Samplonius wrote: > > > > On Wed, 6 Nov 1996, Julian Elischer wrote: > > > > > I have some patches to Inetd her that I sent out for comment. > > > the only comment I got was > > > "Gee that's neat!, I need that" > > > > > > but no technical reviews or code checks.. > > > > xinetd has done this for long time already. Why not use that? > > > > Tom > where does one get it? ports/security -- Brant Katkansky (brantk@atlas.com) Software Engineer, ADC From owner-freebsd-hackers Thu Nov 7 13:53:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19199 for hackers-outgoing; Thu, 7 Nov 1996 13:53:39 -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 NAA19194 for ; Thu, 7 Nov 1996 13:53:33 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.7.6/8.7.3) with SMTP id QAA03685 for ; Thu, 7 Nov 1996 16:53:18 -0500 (EST) Date: Thu, 7 Nov 1996 16:53:17 -0500 (EST) From: John Fieber To: hackers@freebsd.org Subject: Who owns PCMCIA? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 06 Nov 1996 17:16:54 PST From: Craig Leres To: www@freebsd.org Subject: http://www.freebsd.org/handbook/handbook8.html It might be a good idea to update this and the ancillary pages to have the list of pcmcia hardware supported by freebsd. Just now I was trying to pick a pcmcia scsi controller and as far as I could tell by looking at the online handbook, no controllers are supported. But we eventually found /etc/pccard.conf and found that at least 3 different cards are supported. Craig From owner-freebsd-hackers Thu Nov 7 14:20:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA20378 for hackers-outgoing; Thu, 7 Nov 1996 14:20:25 -0800 (PST) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA20257 for ; Thu, 7 Nov 1996 14:19:00 -0800 (PST) Received: (from henrich@localhost) by crh.cl.msu.edu (8.7.6/8.7.3) id RAA03424 for freebsd-hackers@freebsd.org; Thu, 7 Nov 1996 17:18:56 -0500 (EST) From: Charles Henrich Message-Id: <199611072218.RAA03424@crh.cl.msu.edu> Subject: Linux emulation To: freebsd-hackers@freebsd.org Date: Thu, 7 Nov 1996 17:18:56 -0500 (EST) 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 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? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Thu Nov 7 14:37:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21361 for hackers-outgoing; Thu, 7 Nov 1996 14:37:05 -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 OAA21347 for ; Thu, 7 Nov 1996 14:37:01 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA18190 for ; Thu, 7 Nov 1996 12:35:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA10568; Thu, 7 Nov 1996 13:27:20 -0700 From: Terry Lambert Message-Id: <199611072027.NAA10568@phaeton.artisoft.com> Subject: Re: Welcome to POSIX... To: jehamby@lightside.com (Jake Hamby) Date: Thu, 7 Nov 1996 13:27:20 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "Jake Hamby" at Nov 7, 96 10:54:27 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 > I now have a copy of the NIST POSIX conformance test suite, or > NIST-PCTS:151-2. Right now I'm running it on a Solaris box so I can be > familiar with it before I try FreeBSD. > > I should note, though, two things: First, this is a test for FIPS 151-2, > and not strictly POSIX.1 (it's POSIX.1 with a few additional tidbits). > Second, this test suite does _NOT_ require TET to be installed, as Terry > had mentioned. Perhaps I have a different test suite from what Terry > was thinking of? If so, is that other test free as well? I already answered this. I made a mistake; the TET is required for my FABIO test suite which I have been working on. I plopped the thing into the same framework and call it from a TET environment. It was my setup, not the test itself, which required TET. I made the mistake because I was running both PCTS and SVID against UnixWare back at Novell. SVID requires TET (so does the X11 validation suite). > I received the test suite from Martha Gray at NIST, and as Terry > mentioned, it does not yet have the proper legal notices for a more > wide-spread distribution. However, as I've already discovered at least > one Linux distribution which claims to be POSIX.1 and FIPS 151-2 > conformant already (Linux-FT from Lasermoon), I'm going to hurry and post > up my finding ASAP (it's only a matter of time before RedHat, e.g., get > tested for POSIX, and we don't want to be left in the dust :-) The Linux distributor bought the suite. They ran the suite and hacked the OS iteratively to make it conform. Then they paid over $50,000 to an accredited testing lab to run the suite for them, and sign off on a conformance certificate. You personally running the test is meaningless. You can claim compliance (in a sort of carefully worded way), but not conformance. To be able to claim conformance requires certification, which requires $$$. The only thing this changes is that now you can do precertification testing without purchasing the suite. 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 7 14:37:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21520 for hackers-outgoing; Thu, 7 Nov 1996 14:37:46 -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 OAA21507 for ; Thu, 7 Nov 1996 14:37:42 -0800 (PST) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id MAA18176 for ; Thu, 7 Nov 1996 12:34:37 -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 VAA25314 for ; Thu, 7 Nov 1996 21:30:34 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id VAA23454 for hackers@freebsd.org; Thu, 7 Nov 1996 21:29:11 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.2/keltia-uucp-2.9) id UAA18008; Thu, 7 Nov 1996 20:50:02 +0100 (MET) Message-Id: <199611071950.UAA18008@keltia.freenix.fr> Date: Thu, 7 Nov 1996 20:50:01 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@freebsd.org Subject: Re: Inetd mod.. comments? References: <32823128.446B9B3D@whistle.com> X-Mailer: Mutt 0.49.07 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2675 In-Reply-To: <32823128.446B9B3D@whistle.com>; from Julian Elischer on Nov 7, 1996 10:57:44 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Julian Elischer: > > xinetd has done this for long time already. Why not use that? > > > > Tom > where does one get it? In /usr/ports/security/xinetd ? :-) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #26: Sun Oct 27 19:39:11 MET 1996 From owner-freebsd-hackers Thu Nov 7 14:37:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21547 for hackers-outgoing; Thu, 7 Nov 1996 14:37:52 -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 OAA21529 for ; Thu, 7 Nov 1996 14:37:48 -0800 (PST) Received: from ingenieria ([168.176.15.11]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id MAA18095 for ; Thu, 7 Nov 1996 12:13:20 -0800 (PST) Received: from unalslip.usc.unal.edu.co by ingenieria (SMI-8.6/SMI-SVR4) id PAA19006; Thu, 7 Nov 1996 15:08:28 +0600 Message-ID: <32826B99.7A43@ingenieria.ingsala.unal.edu.co> Date: Thu, 07 Nov 1996 15:07:05 -0800 From: "Pedro Giffuni S." Reply-To: pgiffuni@fps.biblos.unal.edu.co Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Jake Hamby CC: hackers@freebsd.org Subject: Re: Welcome to POSIX... References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jake Hamby wrote: > I should note, though, two things: First, this is a test for FIPS 151-2, > and not strictly POSIX.1 (it's POSIX.1 with a few additional tidbits). > Second, this test suite does _NOT_ require TET to be installed, as Terry > had mentioned. Perhaps I have a different test suite from what Terry > was thinking of? If so, is that other test free as well? > It was, more or less discussed that TET is an aditional test that can be use to test other conformances as well. It is more strict. The latest version isn´t free but the old versions are being ported. If you can publish or provide your result with FreeBSD current, they would be useful. Anyway we may decide not to certify ($$$!) but keep fbsd complaint. An eventual goverment contractor may find it economically advantageous to certify, but money can be better spent in other things. Pedro. > I received the test suite from Martha Gray at NIST, and as Terry > mentioned, it does not yet have the proper legal notices for a more > wide-spread distribution. However, as I've already discovered at least > one Linux distribution which claims to be POSIX.1 and FIPS 151-2 > conformant already (Linux-FT from Lasermoon), I'm going to hurry and post > up my finding ASAP (it's only a matter of time before RedHat, e.g., get > tested for POSIX, and we don't want to be left in the dust :-) > > -- Jake From owner-freebsd-hackers Thu Nov 7 14:39:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21809 for hackers-outgoing; Thu, 7 Nov 1996 14:39:08 -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 OAA21797 for ; Thu, 7 Nov 1996 14:39:04 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id LAA17853 for ; Thu, 7 Nov 1996 11:09:52 -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 LAA01331; Thu, 7 Nov 1996 11:09:50 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id GAA27414; Fri, 8 Nov 1996 06:09:42 +1100 From: Julian Assange Message-Id: <199611071909.GAA27414@suburbia.net> Subject: Re: limiting bandwidth on a port via forwarding To: julian@whistle.com (Julian Elischer) Date: Fri, 8 Nov 1996 06:09:42 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <32822FEA.2781E494@whistle.com> from "Julian Elischer" at Nov 7, 96 10:52:26 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Julian Assange wrote: > > > I'm more interested in the forwarding situation. Dynamic modification of the > > tcp window size according to ipfw rules and the current amount of backed up > > data seems like something that wouldn't be hard to impliment. Darren? > > As archie said... > the divert code in ipfw would make this very doable.. > And very expensive for a box acting as a gateway/router... -- "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 7 14:39:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21856 for hackers-outgoing; Thu, 7 Nov 1996 14:39:21 -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 OAA21844 for ; Thu, 7 Nov 1996 14:39:18 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id LAA17843 for ; Thu, 7 Nov 1996 11:09:32 -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 LAA01324; Thu, 7 Nov 1996 11:09:15 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id GAA27388; Fri, 8 Nov 1996 06:08:47 +1100 From: Julian Assange Message-Id: <199611071908.GAA27388@suburbia.net> Subject: virtual hosting with inetd To: terry@lambert.org (Terry Lambert) Date: Fri, 8 Nov 1996 06:08:46 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611071827.LAA10376@phaeton.artisoft.com> from "Terry Lambert" at Nov 7, 96 11:27:24 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > +Lines starting with '/' in the configuration file are special directives to > > +.Nm inetd . > > +At present the following directives are supported: > > +.Bd -literal > > +/bind iface1|ANY...iface_n bind following service entries to > > + these interfaces > > +/bind+ iface1...iface_n as above, but add specified ifaces to > > + the previous bind list > > +.Ed > > +.Pp > > +If the iface name begins with "<", then the iface name is treated > > +as a file with interface addresses listed as the first word per line. > > +If the iface name is multi-homed in the DNS, then all addresses belonging > > +to that iface name will be bound. > > Some notes on the "inetd.conf" "bind" changes... > > 1) Why not add an "-i" option to inetd ans start multiple inetd's? > Clearly, the intent of the "<" syntax is to have seperate conf > files per bound interface. There is already an "-a" option. The '<' is used so one can automate the addition of particular classes of interfaces (virtual hosts), by simple having those addresses in a "hosts" type file, that can also be used for other things, such as setting up the interface alias addresses in the first place. Further, such a list could be very large and therefor not in keeping with placing in inetd.conf The general idea behind my changes this: a) many systems now run as "virtual" sites, depending on IP. Some systems have hundreds or thousands of such addresses. b) one should not need to run more than one inetd c) the majority of services with be uniform accross ifaces; therefor only the differences between ifaces should be different. The case of having multiple inetd.conf's flies in the face of all configuration file theory ;) and will in the majority of circumstances require idential changes to every inetd.conf file when a service entry needs changing. d) the accounting features of inetd should be unified. e) configuration files should be efficient and visually pleasing. > 2) Why introduce state? Since a configuration for a single > interface can span several pages of data, this is confusing. > Did you consider an "interface:service" instead of "service" > syntax instead? A single strtok() call could find the ':'. I thought about this idea, and decided against it on the basis that it would introduce possible large scale data duplication and very ugly config lines. State is good. Natural language uses it all the time. It makes things more efficient ;) > 3) Why are you binding by network number (or host name, which will > be translated to network number and may in fact fail if this is > run on a multi-homed host)? If you bound by interface name > instead, it would be unambiguous... I didn't believe I was binding by network number...? > 4) Support for virtual hosting in inetd has already been implemented > by Van Jacobsen (last I heard)... any reason to not use his code > instead? I believe it requires the ability to determine the > interface following an accept before the spawn via an ioctl() > on the socket... getsockname(). I didn't use this, as it requires checking only after the connection is made. This latter method is flawed, as you may not want a service bound to every interface, you may want it handled out side of inetd, or have no listening process on it at all. -- "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 7 14:39:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21907 for hackers-outgoing; Thu, 7 Nov 1996 14:39:28 -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 OAA21872 for ; Thu, 7 Nov 1996 14:39:23 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA17678 for ; Thu, 7 Nov 1996 10:35:06 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA11058; Thu, 7 Nov 1996 12:32:34 -0600 From: Joe Greco Message-Id: <199611071832.MAA11058@brasil.moneng.mei.com> Subject: Re: still no response To: terry@lambert.org (Terry Lambert) Date: Thu, 7 Nov 1996 12:32:34 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, terry@lambert.org, julian@whistle.com, hackers@freebsd.org In-Reply-To: <199611071819.LAA10340@phaeton.artisoft.com> from "Terry Lambert" at Nov 7, 96 11:18:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > The inetd already has a session limit. It's just not per service, it's > > > per inetd, and it's compiled in. > > > > I thought that was a session spawning rate limit - not a session number > > limit. Maybe I am wrong. > > The spawning rate limit is a soft limit. Sorry, you are right. It _used_ to be a hard limit, and it used to be compiled in. I'm remembering running into this on *OS and having to build my own inetd from BSD sources so that I could play hack-the-constant... > The session number limit is set external to the inetd (think: number of > child processes). Yes, but that is not "per inetd, and it's compiled in". ... JG From owner-freebsd-hackers Thu Nov 7 14:39:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21928 for hackers-outgoing; Thu, 7 Nov 1996 14:39:31 -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 OAA21886 for ; Thu, 7 Nov 1996 14:39:25 -0800 (PST) Received: from pluto.plutotech.com (root@pluto.plutotech.com [206.168.67.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA17675 for ; Thu, 7 Nov 1996 10:35:05 -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 LAA25115 for ; Thu, 7 Nov 1996 11:35:04 -0700 (MST) Message-Id: <199611071835.LAA25115@pluto.plutotech.com> From: "Mike Durian" To: freebsd-hackers@freebsd.org Subject: small bugs in pci code Date: Thu, 07 Nov 1996 11:35:09 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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. 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) Notice the mask has changed from 0xff00 to 0xf000. This is because the lower nibble is not part of the address, but instead determines if the addressing is 16 bit or 32 bit. 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." 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. mike From owner-freebsd-hackers Thu Nov 7 14:39:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21957 for hackers-outgoing; Thu, 7 Nov 1996 14:39: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 OAA21922 for ; Thu, 7 Nov 1996 14:39:30 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA17767 for ; Thu, 7 Nov 1996 10:50:35 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA17516; Thu, 7 Nov 1996 13:50:03 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 7 Nov 1996 13: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 MAA08502; Thu, 7 Nov 1996 12:53:33 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id MAA03193; Thu, 7 Nov 1996 12:54:35 -0500 (EST) Date: Thu, 7 Nov 1996 12:54:35 -0500 (EST) From: Thomas David Rivers Message-Id: <199611071754.MAA03193@lakes.water.net> To: michaelh@cet.co.jp, ponds!Root.COM!dg@ucbvax.Berkeley.EDU Subject: Re: More info on the daily panics... Cc: ponds!freefall.freebsd.org!freebsd-hackers@ucbvax.Berkeley.EDU, ponds!ponds!rivers@ucbvax.Berkeley.EDU Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > In the one case of this problem that I looked into, it was caused by the > > v_usecount being negative. There was clearly one too many vrele's occuring > > somewhere. It was not caused by any sort of "freelist wrap" condition. The > > patch you've provided will kludge around the problem, but it is not in any > > sense a "fix". Each time a vnode is deallocated too many times (and thus > > v_usecount goes negative), you'll end up losing all of the vnodes on the > > freelist that follow it (potentially several thousand) because the condition > > will never go away. This is bad. > > Then Thomas would be doing us a favor if he put in the following diff to > help track it down: > Ask and ye shall receive.... I think the original patch was in reverse order; here's what I've done relative to 2.1.5-STABLE. By the way, it's Dave, not Thomas... It's a southern idiocyncratic 'feature' to use your middle-name as your familiar title, not your first. So, why don't I do that in the GECOS field of my passwd entry?... well, that's an entirely different issue, involving my father, his father and some issues with the banking establishment.. :-) :-) - Dave R. - *** vfs_subr.c.ori Thu Nov 7 12:46:24 1996 --- vfs_subr.c Thu Nov 7 12:49:24 1996 *************** *** 828,839 **** vp->v_usecount--; if (vp->v_usecount > 0) return; - #ifdef DIAGNOSTIC if (vp->v_usecount != 0 /* || vp->v_writecount != 0 */ ) { vprint("vrele: bad ref count", vp); panic("vrele: ref cnt"); } - #endif if (vp->v_flag & VAGE) { TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); vp->v_flag &= ~VAGE; --- 828,839 ---- vp->v_usecount--; if (vp->v_usecount > 0) return; if (vp->v_usecount != 0 /* || vp->v_writecount != 0 */ ) { + #ifdef DIAGNOSTIC vprint("vrele: bad ref count", vp); + #endif panic("vrele: ref cnt"); } if (vp->v_flag & VAGE) { TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); vp->v_flag &= ~VAGE; From owner-freebsd-hackers Thu Nov 7 14:40:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22174 for hackers-outgoing; Thu, 7 Nov 1996 14:40:24 -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 OAA22127 for ; Thu, 7 Nov 1996 14:40:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA17641 for ; Thu, 7 Nov 1996 10:28:30 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10340; Thu, 7 Nov 1996 11:19:00 -0700 From: Terry Lambert Message-Id: <199611071819.LAA10340@phaeton.artisoft.com> Subject: Re: still no response To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 7 Nov 1996 11:18:59 -0700 (MST) Cc: terry@lambert.org, julian@whistle.com, hackers@freebsd.org In-Reply-To: <199611070342.VAA10194@brasil.moneng.mei.com> from "Joe Greco" at Nov 6, 96 09:42:51 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 > > The inetd already has a session limit. It's just not per service, it's > > per inetd, and it's compiled in. > > I thought that was a session spawning rate limit - not a session number > limit. Maybe I am wrong. The spawning rate limit is a soft limit. The session number limit is set external to the inetd (think: number of child processes). 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 7 14:40:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22296 for hackers-outgoing; Thu, 7 Nov 1996 14:40:52 -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 OAA22269; Thu, 7 Nov 1996 14:40:45 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA17616 ; Thu, 7 Nov 1996 10:22:55 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10315; Thu, 7 Nov 1996 11:13:59 -0700 From: Terry Lambert Message-Id: <199611071813.LAA10315@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: dg@root.com Date: Thu, 7 Nov 1996 11:13:59 -0700 (MST) Cc: ponds!rivers@dg-rtp.dg.com, terry@lambert.org, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199611070813.AAA02988@root.com> from "David Greenman" at Nov 7, 96 00:13: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 > > After Terry signs off on this, can someone get it committed to > >2.1.6 (nee 2.1.5-STABLE)... > > I think there is a lot of misinformation being bandied about this problem. > In the one case of this problem that I looked into, it was caused by the > v_usecount being negative. There was clearly one too many vrele's occuring > somewhere. It was not caused by any sort of "freelist wrap" condition. The > patch you've provided will kludge around the problem, but it is not in any > sense a "fix". Each time a vnode is deallocated too many times (and thus > v_usecount goes negative), you'll end up losing all of the vnodes on the > freelist that follow it (potentially several thousand) because the condition > will never go away. This is bad. The intent of the fix is to prevent improper vnode reuse around list expansion time, not to kludge multiple frees. The multiple free panic should occur in the vrele(). It should be an assert or other compile time debug option, since it is in the critical path for what *should* be a fast operation and *should* never happen. The effect of the things are unrelated, but similar in appearance. This patch *is* a kludge: it's a kludge against the fact that there is a two stage decommit (which is itself a kludge, with no way to recover perfectly valid data hung off an in core vnode buffer list pointer once the FS data has been dissociated from that vnode). The problem is the race conditions in the two stage decommit during a period of incresing demand and high vnode reuse. Multiple vrele()'s are a seperate problem with similar symptoms, but the symptoms evidence at a slightly different time. A multiple vrele will result in the panic on an increasing usecount. A multiple allocation of the same vnode at list grow time will result in a delayed crash effect at a later time, not necessarily (but possibly) on an increasing usecount. If you are really concerned that this will mask a future multiple vrele() problem, I suggest you put the assert in vrele() and prevent the queue from ever getting corrupted that way in the first place. This is a horse-out-of-the-barn issue, in any case, since it means a significant coding error in one FS or another for it to happen. The wrap error, on the other hand, just needs the right timing window on a WAIT memory allocation... generally on a busy machine, where the boundry crossing of the high water mark will be relatively frequent. If you are in the assert-generating mood, I'd also suggest a verification macro to be called inside every VTOI()/ITOV() operation to verify that the inode the vnode points to point to the same vnode, and that the vnode the inode points to points to the same inode (depending on the op). You would probably have to make them into function calls, which would mean moving references to them out of the data declarations for some auto variables in a lot of places (the code generated should remain the same -- data declaration constant relative references are shorthand only, and have no real ability to affect code compactness). Since it would happen all over the place, this would be too expensive to leave on in a GENERIC kernel, but would catch both the problem you are concerned about, the one I'm concerned about, and other error cases which neither of us may have considered. 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 7 14:41:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22469 for hackers-outgoing; Thu, 7 Nov 1996 14:41:47 -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 OAA22459 for ; Thu, 7 Nov 1996 14:41:41 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.222]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA17489 for ; Thu, 7 Nov 1996 10:02:40 -0800 (PST) Received: (from smtpd@localhost) by profane.iq.org (8.8.2/8.8.2) id AAA01322 for ; Fri, 8 Nov 1996 00:19:50 +1100 (EST) Message-Id: <199611071319.AAA01322@profane.iq.org> Received: from localhost(127.0.0.1), claiming to be "profane.iq.org" via SMTP by localhost, id smtpd001024; Thu Nov 7 06:28:02 1996 To: hackers@freebsd.org Subject: patches for nice text modes (170x48x16 etc) (syscons.c) Date: Thu, 07 Nov 1996 17:28:00 +1100 From: Julian Assange Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --- sys/i386/isa/syscons.c.orig Thu Oct 17 00:51:11 1996 +++ sys/i386/isa/syscons.c Fri Oct 18 05:19:47 1996 @@ -195,6 +195,7 @@ static void set_vgaregs(char *modetable); static void set_font_mode(void); static void set_normal_mode(void); +static int change_mode (struct tty *tp, scr_stat *scp, int mode); static void set_destructive_cursor(scr_stat *scp); static void set_mouse_pos(scr_stat *scp); static void mouse_cut_start(scr_stat *scp); @@ -840,62 +841,10 @@ case SW_ENH_B40x25: case SW_ENH_C40x25: case SW_ENH_B80x25: case SW_ENH_C80x25: case SW_ENH_B80x43: case SW_ENH_C80x43: - + case SW_USER: if (!crtc_vga || video_mode_ptr == NULL) return ENXIO; - switch (cmd & 0xff) { - case M_VGA_C80x60: case M_VGA_M80x60: - if (!(fonts_loaded & FONT_8)) - return EINVAL; - scp->xsize = 80; - scp->ysize = 60; - break; - case M_VGA_C80x50: case M_VGA_M80x50: - if (!(fonts_loaded & FONT_8)) - return EINVAL; - scp->xsize = 80; - scp->ysize = 50; - break; - case M_ENH_B80x43: case M_ENH_C80x43: - if (!(fonts_loaded & FONT_8)) - return EINVAL; - scp->xsize = 80; - scp->ysize = 43; - break; - case M_VGA_C80x30: case M_VGA_M80x30: - scp->xsize = 80; - scp->ysize = 30; - break; - default: - if ((cmd & 0xff) > M_VGA_CG320) - return EINVAL; - else - scp->xsize = *(video_mode_ptr+((cmd&0xff)*64)); - scp->ysize = *(video_mode_ptr+((cmd&0xff)*64)+1)+1; - break; - } - scp->mode = cmd & 0xff; - free(scp->scr_buf, M_DEVBUF); - scp->scr_buf = (u_short *) - malloc(scp->xsize*scp->ysize*sizeof(u_short), M_DEVBUF, M_WAITOK); - scp->cursor_pos = scp->cursor_oldpos = - scp->scr_buf + scp->xpos + scp->ypos * scp->xsize; - scp->mouse_pos = scp->mouse_oldpos = - scp->scr_buf + ((scp->mouse_ypos/scp->font_size)*scp->xsize + - scp->mouse_xpos/8); - free(cut_buffer, M_DEVBUF); - cut_buffer = (char *)malloc(scp->xsize*scp->ysize, M_DEVBUF, M_NOWAIT); - cut_buffer[0] = 0x00; - if (scp == cur_console) - set_mode(scp); - scp->status &= ~UNKNOWN_MODE; - clear_screen(scp); - if (tp->t_winsize.ws_col != scp->xsize - || tp->t_winsize.ws_row != scp->ysize) { - tp->t_winsize.ws_col = scp->xsize; - tp->t_winsize.ws_row = scp->ysize; - pgsignal(tp->t_pgrp, SIGWINCH, 1); - } + change_mode(tp, scp, cmd&0xff); return 0; /* GRAPHICS MODES */ @@ -906,7 +855,7 @@ if (!crtc_vga || video_mode_ptr == NULL) return ENXIO; - scp->mode = cmd & 0xFF; + scp->mode = cmd&0xff; scp->xpixel = (*(video_mode_ptr + (scp->mode*64))) * 8; scp->ypixel = (*(video_mode_ptr + (scp->mode*64) + 1) + 1) * (*(video_mode_ptr + (scp->mode*64) + 2)); @@ -1004,6 +953,21 @@ *data = get_scr_num()+1; return 0; + case VT_RESIZE: /* proff */ + { + int n; + vt_consize_t *v = (vt_consize_t*)data; + for (n=0; nysize = v->v_rows; /* number of rows */ + console[n]->xsize = v->v_cols; /* number of columns */ + change_mode(VIRTUAL_TTY(n), console[n], M_USER); + } + } + } + case KDENABIO: /* allow io operations */ error = suser(p->p_ucred, &p->p_acflag); if (error != 0) @@ -1021,7 +985,7 @@ switch (*data) { case KD_TEXT: /* switch to TEXT (known) mode */ /* restore fonts & palette ! */ - if (crtc_vga) { + if (crtc_vga && scp->mode != M_USER) { if (fonts_loaded & FONT_8) copy_font(LOAD, FONT_8, font_8); if (fonts_loaded & FONT_14) @@ -2569,6 +2533,10 @@ history_to_screen(cur_console); } switch (scancode) { + case 0x53: /* grey delete key */ + change_mode(VIRTUAL_TTY(get_scr_num()), cur_console, M_VGA_C80x25); + goto next_code; + case 0x47: /* home key */ cur_console->history_pos = cur_console->history_head; history_to_screen(cur_console); @@ -2951,6 +2919,9 @@ /* setup video hardware for the given mode */ switch (scp->mode) { + case M_USER: + return; + case M_VGA_M80x60: bcopyw(video_mode_ptr+(64*M_VGA_M80x25), &special_modetable, 64); goto special_80x60; @@ -3051,6 +3022,67 @@ /* set border color for this (virtual) console */ set_border(scp->border); return; +} + +static int +change_mode (struct tty *tp, scr_stat *scp, int mode) +{ + switch (mode) { + case M_VGA_C80x60: case M_VGA_M80x60: + if (!(fonts_loaded & FONT_8)) + return EINVAL; + scp->xsize = 80; + scp->ysize = 60; + break; + case M_VGA_C80x50: case M_VGA_M80x50: + if (!(fonts_loaded & FONT_8)) + return EINVAL; + scp->xsize = 80; + scp->ysize = 50; + break; + case M_ENH_B80x43: case M_ENH_C80x43: + if (!(fonts_loaded & FONT_8)) + return EINVAL; + scp->xsize = 80; + scp->ysize = 43; + break; + case M_VGA_C80x30: case M_VGA_M80x30: + scp->xsize = 80; + scp->ysize = 30; + break; + case M_USER: + break; + default: + if (mode > M_VGA_CG320) + return EINVAL; + else + scp->xsize = *(video_mode_ptr+((mode)*64)); + scp->ysize = *(video_mode_ptr+((mode)*64)+1)+1; + break; + } + scp->mode = mode; + free(scp->scr_buf, M_DEVBUF); + scp->scr_buf = (u_short *) + malloc(scp->xsize*scp->ysize*sizeof(u_short), M_DEVBUF, M_WAITOK); + scp->cursor_pos = scp->cursor_oldpos = + scp->scr_buf + scp->xpos + scp->ypos * scp->xsize; + scp->mouse_pos = scp->mouse_oldpos = + scp->scr_buf + ((scp->mouse_ypos/scp->font_size)*scp->xsize + + scp->mouse_xpos/8); + free(cut_buffer, M_DEVBUF); + cut_buffer = (char *)malloc(scp->xsize*scp->ysize, M_DEVBUF, M_NOWAIT); + cut_buffer[0] = 0x00; + if (scp == cur_console) + set_mode(scp); + scp->status &= ~UNKNOWN_MODE; + clear_screen(scp); + if (tp->t_winsize.ws_col != scp->xsize + || tp->t_winsize.ws_row != scp->ysize) { + tp->t_winsize.ws_col = scp->xsize; + tp->t_winsize.ws_row = scp->ysize; + pgsignal(tp->t_pgrp, SIGWINCH, 1); + } + return 0; } void --- sys/i386/include/console.h.orig Thu Oct 17 01:10:16 1996 +++ sys/i386/include/console.h Thu Oct 17 02:55:17 1996 @@ -91,6 +91,7 @@ #define VT_ACTIVATE _IO('v', 5) #define VT_WAITACTIVE _IO('v', 6) #define VT_GETACTIVE _IOR('v', 7, int) +#define VT_RESIZE _IOW('v', 8, vt_consize_t) /* set kernel's idea of screensize */ #define VT_FALSE 0 #define VT_TRUE 1 @@ -219,6 +220,15 @@ u_char mk_keylock; }; +struct vt_consize { + unsigned short v_rows; /* number of rows */ + unsigned short v_cols; /* number of columns */ + unsigned short v_vlin; /* number of pixel rows on screen */ + unsigned short v_clin; /* number of pixel rows per character */ + unsigned short v_vcol; /* number of pixel columns on screen */ + unsigned short v_ccol; /* number of pixel columns per character */ +}; + #define MAXSSAVER 16 struct ssaver { @@ -232,6 +242,7 @@ typedef struct fkeyarg fkeyarg_t; typedef struct vid_info vid_info_t; typedef struct vt_mode vtmode_t; +typedef struct vt_consize vt_consize_t; typedef struct mouse_info mouse_info_t; typedef struct {char scrmap[256];} scrmap_t; typedef struct {char fnt8x8[8*256];} fnt8_t; @@ -335,6 +346,8 @@ #define M_VGA_C80x60 34 /* vga 8x8 font on color */ #define M_VGA_M80x60 35 /* vga 8x8 font on color */ +#define M_USER 36 /* user defined mode */ + #define M_ENH_B80x43 0x70 /* ega black & white 80x43 */ #define M_ENH_C80x43 0x71 /* ega color 80x43 */ #define M_HGC_P0 0xe0 /* hercules graphics - page 0 @ B0000 */ @@ -382,6 +395,7 @@ #define SW_CG640x480 _IO('S', M_VGA12) #define SW_VGA13 _IO('S', M_VGA13) #define SW_VGA_CG320 _IO('S', M_VGA13) +#define SW_USER _IO('S', M_USER) #endif /* PC98 */ #endif /* !_MACHINE_CONSOLE_H_ */ From owner-freebsd-hackers Thu Nov 7 14:41:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22507 for hackers-outgoing; Thu, 7 Nov 1996 14:41:52 -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 OAA22491 for ; Thu, 7 Nov 1996 14:41:50 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.222]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA17490 for ; Thu, 7 Nov 1996 10:02:43 -0800 (PST) Received: (from smtpd@localhost) by profane.iq.org (8.8.2/8.8.2) id AAA01321 for ; Fri, 8 Nov 1996 00:19:50 +1100 (EST) Message-Id: <199611071319.AAA01321@profane.iq.org> Received: from localhost(127.0.0.1), claiming to be "profane.iq.org" via SMTP by localhost, id smtpd001256; Thu Nov 7 06:50:23 1996 To: freebsd-hackers@freebsd.org Subject: patches for nice text modes (SVGATextMode-1.4-src) Date: Thu, 07 Nov 1996 17:50:19 +1100 From: Julian Assange Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk These patches are against: ftp://sunsite.unc.edu/pub/Linux/utils/console/SVGATextMode-1.4-src.tar.gz diff -N -u -r old/SVGATextMode-1.4-src/Makefile SVGATextMode-1.4-src/Makefile --- old/SVGATextMode-1.4-src/Makefile Sun Sep 22 20:54:34 1996 +++ SVGATextMode-1.4-src/Makefile Thu Nov 7 17:41:36 1996 @@ -8,7 +8,7 @@ # - DJGPP 2.0 # -ARCH=$(shell arch) +ARCH=i386 CFLAGS_alpha = CFLAGS_i386 = -pipe CFLAGS_i486 = $(CFLAGS_i386) -m486 @@ -138,7 +138,7 @@ PAL_OBJECTS = setpalette.o vga_prg.o string_ops.o messages.o file_ops.o kversion.o -GRAB_OBJECTS = grabmode.o modedata.o probe.o wait_vsync.o vga_prg.o messages.o string_ops.o +GRAB_OBJECTS = grabmode.o modedata.o probe.o wait_vsync.o vga_prg.o messages.o string_ops.o file_ops.o #PCLKS_OBJECTS = probeclocks.o messages.o vga_prg.o setclock.o file_ops.o \ # run_extprog.o clockchip.o std_clock.o modedata.o probe.o wait_vsync.o diff -N -u -r old/SVGATextMode-1.4-src/SVGATextMode.c SVGATextMode-1.4-src/SVGATextMode.c --- old/SVGATextMode-1.4-src/SVGATextMode.c Fri May 31 04:43:50 1996 +++ SVGATextMode-1.4-src/SVGATextMode.c Fri Oct 18 01:57:50 1996 @@ -34,7 +34,7 @@ #include #include -#ifndef DOS +#ifdef linux # include # include # include @@ -291,8 +291,10 @@ * first see if current kernel version supports resizing. */ +#ifdef linux if (!check_kernel_version(1,1,54, "Virtual Terminal resizing")) PERROR(("Screen resizing not allowed (kernel version must be >= 1.1.54). Use a non-resizing text mode, or upgrade your kernel.\n")); +#endif /* * Resize the screen. Still needs LOTS more error checking to avoid dropping out in the middle, leaving @@ -308,9 +310,11 @@ * until those kernel programmers make this unambiguous */ +#ifdef linux if (do_VT_RESIZE(curr_textmode->cols, curr_textmode->rows, resize1x1)) sresize=TRUE; if (check_kernel_version(1,3,3, "VT_RESIZEX")) +#endif { /* * VDisplay must de divided by 2 for DoubleScan modes, @@ -332,11 +336,13 @@ * a call to VT_RESIZE) */ +#ifdef linux if (!check_kernel_version(1,3,3, "Automatic TTY resizing (SIGWINCH)")) { if (p_terminals) resize_specified_vts(curr_textmode->cols, curr_textmode->rows); else resize_active_vts(curr_textmode->cols, curr_textmode->rows); } +#endif } # else @@ -386,8 +392,10 @@ Set_Textmode; /* just in case some jerk set us in graphics mode. Or if he's in X-windows: surprise surprise ! */ #ifndef DOS +#ifndef __FreeBSD__ /* set console to text mode */ ioctl(opentty("/dev/console"), KDSETMODE, KD_TEXT); +#endif #endif if (set_charwidth(curr_textmode->FontWidth)) PERROR(("Illegal character width: %d\n",curr_textmode->FontWidth)); diff -N -u -r old/SVGATextMode-1.4-src/TextConfig SVGATextMode-1.4-src/TextConfig --- old/SVGATextMode-1.4-src/TextConfig Sun Sep 15 21:27:06 1996 +++ SVGATextMode-1.4-src/TextConfig Fri Oct 18 03:00:56 1996 @@ -60,8 +60,8 @@ # This is for a "generic" VGA card. It should work on ANY VGA card, but can # only use the first 4 clocks -Chipset "VGA" -Clocks 25.175 28.322 +#Chipset "VGA" +#Clocks 25.175 28.322 echo "The SVGATextMode config file is configured as `standard VGA' by default." echo "This is highly sub-optimal on modern VGA cards." @@ -74,7 +74,7 @@ # # Now come the SVGA chipsets -#ChipSet "S3" +ChipSet "S3" #Clocks 25.175 28.322 40.00 0.00 50.00 77.00 36.00 44.90 #Clocks 130.00 120.00 80.00 31.50 110.00 65.00 75.00 94.50 @@ -87,7 +87,7 @@ #ClockChip "sc11412" #ClockChip "s3gendac" #ClockChip "s3_sdac" -#ClockChip "S3Trio" +ClockChip "S3Trio" #ClockChip "S3Virge" #ClockChip "ti3025" #ClockChip "ics2595" @@ -108,7 +108,7 @@ #Option "SLOW_DRAM" #Option "MED_DRAM" #Option "FAST_DRAM" -#Option "XFAST_DRAM" +Option "XFAST_DRAM" # This option enables S3 high-speed text modes for pixel clocks > 36 MHz. # USE WITH CAUTION! This needs a different font format in VGA memory. Read @@ -118,7 +118,7 @@ # before strange effects appear. Older S3 cards (911, 924, 928, ...) need # this option for modes with >36 MHz pixel clocks -#Option "S3_HSText" +Option "S3_HSText" # IBM RGB RAMDAC's absolutely _need_ this. You will have to copy this value # from the output of the XFree86 server startup messages. MAKE SURE THIS @@ -283,7 +283,7 @@ # cards, and is useless on cards with a programmable clock chip. # Cirrus cards seem not to like this feature! # -Option "ClockDiv2" +#Option "ClockDiv2" ############################################################################# # @@ -388,13 +388,21 @@ # Option "LoadFont" -FontProg "/usr/bin/setfont" -FontPath "/usr/lib/kbd/consolefonts" -FontSelect "Cyr_a8x16" 8x16 9x16 8x15 9x15 -FontSelect "Cyr_a8x14" 8x14 9x14 8x13 9x13 -FontSelect "8x12alt.psf" 8x12 9x12 8x11 9x11 -FontSelect "Cyr_a8x8" 8x8 9x8 8x7 9x7 -FontSelect "Cyr_a8x32" 8x32 9x32 8x31 9x31 +#FontProg "./setfont" +#FontPath "." +#FontSelect "Cyr_a8x16" 8x16 9x16 8x15 9x15 +#FontSelect "Cyr_a8x14" 8x14 9x14 8x13 9x13 +#FontSelect "8x12alt.psf" 8x12 9x12 8x11 9x11 +#FontSelect "Cyr_a8x8" 8x8 9x8 8x7 9x7 +#FontSelect "Cyr_a8x32" 8x32 9x32 8x31 9x31 + +FontProg "./vidcontrol-setfont" +FontPath "/usr/share/syscons/fonts" +FontSelect "iso-8x16.fnt" 8x16 9x16 8x15 9x15 +#FontSelect "Cyr_a8x14" 8x14 9x14 8x13 9x13 +#FontSelect "8x12alt.psf" 8x12 9x12 8x11 9x11 +#FontSelect "Cyr_a8x8" 8x8 9x8 8x7 9x7 +#FontSelect "Cyr_a8x32" 8x32 9x32 8x31 9x31 # # using the following FontProg line will avoid losing high-ascii characters @@ -425,8 +433,8 @@ # to the monitor! See your monitor's user's manual for details. # -#HorizSync 30-32 -#VertRefresh 50-80 +HorizSync 30-82 +VertRefresh 40-110 ############################################################################# @@ -450,7 +458,7 @@ # hardware. # -#DacSpeed 45 +DacSpeed 155.50 ############################################################################# # @@ -935,3 +943,4 @@ # newer TextConfig file is just a matter of cutting and pasting this bottom # part into your new TextConfig file. # +"ETbig" 80.0 1360 1368 1488 1656 767 767 773 795 font 8x16 diff -N -u -r old/SVGATextMode-1.4-src/XFREE/Makefile SVGATextMode-1.4-src/XFREE/Makefile --- old/SVGATextMode-1.4-src/XFREE/Makefile Thu Jun 13 05:11:56 1996 +++ SVGATextMode-1.4-src/XFREE/Makefile Fri Oct 18 01:57:50 1996 @@ -26,7 +26,7 @@ libxf86_hw.a: $(OBJECTS) $(ASMOBJS) - ar rcs libxf86_hw.a $(OBJECTS) $(ASMOBJS) + ar rc libxf86_hw.a $(OBJECTS) $(ASMOBJS) $(OBJECTS): %.o: %.c $(CC) -c $(CFLAGS) $(XFREEINC) $(XFREECOMPAT) $< -o $@ diff -N -u -r old/SVGATextMode-1.4-src/XFREE/common/compiler.h SVGATextMode-1.4-src/XFREE/common/compiler.h --- old/SVGATextMode-1.4-src/XFREE/common/compiler.h Mon Oct 30 03:31:14 1995 +++ SVGATextMode-1.4-src/XFREE/common/compiler.h Fri Oct 18 01:57:50 1996 @@ -75,6 +75,9 @@ #ifdef __GNUC__ #if defined(__i386__) +#if defined(__FreeBSD__) +# define GCCUSESGAS +#endif #ifndef FAKEIT #ifdef GCCUSESGAS diff -N -u -r old/SVGATextMode-1.4-src/clockchip.c SVGATextMode-1.4-src/clockchip.c --- old/SVGATextMode-1.4-src/clockchip.c Sun Sep 15 21:19:32 1996 +++ SVGATextMode-1.4-src/clockchip.c Fri Oct 18 01:57:50 1996 @@ -24,7 +24,7 @@ #include #include #ifndef DOS -# include +# include "io.h" #endif #include "misc.h" #include "vga_prg.h" diff -N -u -r old/SVGATextMode-1.4-src/contrib/vgaset/Makefile SVGATextMode-1.4-src/contrib/vgaset/Makefile --- old/SVGATextMode-1.4-src/contrib/vgaset/Makefile Thu Jun 13 05:03:22 1996 +++ SVGATextMode-1.4-src/contrib/vgaset/Makefile Fri Oct 18 01:57:50 1996 @@ -5,11 +5,11 @@ # set COMMON to the pathname of the x386/common/compile.h header file CC=gcc -CFLAGS= -O3 -s $(HAS_USL_VTS) +CFLAGS= -g -O3 $(HAS_USL_VTS) -DGCCUSESGAS vgaset: vgaset.c svga.h $(CC) $(CFLAGS) vgaset.c -o vgaset clean: rm -f vgaset *~ *.bak *.o - \ No newline at end of file + diff -N -u -r old/SVGATextMode-1.4-src/contrib/vgaset/vgaset.c SVGATextMode-1.4-src/contrib/vgaset/vgaset.c --- old/SVGATextMode-1.4-src/contrib/vgaset/vgaset.c Wed Jan 25 07:28:43 1995 +++ SVGATextMode-1.4-src/contrib/vgaset/vgaset.c Fri Oct 18 01:57:50 1996 @@ -31,7 +31,11 @@ #include "compiler.h" /* this should be the x386/common/compiler.h */ #endif #ifdef HAS_USL_VTS +#ifdef __FreeBSD__ +#include +#else #include +#endif #define CONSOLE "/dev/console" /* name of console */ int console; /* file descriptor for console */ @@ -119,12 +123,14 @@ perror ("Can't disable IO ports"); exit (status + 1); } +#ifndef __FreeBSD__ if (ioctl (console, KDDELIO, 0x3BF) < 0) /* delete port number */ { perror ("Can't delete IO ports"); exit (status + 1); } #endif +#endif if (tcsetattr (0, TCSAFLUSH, &prior_term_status)) { printf ("Can't set terminal attributes for stdin: %s\n", strerror (errno)); @@ -448,11 +454,13 @@ perror ("Can't open /dev/console"); exit (1); } +#ifndef __FreeBSD__ if (ioctl (console, KDADDIO, 0x3BF) < 0) /* add port to list */ { perror ("Can't add I/O port 0x3bf"); exit (1); } +#endif if (ioctl (console, KDENABIO, 0) < 0) { perror ("Can't enable port I/O"); diff -N -u -r old/SVGATextMode-1.4-src/grabmode.c SVGATextMode-1.4-src/grabmode.c --- old/SVGATextMode-1.4-src/grabmode.c Thu Feb 22 06:50:36 1996 +++ SVGATextMode-1.4-src/grabmode.c Fri Oct 18 02:20:29 1996 @@ -162,7 +162,7 @@ PWARNING(("Please be patient. This may take a while (up to 1 minute)\n")); - getmode(&m, probe_clock, raw_mode, initial_x, initial_y); + vgagetmode(&m, probe_clock, raw_mode, initial_x, initial_y); if (func == CLOCKPROBE) { diff -N -u -r old/SVGATextMode-1.4-src/io.h SVGATextMode-1.4-src/io.h --- old/SVGATextMode-1.4-src/io.h Thu Jan 1 10:00:00 1970 +++ SVGATextMode-1.4-src/io.h Fri Oct 18 02:06:49 1996 @@ -0,0 +1,28 @@ +/* $Id:$ */ +#ifndef IO_H +#define IO_H + +#ifndef DOS +#ifdef linux +# include +#else +# include "XFREE/common/compiler.h" +# define outb(x,y) outb((y),(x)) +# define outw(x,y) outw((y),(x)) +#endif +#else /* DOS */ +# ifdef DJGPP +# include +# define outb(data,port) outportb(port,data) +# define outw(data,port) outportw(port,data) +# define inb(port) inportb(port) +# define inw(port) inportw(port) +# else /* Borland C */ +# define outb(data,port) outp(port,data) +# define outw(data,port) outpw(port,data) +# define inb(port) inp(port) +# define inw(port) inpw(port) +# endif +#endif + +#endif /* IO_H */ diff -N -u -r old/SVGATextMode-1.4-src/modedata.c SVGATextMode-1.4-src/modedata.c --- old/SVGATextMode-1.4-src/modedata.c Thu Mar 7 06:53:04 1996 +++ SVGATextMode-1.4-src/modedata.c Fri Oct 18 01:57:50 1996 @@ -28,7 +28,7 @@ #ifndef DOS #include -#include +#include "io.h" #endif #include "misc.h" @@ -373,7 +373,7 @@ } -void getmode(modestruct* m, bool probe_clock, bool raw_mode, int initial_x, int initial_y) +void vgagetmode(modestruct* m, bool probe_clock, bool raw_mode, int initial_x, int initial_y) /* get mode parameters. When initial_x and/or initial_y are specified, less guessing is done */ diff -N -u -r old/SVGATextMode-1.4-src/modedata.h SVGATextMode-1.4-src/modedata.h --- old/SVGATextMode-1.4-src/modedata.h Thu Mar 7 06:56:16 1996 +++ SVGATextMode-1.4-src/modedata.h Fri Oct 18 01:57:50 1996 @@ -90,7 +90,7 @@ #define GMOFLG_SET(m,opt) ((m).mode_flags |= (opt)) #define GMOFLG_ISSET(m,opt) ( ((m).mode_flags & (opt)) != 0 ) -void getmode(modestruct* m, bool probe_clock, bool raw_mode, int initial_x, int initial_y); +void vgagetmode(modestruct* m, bool probe_clock, bool raw_mode, int initial_x, int initial_y); #endif diff -N -u -r old/SVGATextMode-1.4-src/probe.c SVGATextMode-1.4-src/probe.c --- old/SVGATextMode-1.4-src/probe.c Sun Sep 15 22:32:44 1996 +++ SVGATextMode-1.4-src/probe.c Fri Oct 18 02:20:54 1996 @@ -53,9 +53,7 @@ #endif #define URATIO (1000000.0/(float)UCLOCKS_PER_SEC) -#ifndef DOS -# include -#endif +#include "io.h" #include "misc.h" #include "vga_prg.h" diff -N -u -r old/SVGATextMode-1.4-src/probeclocks.c SVGATextMode-1.4-src/probeclocks.c --- old/SVGATextMode-1.4-src/probeclocks.c Thu Mar 7 07:30:10 1996 +++ SVGATextMode-1.4-src/probeclocks.c Fri Oct 18 01:57:50 1996 @@ -182,7 +182,7 @@ unlock(chipset); - getmode(&m, TRUE); /* get the current pixel clock so we can restore it */ + vgagetmode(&m, TRUE); /* get the current pixel clock so we can restore it */ PDEBUG(("pixel clock before tests = %1.2f\n", m.pclock)); for (n=0; n #include -#ifndef DOS -# include -#endif #include #include "misc.h" #include "vga_prg.h" @@ -36,6 +33,7 @@ #include "clockchip.h" #include "messages.h" #include "run_extprog.h" +#include "io.h" /*****************************************************************************************************************************/ @@ -230,7 +228,9 @@ /* program clocks in V-blanking only, avoiding video memory corruption and system hangs (?) */ safe_wait_vsync(); /* wait for VSYNC... if there is one */ +/* SCREEN_OFF; +*/ /* mclk programming */ if (clock_data.mclk != MCLK_NOT_DEFINED) diff -N -u -r old/SVGATextMode-1.4-src/std_clock.c SVGATextMode-1.4-src/std_clock.c --- old/SVGATextMode-1.4-src/std_clock.c Sun Sep 8 21:11:58 1996 +++ SVGATextMode-1.4-src/std_clock.c Fri Oct 18 01:57:50 1996 @@ -28,7 +28,7 @@ #include #include #ifndef DOS -# include +# include "io.h" #endif #include #include "misc.h" diff -N -u -r old/SVGATextMode-1.4-src/tty.h SVGATextMode-1.4-src/tty.h --- old/SVGATextMode-1.4-src/tty.h Thu Jan 1 10:00:00 1970 +++ SVGATextMode-1.4-src/tty.h Fri Oct 18 02:08:55 1996 @@ -0,0 +1,27 @@ +/* $Id:$ */ +#ifndef TTY_H +#define TTY_H + +#ifdef linux +#include +#if LINUX_VERSION_CODE < 66382 +# define __KERNEL__ +# include /* for MAX_NR_CONSOLES -- __KERNEL__ is defined to get access to this parameter */ +# undef __KERNEL__ +#else +# include /* for MAX_NR_CONSOLES */ +#endif +#else +# include +#endif + +#ifdef linux +#include /* for PAGE_SIZE */ +#include /* for VT_RESIZE */ +#endif +#include +#include +#include +#include + +#endif /* TTY_H */ diff -N -u -r old/SVGATextMode-1.4-src/ttyresize.c SVGATextMode-1.4-src/ttyresize.c --- old/SVGATextMode-1.4-src/ttyresize.c Sat Jun 1 06:12:37 1996 +++ SVGATextMode-1.4-src/ttyresize.c Fri Oct 18 02:18:45 1996 @@ -25,28 +25,18 @@ *** (c) 1995 Stephen Lee ***/ -#define USE_MMAP 0 /* 1: use mmap() ; 0: use malloc() */ - #ifndef DOS - -#include /* the file states we should NOT use ... */ -#if LINUX_VERSION_CODE < 66382 -# define __KERNEL__ -# include /* for MAX_NR_CONSOLES -- __KERNEL__ is defined to get access to this parameter */ -# undef __KERNEL__ -#else -# include /* for MAX_NR_CONSOLES */ +#ifdef linux +# define USE_MMAP 0 /* 1: use mmap() ; 0: use malloc() */ #endif #include #include #include #include -#include /* for PAGE_SIZE */ -#include /* for VT_RESIZE */ -#include #include -#include +#include +#include #include "misc.h" #include "messages.h" @@ -57,7 +47,9 @@ #if USE_MMAP # include -# include +# ifdef linux +# include +# endif # include #endif @@ -103,6 +95,7 @@ * Make real RAM free, by allocating and then releasing it. */ +#ifdef linux int make_ram_free(size_t bytes) { /* @@ -171,6 +164,7 @@ } #endif } +#endif /* @@ -195,6 +189,7 @@ if (!ioctl(fd, cmd, p_struct_size)) return(TRUE); /* everything went OK */ /* do a few attempts to get enough memory for VT_RESIZE, each time more, hoping we'll get it in the end */ +#ifdef linux for (cnt=1; cnt<=4; cnt++) { PDEBUG(("VT_RESIZE: Could not get memory. Trying to free some (%d), and attempting again...\n", memsize*cnt)); @@ -205,6 +200,7 @@ /* The Real Thing (TM) ... */ if (!ioctl(fd, cmd, p_struct_size)) return(TRUE); /* everything went OK */ } +#endif return(FALSE); } @@ -220,6 +216,7 @@ /* still no luck... if the error is not "out of memory", we don't know what to do and abort. */ perror(descr); if (errno!=ENOMEM) PERROR(("VT_RESIZE returned error %d\n", errno)); +#ifdef linux /* if we are not allowed to resize to a 1x1 screen, we have no more options but to abort */ if (!allow1x1) { @@ -255,8 +252,10 @@ return(TRUE); +#endif } +#ifdef linux int do_VT_RESIZE(int cols, int rows, int allow1x1) { struct vt_sizes my_vt_size, dummy_vt_size; /* passes the new screen size on to the kernel */ @@ -274,25 +273,28 @@ return(generic_VT_RESIZE(&my_vt_size, &dummy_vt_size, allow1x1, ram_needed, VT_RESIZE, "VT_RESIZE")); } - +#endif /* * if VT_RESIZEX not supported (i.e. when compiling on < 1.3.3 kernels), define it. * this is just te keep the compiler happy */ +#ifdef linux #ifndef VT_RESIZEX # define VT_RESIZEX 0x560A typedef struct vt_consize { ushort v_rows; ushort v_cols; ushort v_vlin; ushort v_clin; ushort v_vcol; ushort v_ccol; } vt_consize; #endif - +#endif int do_VT_RESIZEX(int cols, int rows, int vlin, int clin, int vcol, int ccol, int allow1x1) { struct vt_consize my_vt_size; /* passes the new screen size on to the kernel */ +#ifdef linux struct vt_consize dummy_vt_size = { 1 , 1 , 1 , 1 , 1 , 1 }; int ram_needed = cols * rows * 2 * MAX_NR_CONSOLES; +#endif my_vt_size.v_rows = rows; my_vt_size.v_cols = cols; @@ -303,7 +305,11 @@ PDEBUG(("VT_RESIZEX(cols=%d,rows=%d,vlin=%d,clin=%d,vcol=%d,ccol=%d)\n",cols, rows, vlin, clin, vcol, ccol)); +#ifdef linux return(generic_VT_RESIZE(&my_vt_size, &dummy_vt_size, allow1x1, ram_needed, VT_RESIZEX, "VT_RESIZEX")); +#else + return(generic_VT_RESIZE(&my_vt_size, 0, allow1x1, 0, VT_RESIZE, "VT_RESIZE")); +#endif } /* @@ -317,15 +323,18 @@ void resize_specified_vts(int cols, int rows) { +#ifdef linux t_terminals *curr_term; PDEBUG(("Resizing all terminals specified in 'Terminals' line (when needed)\n")); curr_term = p_terminals; while (curr_term) resizetty(curr_term->name, cols, rows); +#endif } +#ifdef linux /* * Resize the VT's reported active from VT_GETSTATE, unfortunately * the return param is a short so we can only hope to know about the @@ -372,6 +381,7 @@ } } } +#endif #endif /* NO_RESIZE */ @@ -389,9 +399,7 @@ return((my_winsize.ws_col != cols) || (my_winsize.ws_row != rows)); } - -#else - +#else /* dos */ /*** *** DOS resizing code for SVGATextMode. *** (c) 1995 Stephen Lee diff -N -u -r old/SVGATextMode-1.4-src/ttyresize.h SVGATextMode-1.4-src/ttyresize.h --- old/SVGATextMode-1.4-src/ttyresize.h Fri May 31 04:39:17 1996 +++ SVGATextMode-1.4-src/ttyresize.h Fri Oct 18 01:57:51 1996 @@ -24,10 +24,11 @@ #ifndef _TTYRESIZE_H #define _TTYRESIZE_H +#include "io.h" +#include "tty.h" + #ifndef DOS # include - -# include # ifndef NO_RESIZE diff -N -u -r old/SVGATextMode-1.4-src/vga_prg.c SVGATextMode-1.4-src/vga_prg.c --- old/SVGATextMode-1.4-src/vga_prg.c Sat Sep 21 21:12:22 1996 +++ SVGATextMode-1.4-src/vga_prg.c Fri Oct 18 02:06:04 1996 @@ -74,6 +74,7 @@ void get_IO_range(long start, long len) { PDEBUG(("Getting VGA IO permissions for addr. range 0x%x-0x%x\n", start, start+len-1)); +#ifdef linux if (start>=0x400) { if (iopl(3) != 0) @@ -92,6 +93,17 @@ You must be superuser, or the program must be setuid root!\n", start, start+len-1)); } } +#else + { + int fd = opentty("/dev/console"); + if (ioctl (fd, KDENABIO, 0) < 0) + { + perror ("Can't enable port I/O"); + exit (1); + } + close (fd); + } +#endif } /* diff -N -u -r old/SVGATextMode-1.4-src/vga_prg.h SVGATextMode-1.4-src/vga_prg.h --- old/SVGATextMode-1.4-src/vga_prg.h Tue Jul 16 05:30:59 1996 +++ SVGATextMode-1.4-src/vga_prg.h Fri Oct 18 01:57:51 1996 @@ -33,22 +33,9 @@ #include "chipset.h" -#ifndef DOS -# include -#else -# ifdef DJGPP -# include -# define outb(data,port) outportb(port,data) -# define outw(data,port) outportw(port,data) -# define inb(port) inportb(port) -# define inw(port) inportw(port) -# else /* Borland C */ -# define outb(data,port) outp(port,data) -# define outw(data,port) outpw(port,data) -# define inb(port) inp(port) -# define inw(port) inpw(port) -# endif -# define ioperm(x,y,z) (0) +#include "io.h" +#ifdef __FreeBSD__ +# include #endif /* diff -N -u -r old/SVGATextMode-1.4-src/vidcontrol-setfont SVGATextMode-1.4-src/vidcontrol-setfont --- old/SVGATextMode-1.4-src/vidcontrol-setfont Thu Jan 1 10:00:00 1970 +++ SVGATextMode-1.4-src/vidcontrol-setfont Fri Oct 18 02:45:15 1996 @@ -0,0 +1,2 @@ +#!/bin/sh +vidcontrol -f 8x16 $* diff -N -u -r old/SVGATextMode-1.4-src/wait_vsync.c SVGATextMode-1.4-src/wait_vsync.c --- old/SVGATextMode-1.4-src/wait_vsync.c Thu Mar 7 06:43:28 1996 +++ SVGATextMode-1.4-src/wait_vsync.c Fri Oct 18 04:46:50 1996 @@ -31,7 +31,7 @@ #include #include #ifndef DOS -# include +# include "io.h" #endif #include "misc.h" @@ -63,6 +63,3 @@ signal(SIGALRM, SIG_DFL); return(!vtimeout); } - - - \ No newline at end of file From owner-freebsd-hackers Thu Nov 7 14:42:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22791 for hackers-outgoing; Thu, 7 Nov 1996 14:42:55 -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 OAA22781 for ; Thu, 7 Nov 1996 14:42:51 -0800 (PST) Received: from nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id HAA16842 for ; Thu, 7 Nov 1996 07:42:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id HAA06957; Thu, 7 Nov 1996 07:41:42 -0800 (PST) Date: Thu, 7 Nov 1996 07:41:35 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: Dan Nelson cc: "Daniel O'Callaghan" , FreeBSD Hackers Subject: Re: changing default sysctl values in kernel... In-Reply-To: <199611071534.JAA18370@dan.emsphone.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, 7 Nov 1996, Dan Nelson wrote: > In the last eposode (Nov 7), John-Mark Gurney said: > > On Thu, 7 Nov 1996, Daniel O'Callaghan wrote: > > > On Wed, 6 Nov 1996, John-Mark Gurney wrote: > > > > well... the subject says it all... I have a server that is > > > > designed to be a terminal server... and I would like a way to > > > > compile a kernel with the default of net.inet.ip.forwarding: 1... > > > > instead of 0... will allow me to not have sysctl on the > > > > machine... thanks for your help... ttyl.. > > > > > > Just put > > > options GATEWAY > > > in your kernel config file. > > > > I just did a search through the kernel source (960801-SNAP) and the > > only place I found anything referencing GATEWAY was in some files in > > i386/boot/... other than that nothing... ttyl.. > > You don't want to search for GATEWAY; search for where the sysctl > "forwarding" is linked to a kernel variable. From /sys/netinet/ip_input.c: > > static int ipforwarding = 0; > SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, > &ipforwarding, 0, ""); > > Just set ipforwarding to 1 there, and you should be set. ahh... thanks... I just decided that I still wanted my other kernels to build fine... so I reimplimented GATEWAY :) thanks for the pointer... 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 7 14:43:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22815 for hackers-outgoing; Thu, 7 Nov 1996 14:43:01 -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 OAA22793 for ; Thu, 7 Nov 1996 14:42:56 -0800 (PST) Received: from hq.icb.chel.su (hq.icb.chel.su [193.125.10.33]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id IAA16961 for ; Thu, 7 Nov 1996 08:00:45 -0800 (PST) Received: (babkin@localhost) by hq.icb.chel.su (8.7.5/8.6.5) id VAA25791; Thu, 7 Nov 1996 21:00:38 +0500 (ESK) From: "Serge A. Babkin" Message-Id: <199611071600.VAA25791@hq.icb.chel.su> Subject: Re: COFF->BSD converter To: erich@lodgenet.com (Eric L. Hernes) Date: Thu, 7 Nov 1996 21:00:37 +0500 (ESK) Cc: hackers@freebsd.org, marc@nietzsche.bowtie.nl.hq.icb.chel.su, vadim@tversu.ac.ru, lenzi@bsi.com.br, babkin@hq.icb.chel.su (Serge A. Babkin) In-Reply-To: <199611042234.QAA02056@jake.lodgenet.com> from "Eric L. Hernes" at Nov 4, 96 04:34:37 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > "Serge A. Babkin" writes: > >I wrote the COFF -> BSD object file converter. It needs more extensive > >testing but it works for now. Now the compatibility library and > >set of headers are needed to use it. I don't know how long would it > >take from me to write them. So if anyone can suggest any help > >it will be gladly accepted. The possible benefits from this project are: > > > > Cool, but doesn't objcopy do the conversion if properly configured? Hm, I don't know. Is objcopy another thing from binutils ? > What compat libraries and headers do you need? Is the stuff from linux' > ibcs2 any help? The following things can be included in a converted executable file: 1. SCO ojbect files. Need: to be converted to BSD format (done). Libraries designed for SCO can be included in this cathegory. Converting, say, Oracle libraries is legal but I think converting SCO libraries like curses etc. are illegal. 2. SCO source files. They are often used as a kind of tuning. Need: to be compiled using SCO or SCO-like header files. For the first time the native SCO headers can be used, later the original headers defining the same things are needed for legal reasons. 3. Compatibility libraries. They are supposed to be written in BSD but implement SCO API. Some functions are the same as in BSD (like open()), some functions are different (like setpgrp()), some functions have different implementation of data structures (like stat() or fopen() or lseek()), some functions are missing in BSD but can be implemented at least in simplified form (like aio_*()), some functions can't be implemented in BSD just because they need some kernel level support (like TLI). The idea is to implement them (except the last one) to get as much of API as possible. It wolud be not bad to save original BSD functions in case of namespace collisions by adding something like "_bsd_" before their names and get the ability to use both APIs at the same time. I have implemented stdio functions now because they were the first thing needed for testing. Need: careful comparsion of SCO and BSD API and creating as many compatibility libraries from BSD ones as possible. 4. BSD object files. If they want to use the functions that are superceeded by SCO API they need to be converted to use functions with "_bsd_" added instead of them. Converter needs to be written but seems to be simple. Perhaps the iBSC2 support can't help here (except for adding some kernel features). > >- getting semi-native version of Oracle (or any other product distributed as > >set of object files) > > > >- using some libraries (say, Motif) converted from SCO (it's possible > >to get personal SCO license for free, so why do not use some > >godd things from it ?) > > because the free SCO is ELF :( It has binary files in ELF but libraries are both for ELF and COFF. > Is anyone working on ELF support > for SCO? I'm wondering this too. :-) -SB From owner-freebsd-hackers Thu Nov 7 14:43:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA22905 for hackers-outgoing; Thu, 7 Nov 1996 14:43:32 -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 OAA22883 for ; Thu, 7 Nov 1996 14:43:23 -0800 (PST) Received: from dan.emsphone.com (-@dan.emsphone.com [199.67.51.101]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id HAA16816 for ; Thu, 7 Nov 1996 07:34:40 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.7.5/8.7.3) id JAA18370; Thu, 7 Nov 1996 09:34:32 -0600 (CST) Message-Id: <199611071534.JAA18370@dan.emsphone.com> Date: Thu, 7 Nov 1996 09:34:32 -0600 From: dnelson@emsphone.com (Dan Nelson) To: gurney_j@resnet.uoregon.edu (John-Mark Gurney) Cc: danny@panda.hilink.com.au (Daniel O'Callaghan), hackers@freebsd.org (FreeBSD Hackers) Subject: Re: changing default sysctl values in kernel... References: X-Mailer: Mutt 0.49 Mime-Version: 1.0 In-Reply-To: ; from "John-Mark Gurney" on Nov 7, 1996 03:24:01 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the last eposode (Nov 7), John-Mark Gurney said: > On Thu, 7 Nov 1996, Daniel O'Callaghan wrote: > > On Wed, 6 Nov 1996, John-Mark Gurney wrote: > > > well... the subject says it all... I have a server that is > > > designed to be a terminal server... and I would like a way to > > > compile a kernel with the default of net.inet.ip.forwarding: 1... > > > instead of 0... will allow me to not have sysctl on the > > > machine... thanks for your help... ttyl.. > > > > Just put > > options GATEWAY > > in your kernel config file. > > I just did a search through the kernel source (960801-SNAP) and the > only place I found anything referencing GATEWAY was in some files in > i386/boot/... other than that nothing... ttyl.. You don't want to search for GATEWAY; search for where the sysctl "forwarding" is linked to a kernel variable. From /sys/netinet/ip_input.c: static int ipforwarding = 0; SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, &ipforwarding, 0, ""); Just set ipforwarding to 1 there, and you should be set. -Dan Nelson dnelson@emsphone.com From owner-freebsd-hackers Thu Nov 7 14:44:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA23130 for hackers-outgoing; Thu, 7 Nov 1996 14:44:24 -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 OAA23082; Thu, 7 Nov 1996 14:44:13 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id HAA16774 ; Thu, 7 Nov 1996 07:24:52 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vLWHP-0005ZI-00; Thu, 7 Nov 1996 08:22:07 -0700 To: sos@freebsd.org Subject: Re: SUP on sup.freebsd.org Cc: jdp@polstra.com (John Polstra), gene@starkhome.cs.sunysb.edu, hackers@freebsd.org In-reply-to: Your message of "Wed, 06 Nov 1996 23:09:37 +0100." <199611062209.XAA02882@ravenock.cybercity.dk> References: <199611062209.XAA02882@ravenock.cybercity.dk> Date: Thu, 07 Nov 1996 08:22:06 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611062209.XAA02882@ravenock.cybercity.dk> "Soren Schmidt" writes: : I wouldn't use C++ either, agreed on that one.. The scary thing is that C++ is still a more mature and stable language than Java. While java has its good point, it makes up for them with a whole new set of bad ones :-(. Warner From owner-freebsd-hackers Thu Nov 7 14:47:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24073 for hackers-outgoing; Thu, 7 Nov 1996 14:47:25 -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 OAA24045 for ; Thu, 7 Nov 1996 14:47:21 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id FAA16290 for ; Thu, 7 Nov 1996 05:47:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id FAA03394; Thu, 7 Nov 1996 05:45:31 -0800 (PST) Message-Id: <199611071345.FAA03394@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Thomas David Rivers cc: hackers@freebsd.org Subject: Re: More info on the daily panics... In-reply-to: Your message of "Thu, 07 Nov 1996 07:54:29 EST." <199611071254.HAA02561@lakes.water.net> From: David Greenman Reply-To: dg@root.com Date: Thu, 07 Nov 1996 05:45:31 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Well - in case you missed it - this fix didn't solve my problem >after all; I just got a panic: ffs_valloc: dup alloc. BTW, this sounds very similar to a problem that Peter Wemm was having when he had a news filesystem made with 4K blocks. I seem to recall that he changed the filesystem to 8K blocks and the problem went away. It appears that there is a bug in the FFS block allocation/free code that is tickled by 4K blocks. Are any of your filesystems built with a 4K blocksize? BTW, your UUCP software re-writes of the email headers into bang-path format is very annoying. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Nov 7 14:47:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24107 for hackers-outgoing; Thu, 7 Nov 1996 14:47:31 -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 OAA24072 for ; Thu, 7 Nov 1996 14:47:25 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id FAA16281 for ; Thu, 7 Nov 1996 05:42:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id FAA03376; Thu, 7 Nov 1996 05:40:59 -0800 (PST) Message-Id: <199611071340.FAA03376@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Thomas David Rivers cc: freebsd-hackers@freebsd.org Subject: Re: More info on the daily panics... In-reply-to: Your message of "Thu, 07 Nov 1996 07:54:29 EST." <199611071254.HAA02561@lakes.water.net> From: David Greenman Reply-To: dg@root.com Date: Thu, 07 Nov 1996 05:40:59 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Also, if v_usecount went negative - wouldn't that only loose >one, or a few vnodes (assuming it went to -1), as v_usecount >was incremented, wouldn't it return to being positive? Also, >since -1 != 0, would that vnode ever be available to be used again? >I'm just thinking out loud... v_usecount is a mechanism for reference counting in-use vnodes. When it drops to 0, it is considered "currently unused" and is placed on the freelist. It's not _completely_ free, however, as there are still references to it from the namecache. If there is a namecache hit, the vnode can be removed from the freelist and used...so vnodes on the freelist form a second chance cache for vnodes. In order for a vnode to be considered not-stale, a match must also occur with the vnode's generation count which is called v_id (which is stored in the namecache along with the pointer to the vnode). If the generation count comparison fails, then the vnode is considered not in the cache and a completely new one is allocated. A vnode is removed from the freelist whenever a reference is gained to it. There is only one case algorithmically that a vnode can be on the freelist and have a non-zero usecount. This is the case where the usecount was once zero (and thus was inserted onto the freelist), and was then later decremented again - causing it to become negative. Later, when a vnode needs to be reclaimed from the freelist, the system does a consistency check on the vnode and if the usecount is not zero, it panics with "free vnode isn't". One potential hack-fix would be, in vrele(), to decrement the v_usecount only if v_usecount != 0. This would prevent it from ever becoming negative and thus duplicate vrele()s would be eaten. The problem with this is that it covers up a potentially serious problem. One can't determine if the extra vrele() may lose a reference that it shouldn't be losing and thus prematurely insert an in-use vnode onto the freelist. Most of the time this probably won't cause your system to die a horrible death, but it could. ...which is why we have consistency checks in the first place. :-) -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Nov 7 14:47:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24224 for hackers-outgoing; Thu, 7 Nov 1996 14:47:52 -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 OAA24179 for ; Thu, 7 Nov 1996 14:47:42 -0800 (PST) Received: from tyger.inna.net (root@tyger.inna.net [206.151.66.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id FAA16149 for ; Thu, 7 Nov 1996 05:11:24 -0800 (PST) Received: from spyder.inna.net (jamie@spyder.inna.net [206.151.66.4]) by tyger.inna.net (8.7.3/8.7.3) with SMTP id IAA22517; Thu, 7 Nov 1996 08:13:19 -0500 (EST) Date: Thu, 7 Nov 1996 08:14:35 -0500 (EST) From: Jamie Bowden To: Steve Passe cc: John Polstra , hackers@freefall.freebsd.org Subject: Re: SUP on sup.freebsd.org In-Reply-To: <199611070629.XAA21750@clem.systemsix.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, 6 Nov 1996, Steve Passe wrote: > The kids are probably getting tired of us geezers remembering old times > so I'll shut-up now... Are you kidding? Old hardware is cool... Jamie Bowden Network Administrator, TBI Ltd. From owner-freebsd-hackers Thu Nov 7 14:47:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24261 for hackers-outgoing; Thu, 7 Nov 1996 14:47:59 -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 OAA24198 for ; Thu, 7 Nov 1996 14:47:51 -0800 (PST) Received: from nimbus.superior.net (root@nimbus.superior.net [206.153.96.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id FAA16217 for ; Thu, 7 Nov 1996 05:24:39 -0800 (PST) Received: (from exidor@localhost) by nimbus.superior.net (8.7.6/8.7.5) id IAA00454; Thu, 7 Nov 1996 08:22:47 -0500 (EST) Message-Id: <199611071322.IAA00454@nimbus.superior.net> Date: Thu, 7 Nov 1996 08:22:47 -0500 From: exidor@superior.net (Christopher Masto) To: proff@suburbia.net (Julian Assange) Cc: hackers@freebsd.org Subject: Re: still no response References: <328138CB.41C67EA6@whistle.com> <199611070318.OAA21381@suburbia.net> X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 In-Reply-To: <199611070318.OAA21381@suburbia.net>; from Julian Assange on Nov 7, 1996 14:18:52 +1100 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Assange writes: > I like it. Now, what do you think of mine ;) Godlike. -- Christopher Masto . . . . Superior Net Support: support@superior.net chris@masto.com . . . . . Masto Consulting: info@masto.com On Women: There has been no exclusion. We have simply excluded all the women. - Nicolas Romanoff, decendant of last Czar of Russia Nicholas II, - explaining why no women were invited to form a family foundation From owner-freebsd-hackers Thu Nov 7 14:48:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24380 for hackers-outgoing; Thu, 7 Nov 1996 14:48: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 OAA24358 for ; Thu, 7 Nov 1996 14:48:23 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id FAA16192 for ; Thu, 7 Nov 1996 05:20:39 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA26531; Thu, 7 Nov 1996 08:20:01 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 7 Nov 1996 08: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 HAA00852; Thu, 7 Nov 1996 07:53:28 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id HAA02561; Thu, 7 Nov 1996 07:54:29 -0500 (EST) Date: Thu, 7 Nov 1996 07:54:29 -0500 (EST) From: Thomas David Rivers Message-Id: <199611071254.HAA02561@lakes.water.net> To: dg@root.com, ponds!freebsd.org!freebsd-hackers@ucbvax.Berkeley.EDU Subject: Re: More info on the daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I think there is a lot of misinformation being bandied about this problem. > In the one case of this problem that I looked into, it was caused by the > v_usecount being negative. There was clearly one too many vrele's occuring > somewhere. It was not caused by any sort of "freelist wrap" condition. The > patch you've provided will kludge around the problem, but it is not in any > sense a "fix". Each time a vnode is deallocated too many times (and thus > v_usecount goes negative), you'll end up losing all of the vnodes on the > freelist that follow it (potentially several thousand) because the condition > will never go away. This is bad. > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project Well - in case you missed it - this fix didn't solve my problem after all; I just got a panic: ffs_valloc: dup alloc. So, I'd have to say that the problem I'm experiencing is somehow different than the problem this fix addresses. Also, if v_usecount went negative - wouldn't that only loose one, or a few vnodes (assuming it went to -1), as v_usecount was incremented, wouldn't it return to being positive? Also, since -1 != 0, would that vnode ever be available to be used again? I'm just thinking out loud... Anyway, looks like I'm still wondering if the isclr() bit on the inodes is somehow not getting set... - Dave Rivers - From owner-freebsd-hackers Thu Nov 7 14:49:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24526 for hackers-outgoing; Thu, 7 Nov 1996 14:49:01 -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 OAA24480 for ; Thu, 7 Nov 1996 14:48:51 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id EAA16048 for ; Thu, 7 Nov 1996 04:50:39 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AB25358; Thu, 7 Nov 1996 07:50:07 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 7 Nov 1996 07: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 HAA00639; Thu, 7 Nov 1996 07:46:12 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id HAA02530; Thu, 7 Nov 1996 07:47:13 -0500 (EST) Date: Thu, 7 Nov 1996 07:47:13 -0500 (EST) From: Thomas David Rivers Message-Id: <199611071247.HAA02530@lakes.water.net> To: ponds!freebsd.org!dyson@ucbvax.Berkeley.EDU, ponds!freefall.cdrom.com!freebsd-hackers@ucbvax.Berkeley.EDU, ponds!lakes.water.net!rivers@ucbvax.Berkeley.EDU, ponds!lambert.org!terry@ucbvax.Berkeley.EDU Subject: Re: More info on the daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > [ ... patch elided ... ] > > Yes. This is an equivalent workaround. > > I suppose the big question is: did this fix the problem for you? > > Well - the jury is "in" - the patch didn't affect my problem. This morning, at 7:06am - I got a reboot: panic: ffs_valloc: dup alloc I seem to recall you mentioning this was an added solution to some previous changes... could those be required to make this a better fix? Recall, I'm using 2.1.5-STABLE as of Oct. 17th, not 2.2. Any more avenues to explore? - Dave Rivers - From owner-freebsd-hackers Thu Nov 7 14:49:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24583 for hackers-outgoing; Thu, 7 Nov 1996 14:49:18 -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 OAA24538 for ; Thu, 7 Nov 1996 14:49:04 -0800 (PST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id EAA16034 for ; Thu, 7 Nov 1996 04:47:37 -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 NAA07538 for ; Thu, 7 Nov 1996 13:46:16 +0100 (MET) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0vLTrH-00021LC; Thu, 7 Nov 96 13:46 MET Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA282520755; Thu, 7 Nov 1996 13:45:55 +0100 From: "Hr.Ladavac" Message-Id: <199611071245.AA282520755@ws2301.gud.siemens.co.at> Subject: Re: still no response To: terry@lambert.org (Terry Lambert) Date: Thu, 7 Nov 1996 13:45:55 +0100 (MEZ) Cc: julian@whistle.com, hackers@freebsd.org In-Reply-To: <199611070146.SAA09269@phaeton.artisoft.com> from "Terry Lambert" at Nov 6, 96 06:46:19 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 Terry Lambert contained: > > I still haven't heard back from anyone regarding the > > session limit addition in inetd. > > > > does everyone think it's a boring idea? > > doesn no one dislikr it? > > should I just check it in? I've already said "go ahead", but I have vested interest. > > The inetd already has a session limit. It's just not per service, it's > per inetd, and it's compiled in. > > You can get the same effect right now by compiling another inetd and > starting several inetd's with different inetd.conf files per service > class. Except that I don't have the SINIX sources, and the compiled limit is *too small*. Now, I can probably persuade my sysadmins and higher management to replace inetd on a couple of machines with FreeBSD inetd if it were a drop-in replacement, with extensions. I *know* that they won't like the idea of multiple inetd's and multiple inetd.conf's running on the same machine. > > > I've used multiple inetd's for several years to get different '-R' > values for different things (tftpd, in particular, for a lab full of > X terminals). To make things even worse, I don't think that SINIX inetd supports -R :( > > I've only compiled up a seperate inetd with a use count restriction > once, and that was for an ISP who wanted to limit FTP sessions with > an old ftpd. > > > I can see where it might be a big deal for some ISP's, or for people > who want to put every service in a different limitation class. Other > than that, I'm pretty non-commital -- I can take it or leave it... it's > just an alternate way of doing things I can already do (but with the > bonus that people who don't understand inetd can twiddle the thing, > I suppose). As far as I understood the patch, it is fully backwardly compatible version, and hardly bloated at all. And it doesn't require another instance of inetd in core when running. /Marino > > > 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 7 14:52:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25224 for hackers-outgoing; Thu, 7 Nov 1996 14:52: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 OAA25202 for ; Thu, 7 Nov 1996 14:52:23 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA18621 for ; Thu, 7 Nov 1996 14:52:20 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA10705; Thu, 7 Nov 1996 15:42:58 -0700 From: Terry Lambert Message-Id: <199611072242.PAA10705@phaeton.artisoft.com> Subject: Re: Linux emulation To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Thu, 7 Nov 1996 15:42:58 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199611072218.RAA03424@crh.cl.msu.edu> from "Charles Henrich" at Nov 7, 96 05:18:56 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 > 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? Well, since ioctl's are device dependent and can therefore have overlapping name spaces, it depends on the device. The 'P' leads me to believe it's a pty, but you should look at the open which returns '9' as it's fd. Then you should look up the Linux header file and man page for whatever device it is, and translate the number into a description. 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 7 15:19:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26619 for hackers-outgoing; Thu, 7 Nov 1996 15:19:28 -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 PAA26614 for ; Thu, 7 Nov 1996 15:19:25 -0800 (PST) Received: (from gemohler@localhost) by dyslexic.phoenix.net (8.7.5/8.7.3) id RAA02702; Thu, 7 Nov 1996 17:19:24 -0600 (CST) Date: Thu, 7 Nov 1996 17:19:24 -0600 (CST) From: Geoff Mohler X-Sender: gemohler@dyslexic.phoenix.net To: hackers@freebsd.org Subject: Trafshow & FPA0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can someone tell me what I might to do get trafshow working on my fpa0 interface? I am getting this error: *** virtual2# trafshow -ifpa0 trafshow: unknown data link type 0xa *** Clues? PS: How can I join this mailing list? "Quark & Odo in '96. Law, order, and a tidy profit." Geoff Mohler Operations Engineer Charter Communications/Phoenix Data Net From owner-freebsd-hackers Thu Nov 7 16:56:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA22650 for hackers-outgoing; Thu, 7 Nov 1996 16:56:11 -0800 (PST) Received: from fgwmail.fujitsu.co.jp (fgwmail.fujitsu.co.jp [164.71.1.133]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA22588 for ; Thu, 7 Nov 1996 16:56:06 -0800 (PST) Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.7.6+2.6Wbeta7/3.3W5-MX961019-Fujitsu Mail Gateway) id JAA20584; Fri, 8 Nov 1996 09:56:03 +0900 (JST) Received: from sphinx.sysrap.cs.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.12+2.5Wb4/3.3W9-MX961013-Fujitsu Domain Mail Master) id JAA11674; Fri, 8 Nov 1996 09:55:30 +0900 Received: (from seki@localhost) by sphinx.sysrap.cs.fujitsu.co.jp (8.6.12+2.5Wb7/3.4W-) id JAA06123; Fri, 8 Nov 1996 09:50:05 +0900 Date: Fri, 8 Nov 1996 09:50:05 +0900 From: Masahiro SEKIGUCHI Message-Id: <199611080050.JAA06123@sphinx.sysrap.cs.fujitsu.co.jp> To: hackers@FreeBSD.org Subject: Re: Who owns PCMCIA? In-Reply-To: References: Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Subject: http://www.freebsd.org/handbook/handbook8.html > > It might be a good idea to update this and the ancillary pages Yes! > the list of pcmcia hardware supported by freebsd. See http://www.mt.cs.keio.ac.jp/person/hosokawa/PAO/ for the info. There is a list of supported PC cards (and some known-to-be-not-supported cards) at the bottom of the page. The page is entirely written in English, so subscribers of this list should have no difficulty to read it. Unfortunately, PC cards discussed here *may* be biased by availability in Japanese market... You hackers worldwide can help Tatsumi to write more comprehensive list! From owner-freebsd-hackers Thu Nov 7 18:20:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA29075 for hackers-outgoing; Thu, 7 Nov 1996 18: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 SAA29058 for ; Thu, 7 Nov 1996 18:20:38 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA20486; Thu, 7 Nov 1996 21:20:03 -0500 Received: from lambert.org by dg-rtp.dg.com.rtp.dg.com; Thu, 7 Nov 1996 21:20 EST Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.7.5/8.7.3) with UUCP id SAA04319 for freefall.cdrom.com!freebsd-hackers; Thu, 7 Nov 1996 18:17:16 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA20565; Thu, 7 Nov 1996 14:37:46 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA03645; Thu, 7 Nov 96 14:34:20 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA03236; Thu, 7 Nov 96 13:58:06 -0500 Received: from stingray.mcnc.org (stingray.mcnc.org [128.109.130.74]) by ncnoc.ncren.net (8.7.4/8.7.3) with ESMTP id NAA25380; Thu, 7 Nov 1996 13:57:34 -0500 (EST) Received: from relay3.UU.NET by stingray.mcnc.org (8.7.5/MCNC/8-10-92) id NAA13603; Thu, 7 Nov 1996 13:56:05 -0500 (EST) for Received: from coyote.Artisoft.COM by relay3.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQbovj17719; Thu, 7 Nov 1996 13:56:53 -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 LAA02788; Thu, 7 Nov 1996 11:54:26 -0700 (MST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10405; Thu, 7 Nov 1996 11:46:43 -0700 From: Terry Lambert Message-Id: <199611071846.LAA10405@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: ponds!ponds!rivers (Thomas David Rivers) Date: Thu, 7 Nov 1996 11:46:42 -0700 (MST) Cc: ponds!Artisoft.COM!ponds!freebsd.org!dyson, ponds!Artisoft.COM!ponds!freefall.cdrom.com!freebsd-hackers, ponds!Artisoft.COM!ponds!lakes.water.net!rivers, ponds!Artisoft.COM!ponds!lambert.org!terry In-Reply-To: <199611071247.HAA02530@lakes.water.net> from "Thomas David Rivers" at Nov 7, 96 07:47:13 am 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 > Well - the jury is "in" - the patch didn't affect my problem. > > This morning, at 7:06am - I got a reboot: > > panic: ffs_valloc: dup alloc > > I seem to recall you mentioning this was an added solution to > some previous changes... could those be required to make this > a better fix? Recall, I'm using 2.1.5-STABLE as of Oct. 17th, > not 2.2. > > Any more avenues to explore? The patch only prevents a condition from occuring instead of panic'ing when it does occur. Ie: it prevents one less error condition that can't be handled from needing to be checked, and then "not handled" (panic). The previous changes didn't affect that specific area of the code, they were a usage workaround designed not to tickle the sensitive race. They were a kludge fix, since the code should be robust in isolation. The "doctor: don't do that" answer isn't applicable when the interfaces are (supposedly) treated as if they were black boxes. What FS's do you have mounted? This is very important. Not all FS's verify the generation count on the vnode like they should, and other nasty bits which may cause your problem as well. Very likely, if David is correct about the proximal cause, it is an FS-specific problem. That it errors out not in the call tree for the FS is a result of the panic check being in the wrong place (list reference instead of list insertion). Please see my recent posting. If David is right about your particular problem, then putting the check in the vrele() like I suggested there will cause a panic at the point of corruption rather than the point of use of corrupted data. This would have the effect of isolating the exact line of code causing your problem, which in the multiple vrele() case is probably an error path that is not frequently used. It would also make the panic condition repeat reliably, for what that's worth (probably a lot, at this point). The vnode->inode->vnode and the inode->vnode->inode integrity checks, like the "ffs_valloc: dup alloc" check, is a post-event check. You will see the corrupt data before you attempt to use it, and panic earlier than you would have, but the proximal cause of the corruption would still not be identifiable from the stack trace. 8-(. Unfortunately, the FreeBSD VFS architecture is not very friendly to FS debugging, and changes to fix it don't look like they will be going in en masse. 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 7 18:46:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA00683 for hackers-outgoing; Thu, 7 Nov 1996 18:46:37 -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 SAA00678; Thu, 7 Nov 1996 18:46:34 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id CAA01157; Fri, 8 Nov 1996 02:46:14 GMT Date: Fri, 8 Nov 1996 11:46:13 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: dg@root.com, ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-Reply-To: <199611071813.LAA10315@phaeton.artisoft.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, 7 Nov 1996, Terry Lambert wrote: > If you are really concerned that this will mask a future multiple vrele() > problem, I suggest you put the assert in vrele() and prevent the queue > from ever getting corrupted that way in the first place. We really need to engineer asserts into the kernel. They're kind of there with the #ifdef DIAGNOSTICS stuff, but this is ugly I hate looking at #ifdef's. I'm happy that we *have* a model. In our code they are often in the wrong place. In the case of vrele() they are too far into the function body, they should be the first things checked for, near the parameter list. The current model for parameter checking is this: 1) #ifdef DIAGNOSTICS ... #endif for parameter checks we assume the caller does correctly, but want to check sometime. 2) if ( expr ) { ... } for checks we think are important enough to require in it runtime code. We also have stuff embedded, but I won't talk about that. I like to improve upon the model like this: Improved use of assertions ==================================================================== void vrele(vp) register struct vnode *vp; { ASSUME(vp != NULL, "vrele: vp shouldn't be null"); REQUIRE(vp->v_usecount > 0, "vrele: ref count shouldn't already be zero"); vp->v_usecount--; if ((vp->v_usecount == 1) && vp->v_object && (vp->v_object->flags & OBJ_VFS_REF)) { vp->v_object->flags &= ~OBJ_VFS_REF; vm_object_deallocate(vp->v_object); return; } if (vp->v_usecount > 0) return; [ .. ] Current ==================================================================== void vrele(vp) register struct vnode *vp; { #ifdef DIAGNOSTIC if (vp == NULL) panic("vrele: null vp"); #endif vp->v_usecount--; if ((vp->v_usecount == 1) && vp->v_object && (vp->v_object->flags & OBJ_VFS_REF)) { vp->v_object->flags &= ~OBJ_VFS_REF; vm_object_deallocate(vp->v_object); return; } if (vp->v_usecount > 0) return; if (vp->v_usecount < 0) { #ifdef DIAGNOSTIC vprint("vrele: negative ref count", vp); #endif panic("vrele: negative reference cnt"); } [ ... ] Regards, Mike Hancock From owner-freebsd-hackers Thu Nov 7 18:52:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA01051 for hackers-outgoing; Thu, 7 Nov 1996 18:52: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 SAA01039 for ; Thu, 7 Nov 1996 18:52:20 -0800 (PST) Received: from misery.sdf.com ([204.244.213.33]) by misery.sdf.com with SMTP id <1359-3087>; Thu, 7 Nov 1996 19:20:47 -0800 Date: Thu, 7 Nov 1996 19:20:38 -0800 (PST) From: Tom Samplonius To: Julian Elischer cc: hackers@freebsd.org Subject: Re: Inetd mod.. comments? In-Reply-To: <32823128.446B9B3D@whistle.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, 7 Nov 1996, Julian Elischer wrote: > > Tom Samplonius wrote: > > > > On Wed, 6 Nov 1996, Julian Elischer wrote: > > > > > I have some patches to Inetd her that I sent out for comment. > > > the only comment I got was > > > "Gee that's neat!, I need that" > > > > > > but no technical reviews or code checks.. > > > > xinetd has done this for long time already. Why not use that? > > > > Tom > where does one get it? ports/packages, where else?!? It has been a port for quite some time actually. I've installed xinetd on every server, freebsd and otherwise. Tom From owner-freebsd-hackers Thu Nov 7 18:53:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA01115 for hackers-outgoing; Thu, 7 Nov 1996 18:53:39 -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 SAA01109; Thu, 7 Nov 1996 18:53:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id SAA04382; Thu, 7 Nov 1996 18:49:56 -0800 (PST) Message-Id: <199611080249.SAA04382@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-reply-to: Your message of "Thu, 07 Nov 1996 11:13:59 MST." <199611071813.LAA10315@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 07 Nov 1996 18:49:56 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >This patch *is* a kludge: it's a kludge against the fact that there is >a two stage decommit (which is itself a kludge, with no way to recover >perfectly valid data hung off an in core vnode buffer list pointer once >the FS data has been dissociated from that vnode). The problem is the >race conditions in the two stage decommit during a period of incresing >demand and high vnode reuse. As always, trying to parse what you're saying is difficult. I interpret what you're saying above as there being a race condition when allocating inode+vnode pairs (since either one can block and thus someone else might get in there and try to do the same thing for the same inode). I fixed that race condition over a year ago by adding a mutex lock and by a series of allocation order changes. I might have missed a rarely used filesystem (msdosfs?), but the race condition for FFS has been fixed since July '95. ufs/ffs/ffs_vfsops.c: ---------------------------- revision 1.25 date: 1995/07/21 16:20:20; author: davidg; state: Exp; lines: +8 -14 Since ufs_ihashget can block, the lock must be checked for each time the function returns. Also, moved lock into .bss and made minor cosmetic changes. Submitted by: Bruce Evans ---------------------------- revision 1.24 date: 1995/07/21 03:52:40; author: davidg; state: Exp; lines: +34 -4 Implement a lock in ffs_vget to prevent a race condition where two processes try allocate the same inode/vnode, causing a duplicate. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Nov 7 19:00:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01673 for hackers-outgoing; Thu, 7 Nov 1996 19:00:12 -0800 (PST) Received: from defiant (defiant.flash.net [208.194.223.9]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA01656 for ; Thu, 7 Nov 1996 19:00:07 -0800 (PST) Received: from nt-support2.flash.net (nt-support2.flash.net [206.149.30.138]) by defiant (8.6.12/8.6.9) with SMTP id UAA18552 for ; Thu, 7 Nov 1996 20:59:56 -0600 Message-ID: <32824DA3.167EB0E7@flash.net> Date: Thu, 07 Nov 1996 20:59:15 +0000 From: "J. A. Sigler" X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: FreeBSD Development Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am greatly interested in FreeBSD development. I am not able to contribute at this time, as I just recently switched to running BSD on my desktop workstation. I would like to be on any applicable mailing lists. Thank you, J. Andrew Sigler FlashNet Communications From owner-freebsd-hackers Thu Nov 7 19:11:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA02334 for hackers-outgoing; Thu, 7 Nov 1996 19:11:10 -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 TAA02319; Thu, 7 Nov 1996 19:11:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id TAA04492; Thu, 7 Nov 1996 19:07:52 -0800 (PST) Message-Id: <199611080307.TAA04492@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Hancock cc: Terry Lambert , ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-reply-to: Your message of "Fri, 08 Nov 1996 11:46:13 +0900." From: David Greenman Reply-To: dg@root.com Date: Thu, 07 Nov 1996 19:07:52 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On Thu, 7 Nov 1996, Terry Lambert wrote: > >> If you are really concerned that this will mask a future multiple vrele() >> problem, I suggest you put the assert in vrele() and prevent the queue >> from ever getting corrupted that way in the first place. > >We really need to engineer asserts into the kernel. They're kind of there >with the #ifdef DIAGNOSTICS stuff, but this is ugly I hate looking at >#ifdef's. I'm happy that we *have* a model. We've been down this road before. The asserts model isn't very well liked by a lot of people, including myself. It tends to bloat the sources with a lot of unuseful checks and isn't flexible enough to accomodate more algorithmically complex checks. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Nov 7 19:20:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA02886 for hackers-outgoing; Thu, 7 Nov 1996 19:20:47 -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 TAA02876 for ; Thu, 7 Nov 1996 19:20:35 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA21036; Thu, 7 Nov 1996 22:20:04 -0500 Received: from dg-rtp by dg-rtp.dg.com.rtp.dg.com; Thu, 7 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 WAA07496 for freefall.cdrom.com!freebsd-hackers; Thu, 7 Nov 1996 22:07:37 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA01440; Thu, 7 Nov 1996 21:39:47 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA07556; Thu, 7 Nov 96 21:25:58 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA07519; Thu, 7 Nov 96 21:22:14 -0500 Received: from stingray.mcnc.org (stingray.mcnc.org [128.109.130.74]) by ncnoc.ncren.net (8.7.4/8.7.3) with ESMTP id VAA03745 for ; Thu, 7 Nov 1996 21:21:49 -0500 (EST) Received: from relay3.UU.NET by stingray.mcnc.org (8.7.5/MCNC/8-10-92) id VAA15815; Thu, 7 Nov 1996 21:20:27 -0500 (EST) for Received: from coyote.Artisoft.COM by relay3.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQbown11557; Thu, 7 Nov 1996 21:21:46 -0500 (EST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by coyote.Artisoft.COM (8.7.6/8.7.3) with SMTP id TAA15237 for ; Thu, 7 Nov 1996 19:20:42 -0700 (MST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA20660; Thu, 7 Nov 1996 21:20:07 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 7 Nov 1996 21: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 UAA06648; Thu, 7 Nov 1996 20:42:41 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id UAA03593; Thu, 7 Nov 1996 20:43:45 -0500 (EST) Date: Thu, 7 Nov 1996 20:43:45 -0500 (EST) From: Thomas David Rivers Message-Id: <199611080143.UAA03593@lakes.water.net> To: ponds!lambert.org!terry, ponds!uunet.uu.net!ponds!ponds!rivers Subject: Re: More info on the daily panics... Cc: ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!freebsd.org!dyson, ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!freefall.cdrom.com!freebsd-hackers, ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!lakes.water.net!rivers, ponds!uunet.uu.net!ponds!Artisoft.COM!ponds!lambert.org!terry Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Well - the jury is "in" - the patch didn't affect my problem. > > > > This morning, at 7:06am - I got a reboot: > > > > panic: ffs_valloc: dup alloc > > > > I seem to recall you mentioning this was an added solution to > > some previous changes... could those be required to make this > > a better fix? Recall, I'm using 2.1.5-STABLE as of Oct. 17th, > > not 2.2. > > > > Any more avenues to explore? > > The patch only prevents a condition from occuring instead of panic'ing > when it does occur. Ie: it prevents one less error condition that can't > be handled from needing to be checked, and then "not handled" (panic). Ok, then we can deduce that my panic was not from this condition, right? (Since this condition can no longer occur, and I still get the panic...) > > The previous changes didn't affect that specific area of the code, they > were a usage workaround designed not to tickle the sensitive race. They > were a kludge fix, since the code should be robust in isolation. The > "doctor: don't do that" answer isn't applicable when the interfaces are > (supposedly) treated as if they were black boxes. > > > What FS's do you have mounted? This is very important. Not all FS's > verify the generation count on the vnode like they should, and other > nasty bits which may cause your problem as well. Very likely, if David > is correct about the proximal cause, it is an FS-specific problem. That > it errors out not in the call tree for the FS is a result of the panic > check being in the wrong place (list reference instead of list insertion). Hmmm... it seems to error-out in the ffs code (ffs_valloc) - isn't that specific to ffs? Anyway, to answer your question; I have ufs and nfs file systems mounted, my /etc/fstab: /dev/wd0s1b none swap sw 0 0 /dev/wd0a / ufs rw 1 1 /dev/wd0s1e /usr ufs rw 1 1 proc /proc procfs rw 0 0 lakes:/disk1 /disk1 nfs rw 0 0 lakes:/disk1/usr /disk1/usr nfs rw 0 0 lakes:/usr/X11R6 /usr/X11R6 nfs rw 0 0 nothing else is mounted... > > > Please see my recent posting. If David is right about your particular > problem, then putting the check in the vrele() like I suggested there > will cause a panic at the point of corruption rather than the point > of use of corrupted data. Ok - that's done... > > This would have the effect of isolating the exact line of code causing > your problem, which in the multiple vrele() case is probably an error > path that is not frequently used. > > It would also make the panic condition repeat reliably, for what that's > worth (probably a lot, at this point). Yes - it would be helpful - particularly since I have to wait 'n' days for this to occur, with 'n' usually less than 3... The problem almost always occurs at 3:00 AM, but sometimes it occurs at 1:13pm... [I couldn't relate any particular item started by cron(1) that caused this...] > > > The vnode->inode->vnode and the inode->vnode->inode integrity checks, > like the "ffs_valloc: dup alloc" check, is a post-event check. You > will see the corrupt data before you attempt to use it, and panic > earlier than you would have, but the proximal cause of the corruption > would still not be identifiable from the stack trace. 8-(. Well - at least would have incontravertable evidence of the corruption... If I don't trip over the vrele() check, and still get the panic; we can look elsewhere... Just let me add, up front, that I appreciate everyone's effort on this! - Dave R. - From owner-freebsd-hackers Thu Nov 7 22:40:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA12429 for hackers-outgoing; Thu, 7 Nov 1996 22:40:28 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA12405 for ; Thu, 7 Nov 1996 22:40:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA28148 for ; Thu, 7 Nov 1996 23:40:15 -0700 Message-Id: <199611080640.XAA28148@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: hackers@freefall.freebsd.org Subject: motherboard chipset identification Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 23:40:15 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I need to be able to tell which chipset is being used on a motherboard during the boot process (Neptune, Triton, Natoma, etc.) Could someone point me towards the code in the kernel that determines this info??? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-hackers Thu Nov 7 23:35:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA15392 for hackers-outgoing; Thu, 7 Nov 1996 23:35:41 -0800 (PST) Received: from isbalham (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA15387 for ; Thu, 7 Nov 1996 23:35:38 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham (8.6.12/8.6.12) with UUCP id HAA08635; Fri, 8 Nov 1996 07:34:51 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Fri, 8 Nov 1996 07:34:11 GMT X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Nov 1996 07:34:18 +0000 To: Jamie Bowden , Steve Passe From: rb@gid.co.uk (Bob Bishop) Subject: Re: SUP on sup.freebsd.org Cc: John Polstra , hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 8:14 am 7/11/96, Jamie Bowden wrote: >On Wed, 6 Nov 1996, Steve Passe wrote: > >> The kids are probably getting tired of us geezers remembering old times >> so I'll shut-up now... > >Are you kidding? Old hardware is cool... Not necessarily. In the old days, we had a Honeywell 516 in the corner of the lab, and we used to power it up to keep warm! -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Thu Nov 7 23:40:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA15711 for hackers-outgoing; Thu, 7 Nov 1996 23:40:05 -0800 (PST) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA15624 for ; Thu, 7 Nov 1996 23:39:57 -0800 (PST) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id IAA28325; Fri, 8 Nov 1996 08:39:11 +0100 Message-Id: <199611080739.IAA28325@ra.dkuug.dk> Subject: Re: patches for nice text modes (170x48x16 etc) (syscons.c) To: proff@profane.iq.org (Julian Assange) Date: Fri, 8 Nov 1996 08:39:11 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199611071319.AAA01322@profane.iq.org> from "Julian Assange" at Nov 7, 96 05:28:00 pm From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Assange who wrote: OK, I'll just inform that this is not the way it will be done in the official syscons. I have discussed this with Julian, but he hasn't the time to change this to the proposed interface (which isn't in the official sources yet). [patch deleted] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Fri Nov 8 01:38:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21255 for hackers-outgoing; Fri, 8 Nov 1996 01:38:47 -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 BAA21246 for ; Fri, 8 Nov 1996 01:38:21 -0800 (PST) From: john@starfire.mn.org Received: (from john@localhost) by starfire.mn.org (8.7.5/1.1) id DAA03390 for hackers@FreeBSD.org; Fri, 8 Nov 1996 03:37:42 -0600 (CST) Message-Id: <199611080937.DAA03390@starfire.mn.org> Subject: Strange messages from my 2.1.0 kernel To: hackers@FreeBSD.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 03:37:42 -0600 (CST) 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 Can anyone help me understand what these mean? fhtovp: file start miss 1946157056 vs 68 fhtovp: file start miss 1946157056 vs 68 fhtovp: file start miss 1946157056 vs 68 fhtovp: file start miss 1946157056 vs 68 fhtovp: file start miss 1946157056 vs 68 fhtovp: file start miss 1946157056 vs 68 fhtovp: file start miss 1946157056 vs 68 fhtovp: file start miss 1946157056 vs 68 John Lind, Starfire Consulting Services E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417 From owner-freebsd-hackers Fri Nov 8 01:39:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21296 for hackers-outgoing; Fri, 8 Nov 1996 01:39:53 -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 BAA21290; Fri, 8 Nov 1996 01:39:50 -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 BAA13193; Fri, 8 Nov 1996 01:39:40 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id UAA03898; Fri, 8 Nov 1996 20:39:28 +1100 From: Julian Assange Message-Id: <199611080939.UAA03898@suburbia.net> Subject: Re: patches for nice text modes (170x48x16 etc) (syscons.c) To: sos@freebsd.org Date: Fri, 8 Nov 1996 20:39:27 +1100 (EST) Cc: hackers@freebsd.org In-Reply-To: <199611080739.IAA28325@ra.dkuug.dk> from "sos@freebsd.org" at Nov 8, 96 08:39:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In reply to Julian Assange who wrote: > > OK, I'll just inform that this is not the way it will be done in > the official syscons. I have discussed this with Julian, but he > hasn't the time to change this to the proposed interface (which > isn't in the official sources yet). Your "proposed interface" doesn't work, and never will work without substantial modifications. Despite my [previously stated] objections to it I actually tried very hard implimenting the patch as an lkm using your new sc_user_ioctl() hook as you insisted. It was simply impossible, given the variables used and routines that are called when the screen is (physically) resized. It is beyond me, that you insist that something so fundemental to the opperations of the console as changing the number of rows/cols on the screen should be a module. Even so, I would be accepting of your decision if your interface was actually capable of doing the job. As I recall my final words on the matter were that you should convert my patch to your [moving target] interface. I'd have thought the maintainer of syscons would have been delighted to see a patch that substantially increased functionality. All I have got out of it is negativity, complications and a complete waste of my time. If this is FreeBSD evangelism, God save us. -- "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 8 02:01:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22133 for hackers-outgoing; Fri, 8 Nov 1996 02:01:34 -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 CAA22124; Fri, 8 Nov 1996 02:01:30 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id KAA03929; Fri, 8 Nov 1996 10:01:05 GMT Date: Fri, 8 Nov 1996 19:01:05 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: David Greenman cc: Terry Lambert , ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-Reply-To: <199611080307.TAA04492@root.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, 7 Nov 1996, David Greenman wrote: > We've been down this road before. The asserts model isn't very well liked > by a lot of people, including myself. It tends to bloat the sources with a I think there were more ayes than nays on the list the last time we talked about it. > lot of unuseful checks and isn't flexible enough to accomodate more > algorithmically complex checks. Every #ifdef DIAGNOSTICS is an assert so we're already using them. What I'm doing is classifying them and structuring them into the functionality of both assertions and function specifications. This enhances the debugging process both while writing the code and while running the code. I don't suggest that the model be used to replace things like the #ifdef DDB stuff. The current structure is fine. Writing code without parameter assertions basically communicates to the consumer of the function that there is no policy regarding the use of the function. It's hard to debug the fs when each fs author has a different interpretation of how you use the exported functions. The assertions would accelerate debugging because they would detect problems early. A few consistency checks are not enough, by the time you detect the problem the bug that triggered it is often too far away to back track. The best way to debug is to use gdb over a serial cable over a repeatable bug. The best way for user environments that you don't have access to is have them run the kernel with assertions turned on. It would be easier for them to start debugging themselves because it would be very obvious what the author of the function expected. It will be possible for the brave to preprocess away both ASSUME and REQUIRE assertions. We could reach a level of quality nirvana where we can have the confidence to run without a safety net using a *smaller*, *faster*, and *correct* kernel. The anal retentives could run with a DIAGNOSTIC kernel. Enabling both ASSUME and REQUIRE assertions. Look at the code below, I haven't added any more checking than before and if it were the first time I looked at the code I would know a lot about how to use it after reading just 2 lines into the code body. Improved use of assertions: ASSUMEs are only compiled into DIAGNOSTIC kernels, while REQUIREs are compiled into the generic kernel. NDEBUG preprocesses away both. ==================================================================== void vrele(vp) register struct vnode *vp; { ASSUME(vp != NULL, "that vp isn't null"); REQUIRE(vp->v_usecount > 0, "that the ref count isn't already zero"); vp->v_usecount--; if ((vp->v_usecount == 1) && vp->v_object && (vp->v_object->flags & OBJ_VFS_REF)) { vp->v_object->flags &= ~OBJ_VFS_REF; vm_object_deallocate(vp->v_object); return; } if (vp->v_usecount > 0) return; [ .. ] Current ==================================================================== void vrele(vp) register struct vnode *vp; { #ifdef DIAGNOSTIC if (vp == NULL) panic("vrele: null vp"); #endif vp->v_usecount--; if ((vp->v_usecount == 1) && vp->v_object && (vp->v_object->flags & OBJ_VFS_REF)) { vp->v_object->flags &= ~OBJ_VFS_REF; vm_object_deallocate(vp->v_object); return; } if (vp->v_usecount > 0) return; if (vp->v_usecount < 0) { #ifdef DIAGNOSTIC vprint("vrele: negative ref count", vp); #endif panic("vrele: negative reference cnt"); } [ ... ] Regards, Mike Hancock Are you going to "out-stubborn" me again? From owner-freebsd-hackers Fri Nov 8 02:13:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22683 for hackers-outgoing; Fri, 8 Nov 1996 02:13:09 -0800 (PST) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22671; Fri, 8 Nov 1996 02:13:05 -0800 (PST) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id LAA29180; Fri, 8 Nov 1996 11:12:08 +0100 Message-Id: <199611081012.LAA29180@ra.dkuug.dk> Subject: Re: patches for nice text modes (170x48x16 etc) (syscons.c) To: proff@suburbia.net (Julian Assange) Date: Fri, 8 Nov 1996 11:12:08 +0100 (MET) Cc: sos@freebsd.org, hackers@freebsd.org In-Reply-To: <199611080939.UAA03898@suburbia.net> from "Julian Assange" at Nov 8, 96 08:39:27 pm From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Julian Assange who wrote: > > > In reply to Julian Assange who wrote: > > > > OK, I'll just inform that this is not the way it will be done in > > the official syscons. I have discussed this with Julian, but he > > hasn't the time to change this to the proposed interface (which > > isn't in the official sources yet). > > Your "proposed interface" doesn't work, and never will work without > substantial modifications. Despite my [previously stated] objections to > it I actually tried very hard implimenting the patch as an lkm using > your new sc_user_ioctl() hook as you insisted. It was simply impossible, > given the variables used and routines that are called when the screen is > (physically) resized. Now wait a minute, the ioctl thing is there and it works, as I also stated to you in private mail was that some other _minor_ changes to syscons would be nessesary (mostly removing some static declarations), and that I would help out with that part. You flatly refused to change the code, due to lack of time as I remember, maybe you tried later I don't know. > It is beyond me, that you insist that something so fundemental to the > opperations of the console as changing the number of rows/cols on the > screen should be a module. Even so, I would be accepting of your decision if > your interface was actually capable of doing the job. In your case it might be simple, but IMHO what you have done is only a half solution, in that it does not support switching screens to other modes etc. If you did care to take the time a do this in a general manner, I would have no trouble in including it, but putting in X hacks for Y half solutions is just not my idea of keeping the quitlity of our sources in a resonable shape. > > As I recall my fal words on the matter were that you should convert my > patch to your [moving target] interface. And there will be a solution to this, but I have only so many hours in a day... > I'd have thought the maintainer of syscons would have been delighted to > see a patch that substantially increased functionality. All I have got > out of it is negativity, complications and a complete waste of my time. Sorry about that, but if we don't do things like this in a general way, we will end up with a multiheaded monster, that noone cares to maintain. If you would take the task of maintaining syscons, and devote the time needed (which is considerable, I've been there) then I'd gladly hand it over to you, I have plenty to do in other areas of the system, plus a full time job, vife and kids. > If this is FreeBSD evangelism, God save us. No, its called common sense and responsibility to our users.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Fri Nov 8 02:13:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22745 for hackers-outgoing; Fri, 8 Nov 1996 02:13:42 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22739 for ; Fri, 8 Nov 1996 02:13:38 -0800 (PST) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id KAA00652; Fri, 8 Nov 1996 10:13:19 GMT Date: Fri, 8 Nov 1996 10:13:17 +0000 (GMT) From: Doug Rabson To: Karl Denninger cc: hackers@FreeBSD.org Subject: Re: Funny behavior in NFS In-Reply-To: <199611051605.KAA05286@Venus.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 On Tue, 5 Nov 1996, Karl Denninger wrote: > > Don't you need the "intr" flag to be able to ^C out of an operation? The > > "soft" flag gives up the operation after a number of retries but isn't > > necessarily interruptable > > Yes, but you can sit with a "soft" mount for hours and it never times out.. I just tried to reproduce this and the soft, intr stuff works fine for me. What you may be seeing is that the code exponentially increases the timeout each time any request times out. This means that for a moderately busy machine which loses its connection, the timeout will go right up to the maximum (256 * timeout specified for mount_nfs) as the first eight processes attempt NFS requests. With the default timeout and retry count, this would mean that the requests will take about 45 minutes to time out. At any time during this 45 minutes, you can ^C the request (for an interruptable mount) and get control back at most one second later. For a single user machine, with only one NFS request outstanding, the total timeout is about 15 minutes. If this is not right for your site, you could try reducing the retrans count down to 5 from the default value of 10. For my testing, I had an fstab line like this: foo:/home /home nfs rw,soft,intr,-x5 0 0 -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-hackers Fri Nov 8 02:27:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA23619 for hackers-outgoing; Fri, 8 Nov 1996 02:27:51 -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 CAA23614; Fri, 8 Nov 1996 02:27:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id CAA05116; Fri, 8 Nov 1996 02:24:38 -0800 (PST) Message-Id: <199611081024.CAA05116@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Hancock cc: Terry Lambert , ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-reply-to: Your message of "Fri, 08 Nov 1996 19:01:05 +0900." From: David Greenman Reply-To: dg@root.com Date: Fri, 08 Nov 1996 02:24:38 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> We've been down this road before. The asserts model isn't very well liked >> by a lot of people, including myself. It tends to bloat the sources with a > >I think there were more ayes than nays on the list the last time we talked >about it. We don't make architectural decisions by majority vote. If there are a significant number of people that have strong opinions against something, then it's probably a change that shouldn't be made. >Are you going to "out-stubborn" me again? I don't think you understand: I understand your position on this and the benefits as you've articulated them are very clear. I simply disagree with you on this topic. My opinion is that I don't like what it does to the sources (adding lots of redundant and usually useless assertions), nor do I like the style (macroized condition expressions). My opinion on this isn't going to change, and I'm not the only core member who has this opinion. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Nov 8 03:22:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25902 for hackers-outgoing; Fri, 8 Nov 1996 03:22:41 -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 DAA25894 for ; Fri, 8 Nov 1996 03:22:38 -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 FAA01873 for ; Fri, 8 Nov 1996 05:22:35 -0600 (CST) Message-Id: <199611081122.FAA01873@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: vnode_pager_input errors... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 05:22:35 -0600 From: "Chris Csanady" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently got the following message while doing a CVSup... Nov 8 04:48:17 friley216 /kernel: vnode_pager_getpages: I/O read error Nov 8 04:48:17 friley216 /kernel: vm_fault: pager input (probably hardware) error, PID 1573 failure Nov 8 04:49:20 friley216 /kernel: pid 1573 (cvsup), uid 0: exited on signal 6 (core dumped) I also recently ran into this problem consistently on some of our 2.1.5 boxes. >From reading through some of the mail list archives, I thought that it was a problem that was fixed quit a while ago.. Any ideas? Btw, this is from a 10/04/96 kernel.. --Chris Csanady From owner-freebsd-hackers Fri Nov 8 03:32:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA26357 for hackers-outgoing; Fri, 8 Nov 1996 03:32:19 -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 DAA26346 for ; Fri, 8 Nov 1996 03:32:14 -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 FAA01931 for ; Fri, 8 Nov 1996 05:32:13 -0600 (CST) Message-Id: <199611081132.FAA01931@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 cc: hackers@freebsd.org Subject: Re: vnode_pager_input errors... In-reply-to: Your message of Fri, 08 Nov 1996 05:22:35 -0600. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 05:32:13 -0600 From: "Chris Csanady" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I recently got the following message while doing a CVSup... > >Nov 8 04:48:17 friley216 /kernel: vnode_pager_getpages: I/O read error >Nov 8 04:48:17 friley216 /kernel: vm_fault: pager input (probably hardware) >error, PID 1573 failure >Nov 8 04:49:20 friley216 /kernel: pid 1573 (cvsup), uid 0: exited on signal 6 >(core dumped) > >I also recently ran into this problem consistently on some of our 2.1.5 boxes. >From reading through some of the mail list archives, I thought that it was >a problem that was fixed quit a while ago.. > >Any ideas? I forgot to mention a rather important peice of information. The tree I was CVSupping into was on an nfs mounted drive. (from a 2.1.5 machine if it matters) I think it may be nfs related.. Sorry, Chris Csanady > >Btw, this is from a 10/04/96 kernel.. > >--Chris Csanady > From owner-freebsd-hackers Fri Nov 8 03:59:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA27718 for hackers-outgoing; Fri, 8 Nov 1996 03:59:19 -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 DAA27713 for ; Fri, 8 Nov 1996 03:59:15 -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 EAA22867 for ; Fri, 8 Nov 1996 04:05:00 -0600 (CST) Received: by bio-5.bsd.uchicago.edu (5.0/SMI-SVR4) id AA11205; Fri, 8 Nov 1996 04:04:53 +0600 Date: Fri, 8 Nov 1996 04:04:53 +0600 Message-Id: <9611081004.AA11205@bio-5.bsd.uchicago.edu> To: hackers@freebsd.org Subject: TIOCSPGRP on ptys? From: Tim Pierce Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In 2.1.5, TIOCSPGRP ioctls cannot be made on slave pseudo-terminals. In fact, the source for kern/tty_pty.c seems to be written to prevent *any* ioctls from being performed on slave ptys, and to prevent most TIOC ioctls from being performed on master ptys. Am I reading the source correctly? This behavior seems to be inconsistent with the pty(4) man page: The slave device provides to a process an in- terface identical to that described in tty(4). If this is the intended behavior, what is the `correct' (i.e. portable, non-deprecated) method for setting the process group for a pty? I see a TIOCSCTTY ioctl and a `login_tty' function in libutil, but no documentation, and am not sure whether these interfaces are stable or experimental. From owner-freebsd-hackers Fri Nov 8 04:02:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27983 for hackers-outgoing; Fri, 8 Nov 1996 04:02:02 -0800 (PST) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA27973 for ; Fri, 8 Nov 1996 04:01:56 -0800 (PST) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id LAA00866; Fri, 8 Nov 1996 11:59:46 GMT Date: Fri, 8 Nov 1996 11:59:44 +0000 (GMT) From: Doug Rabson To: Chris Csanady cc: hackers@freebsd.org Subject: Re: vnode_pager_input errors... In-Reply-To: <199611081132.FAA01931@friley216.res.iastate.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 Fri, 8 Nov 1996, Chris Csanady wrote: > > > > >I recently got the following message while doing a CVSup... > > > >Nov 8 04:48:17 friley216 /kernel: vnode_pager_getpages: I/O read error > >Nov 8 04:48:17 friley216 /kernel: vm_fault: pager input (probably hardware) > >error, PID 1573 failure > >Nov 8 04:49:20 friley216 /kernel: pid 1573 (cvsup), uid 0: exited on signal > 6 > >(core dumped) > > > >I also recently ran into this problem consistently on some of our 2.1.5 boxes. > >From reading through some of the mail list archives, I thought that it was > >a problem that was fixed quit a while ago.. > > > >Any ideas? > > I forgot to mention a rather important peice of information. The tree I was > CVSupping into was on an nfs mounted drive. (from a 2.1.5 machine if it > matters) > I think it may be nfs related.. 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? -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-hackers Fri Nov 8 04:15:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA28588 for hackers-outgoing; Fri, 8 Nov 1996 04:15:48 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA28529 for ; Fri, 8 Nov 1996 04:14:21 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA13440; Fri, 8 Nov 1996 12:37:52 +0100 From: Luigi Rizzo Message-Id: <199611081137.MAA13440@labinfo.iet.unipi.it> Subject: Re: Philips CDD2000 CD-R works as HP-4020i To: cau@cc.gatech.edu (Carlos Ugarte) Date: Fri, 8 Nov 1996 12:37:52 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199611040717.CAA04756@oscar.cc.gatech.edu> from "Carlos Ugarte" at Nov 4, 96 02:17:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I applied the changes to recognise the Philips CDD2000 CD-R to the 961014 snap and the drive is now recongnised as worm0. I have two problems though: 1) can I use it as a CD reader, by putting in a standard CDROM ? mount refuses to work on character devices as /dev/rworm0, and worm.c has no reference to a block device. I tried vnconfig /dev/vn0c /dev/rworm0 but with no luck 2) after making the appropriate changes to burncd.sh, I tried to use the writer in "dummy" mode, with a CDROM instead of a writable disk inside. No luck either, since I get a couple of 'illegal command' messages (but perhaps this is just because the writer wants to see a writable disk instead ?) Any help appreciated, especially on #1 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 Fri Nov 8 04:40:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA00600 for hackers-outgoing; Fri, 8 Nov 1996 04:40:42 -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 EAA00587 for ; Fri, 8 Nov 1996 04:40:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id EAA05360; Fri, 8 Nov 1996 04:38:52 -0800 (PST) Message-Id: <199611081238.EAA05360@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Julian Elischer cc: Archie Cobbs , freebsd-hackers@freebsd.org, mckusick@mckusick.com Subject: Re: Davidg bug (was: mount panics & hangs) In-reply-to: Your message of "Tue, 05 Nov 1996 17:21:56 PST." <327FE834.167EB0E7@whistle.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 08 Nov 1996 04:38:52 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >The only answer I can see is to either make the awakenned >process start again from scratch, >as the mp it has may no longer be valid, >or to put some sort of lock on the whole mount list. I'll look into a fix for this. Unfortunately it appears that similar problems exist in other functions that traverse the mount list. vfs_busy() appears to be fundamentally broken since it references "mp" after waking up from the sleep even though "mp" may no longer be valid. It appears that the only solution to the problem (avoiding massive changes) is to implement a lock around the mountlist. I think that this may create one or more deadlock potentials, however. >BTW there is another small bug, which is.. the return at line "C" >should also do a vfs_unbusy() Thanks! -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri Nov 8 04:41:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA00643 for hackers-outgoing; Fri, 8 Nov 1996 04:41:31 -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 EAA00638 for ; Fri, 8 Nov 1996 04:41:28 -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 GAA00324 for ; Fri, 8 Nov 1996 06:41:26 -0600 (CST) Message-Id: <199611081241.GAA00324@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: Write-back boot blocks? Why not... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 06:41:26 -0600 From: "Chris Csanady" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently came upon an IDE drive, so I have been poking around at things to get it to boot off my scsi. I must say, Im sure there are plenty of new, users that get fairly disgusted trying to this to work. :( Anyway, does the NAMEBLOCK_WRITEBACK feature of biosboot work? (documented in /sys/i386/boot/biosboot/Makefile) I noticed it was commented out. I think it would be a really nice feature for 2.2 if it worked. If not, perhaps the BOOT_HD_BIAS variable should be mentioned in the handbook or somewhere else obvious. :) Just thought I'd bring it to everyones attention.. --Chris Csanady From owner-freebsd-hackers Fri Nov 8 05:08:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA01888 for hackers-outgoing; Fri, 8 Nov 1996 05:08:44 -0800 (PST) Received: from marlin.com.br (blue.marlin.com.br [200.255.107.33]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA01832; Fri, 8 Nov 1996 05:08:32 -0800 (PST) Received: by marlin.com.br (8.6.12/SMI-4.1) id LAA15711; Fri, 8 Nov 1996 11:05:25 -0200 Date: Fri, 8 Nov 1996 11:05:23 -0200 (EDT) From: "Alexsandro D. F. Correia" To: announce@FreeBSD.ORG cc: isp@FreeBSD.ORG, questions@FreeBSD.ORG, hardware@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Problems restoring Backups !!! 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 Sirs, I'm having lots of troubles with my backups, and i hope someone can HELP ME. Here we have two machines with the same configuration. Pentium 100, 32 Mb RAM, HD 2.0 gb SCSI and an EXABYTE - 4mm Cartridge tape drive Running FreeBSD 2.1. That's the problem i have. I can write to the tape, but i can't read anything from the tape. When i try to restore a backup, using tar for example my system crashes. The computer tries to access de tape, and nothing happens, waits about two minutes and then the system CRASHES. Here follows the error msg the system sends to me: ahc0:target 3,lun 0 (st0) timet out st0(ahc0:3:0):BUS DEVICE RESET message Queued. st0(ahc0:3:0):TARGET Busy ahc0:A:3:no active SCB for reconnecting target - issuing ABORT. SAVED_TCL == 0x30 ahc0:target1,lun0(sd0) timed out By the way, I tested the restore on both machines, using CPIO and TAR. But everytime i try to access something from the tape to the HD, the system crashes. Any help or information will be useful. I need to soon this problem as soon as possible. Please, I'll be very glad if someone help me. Thanx a lot. Alexsandro Correia +-------------------------------------------------------------+ Alexsandro Correia E-mail: acorreia@marlin.com.br Analista de Suporte Internet Tel : +55 21 224-9950 +55 21 253-2971 +-------------------------------------------------------------+ Marlin Internet http://www.marlin.com.br Rua 7 de Setembro 48/13 Andar Tel: +55 21 224-9950 Centro - Rio de Janeiro Fax: +55 21 223-427 RJ - Brasil +-------------------------------------------------------------+ From owner-freebsd-hackers Fri Nov 8 05:13:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA02218 for hackers-outgoing; Fri, 8 Nov 1996 05:13: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 FAA02213 for ; Fri, 8 Nov 1996 05:13: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 FAA01830; Fri, 8 Nov 1996 05:09:03 -0800 (PST) To: Luigi Rizzo cc: cau@cc.gatech.edu (Carlos Ugarte), hackers@freebsd.org Subject: Re: Philips CDD2000 CD-R works as HP-4020i In-reply-to: Your message of "Fri, 08 Nov 1996 12:37:52 +0100." <199611081137.MAA13440@labinfo.iet.unipi.it> Date: Fri, 08 Nov 1996 05:09:03 -0800 Message-ID: <1828.847458543@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 1) can I use it as a CD reader, by putting in a standard CDROM ? > mount refuses to work on character devices as /dev/rworm0, > and worm.c has no reference to a block device. I tried > > vnconfig /dev/vn0c /dev/rworm0 > > but with no luck This is a known problem. The device functions either as a CDROM drive (if you don't assign it to worm0) or as a worm, but not both. According to Joerg, this is not trivial to fix and so he hasn't done it (or maybe it's relatively trivial but he just doesn't have any time, rendering it non-trivial in a different sense :-). Jordan From owner-freebsd-hackers Fri Nov 8 06:35:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA06345 for hackers-outgoing; Fri, 8 Nov 1996 06:35:09 -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 GAA06317 for ; Fri, 8 Nov 1996 06:34:50 -0800 (PST) Received: (from smap@localhost) by Guard.PolyNet.Lviv.UA (8.6.12/8.6.12) id QAA09031 for ; Fri, 8 Nov 1996 16:34:15 +0200 Received: from netsurfer.lp.lviv.ua(192.168.0.3) by Guard.PolyNet.Lviv.UA via smap (V2.0beta) id xma009024; Fri, 8 Nov 96 16:34:04 +0200 Received: (from smap@localhost) by NetSurfer.lp.lviv.ua (8.6.12/8.6.12) id QAA01383 for ; Fri, 8 Nov 1996 16:34:04 +0200 Received: from nova.lp.lviv.ua(192.168.0.6) by NetSurfer.lp.lviv.ua via smap (V2.0beta) id xma001380; Fri, 8 Nov 96 16:33:48 +0200 Message-ID: <328344CB.167E@polynet.lviv.ua> Date: Fri, 08 Nov 1996 16:33:47 +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 Subject: Q: How to read hardware port ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi How can i read hardware port in Unix ? Something like this: inport(#), inportb(#); Thanx -- # Slavik Terletsky # University "Lvivska Poytechnica" # # Network Administrator # mailto:ts@polynet.lviv.ua # From owner-freebsd-hackers Fri Nov 8 06:40:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA06668 for hackers-outgoing; Fri, 8 Nov 1996 06:40:03 -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 GAA06649; Fri, 8 Nov 1996 06:40:01 -0800 (PST) Message-Id: <199611081440.GAA06649@freefall.freebsd.org> To: "Alexsandro D. F. Correia" cc: hackers@FreeBSD.ORG Subject: Re: Problems restoring Backups !!! In-reply-to: Your message of "Fri, 08 Nov 1996 11:05:23 -0200." Date: Fri, 08 Nov 1996 06:40:01 -0800 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Please, I'll be very glad if someone help me. You didn't have to ask the entire world! One list would have been enough. Upgrade to a more recent version of FreeBSD and your problems will probably go away. The ahc driver in 2.1R was not that great. >Thanx a lot. > > Alexsandro Correia > >+-------------------------------------------------------------+ > Alexsandro Correia E-mail: acorreia@marlin.com.br > Analista de Suporte Internet Tel : +55 21 224-9950 > +55 21 253-2971 >+-------------------------------------------------------------+ > Marlin Internet http://www.marlin.com.br > Rua 7 de Setembro 48/13 Andar Tel: +55 21 224-9950 > Centro - Rio de Janeiro Fax: +55 21 223-427 > RJ - Brasil >+-------------------------------------------------------------+ > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Fri Nov 8 06:50:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA07137 for hackers-outgoing; Fri, 8 Nov 1996 06:50:54 -0800 (PST) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA07131 for ; Fri, 8 Nov 1996 06:50:49 -0800 (PST) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id PAA00718; Fri, 8 Nov 1996 15:49:34 +0100 Message-Id: <199611081449.PAA00718@ra.dkuug.dk> Subject: Re: Q: How to read hardware port ? To: ts@polynet.lviv.ua (Slavik Terletsky) Date: Fri, 8 Nov 1996 15:49:34 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <328344CB.167E@polynet.lviv.ua> from "Slavik Terletsky" at Nov 8, 96 04:33:47 pm From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Slavik Terletsky who wrote: > > Hi > How can i read hardware port in Unix ? > Something like this: inport(#), inportb(#); > Thanx Open /dev/io and use the inb/outb etc functions, you must be root though for this to work (with good reason). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Fri Nov 8 07:09:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA08996 for hackers-outgoing; Fri, 8 Nov 1996 07:09:59 -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 HAA08986 for ; Fri, 8 Nov 1996 07:09:55 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id PAA05711; Fri, 8 Nov 1996 15:09:44 GMT Date: Sat, 9 Nov 1996 00:09:44 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: David Greenman cc: freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... In-Reply-To: <199611081024.CAA05116@root.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, 8 Nov 1996, David Greenman wrote: > I don't think you understand: I understand your position on this and the > benefits as you've articulated them are very clear. I simply disagree with > you on this topic. My opinion is that I don't like what it does to the sources > (adding lots of redundant and usually useless assertions), nor do I like the Actually, this is where you misunderstand. I am not an advocate of defensive programming. Defensive programming means that you add a lot of redundant checks and you write code assuming the unexpected. This is bad because it becomes hard to find the real code from all the checking code. I see the use of assertions as a way of making it so that we can have expections of how things operate. The writer of the function specifies his expectations and the consumer of the function doesn't have to write redundant checks before calling the function because he knows what to expect. The writer of the function also doesn't have to do redundant checking when passing the parameters to another function. And maybe the the latter function doesn't need to do checking because it is a helper function and it can assume that it's consumer has already done the checking. If assertions are applied properly they can actually reduce the number of checks done in the code and this is what you are missing completely. You can't tell me that there aren't redundant and unnecessary checks in the fs code already. I advocate that some of these are actually taken out and others moved to where they are "strategic". If you can't swallow the macros then please consider the following: Proactive use of FreeBSD assertion model. ==================================================================== void vrele(vp) register struct vnode *vp; { /* parameter checking section */ #ifdef DIAGNOSTIC if (vp == NULL) panic("vrele: null vp"); #endif if (vp->v_usecount <= 0) { #ifdef DIAGNOSTIC vprint("vrele: negative ref count", vp); #endif panic("vrele: negative reference cnt"); } /* start of actual code body */ vp->v_usecount--; if ((vp->v_usecount == 1) && vp->v_object && (vp->v_object->flags & OBJ_VFS_REF)) { vp->v_object->flags &= ~OBJ_VFS_REF; vm_object_deallocate(vp->v_object); return; } if (vp->v_usecount > 0) return; [ .. ] Reactive use of FreeBSD assertion model. ==================================================================== void vrele(vp) register struct vnode *vp; { #ifdef DIAGNOSTIC if (vp == NULL) panic("vrele: null vp"); #endif vp->v_usecount--; if ((vp->v_usecount == 1) && vp->v_object && (vp->v_object->flags & OBJ_VFS_REF)) { vp->v_object->flags &= ~OBJ_VFS_REF; vm_object_deallocate(vp->v_object); return; } if (vp->v_usecount > 0) return; if (vp->v_usecount < 0) { #ifdef DIAGNOSTIC vprint("vrele: negative ref count", vp); #endif panic("vrele: negative reference cnt"); } [ ... ] ============================================================ The changes are subtle but the improvement is that we have a body of code that only does real work and we have a body of code that is only debugging infrastructure. Instead of doing an operation and seeing if we have garbage, we refuse to accept garbage period. The distinction is important. Regards, Mike Hancock From owner-freebsd-hackers Fri Nov 8 07:14:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA10140 for hackers-outgoing; Fri, 8 Nov 1996 07:14:46 -0800 (PST) Received: from conviction.CS.Berkeley.EDU (conviction.CS.Berkeley.EDU [128.32.33.103]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA10131 for ; Fri, 8 Nov 1996 07:14:40 -0800 (PST) Received: from conviction.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by conviction.CS.Berkeley.EDU (8.8.2/8.8.2) with ESMTP id HAA17745; Fri, 8 Nov 1996 07:14:04 -0800 (PST) Message-Id: <199611081514.HAA17745@conviction.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 To: Julian Assange cc: freebsd-hackers@freebsd.org Subject: Re: grub In-reply-to: Your message of "Fri, 01 Nov 1996 22:09:09 +1100." <199611011109.WAA24746@suburbia.net> From: bmah@cs.berkeley.edu (Bruce A. Mah) Reply-to: bmah@cs.berkeley.edu X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 07:14:04 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Assange writes: > > http://uruk.uruk.org/grub > > A fine replacement for the current boot loader, with strong bsd > support. /usr/src/contrib? This is kind of nifty, with only two problems I can see: 1. The FreeBSD version of GAS is too old to assemble one of the .S files. Maybe it's not a showstopper because the grub distribution comes with a set of binaries, but it certainly made for some head-scratching as I was trying to make a couple of changes (see below). 2. It doesn't currently support any analog to BOOT_HD_BIAS in the FreeBSD boot loader. I've hacked up something simple, will send it back to erich@uruk.org when I've tested it a bit. Bruce. From owner-freebsd-hackers Fri Nov 8 07:18:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA10484 for hackers-outgoing; Fri, 8 Nov 1996 07:18:11 -0800 (PST) Received: from interlock.lexmark.com (interlock.lexmark.com [192.146.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA10473 for ; Fri, 8 Nov 1996 07:18:06 -0800 (PST) Received: by interlock.lexmark.com id AA29714 (InterLock SMTP Gateway 3.0 for hackers@FreeBSD.ORG); Fri, 8 Nov 1996 10:17:49 -0500 Message-Id: <199611081517.AA29714@interlock.lexmark.com> Received: by interlock.lexmark.com (Protected-side Proxy Mail Agent-2); Fri, 8 Nov 1996 10:17:49 -0500 Received: by interlock.lexmark.com (Protected-side Proxy Mail Agent-1); Fri, 8 Nov 1996 10:17:49 -0500 To: "hackers%FreeBSD.ORG" From: Larry S Lile Date: 8 Nov 96 10:16:51 EST Subject: Pinnacle RCD Driver Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am currently working on a driver for the Pinnacle RCD 5040i. My original plan was to attempt to integrate support for this device under Joerg's worm driver but it differs to much from the HP/Phillips drives to do this (or at least for me to be able to) I have a pretty good start on the driver and so far Pinnacle is helping me some of there less clearly documented scsi commands. What I am having trouble with and I know that these are probably simple questions, but bear with me as I have never had to deal with Un*x drivers from this side of the street before, are the minor numbers, (cb)devsw, and the partition information. I am also trying to write the driver in such a way that I can interface directly back to Julian's cd driver to give the device full functionality as both an RCD and CD. As to minor numbers, I have seen mention of things like "5 bit unit" in the cd driver, according to documentation Pinnacle sent to me the RCD is an 8 bit device, but supports all cd commands that the cd driver has implemented. So do I set up the minor number in the same way Julian set up the minor number for a cd or should I use the method that Joerg used for the worm driver as the RCD is a worm device? Or have they taken two different implementation methods because cd supports both block and character but worm only currently supports character. Second, I have seen what appear to be 2 disperate cdevsw structure definitions, could some one clarify what exactly the definition of this should be for me. I have compared the implementation of sd, cd, and worm but now I am totally confused Last, I really don't get the partition stuff in the cd driver whatsoever, or worse the device filesystem (DEVFS) stuff. I am fairly sure that I can write the driver functions to operate the drive, its just the interface to the kernel and low-level scsi driver that I don't understand. I have just never had to deal with them before and I don't have much documentation on what is required to do so. Larry Lile lslile@lexmark.com From owner-freebsd-hackers Fri Nov 8 07:41:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA15085 for hackers-outgoing; Fri, 8 Nov 1996 07:41:51 -0800 (PST) Received: from rocket.comtrol.com (rocket.comtrol.com [204.73.219.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA15080 for ; Fri, 8 Nov 1996 07:41:47 -0800 (PST) Received: from amirpc (amir [204.73.219.82]) by rocket.comtrol.com (8.6.9/8.6.9) with SMTP id JAA00123 for ; Fri, 8 Nov 1996 09:41:05 -0600 Date: Fri, 8 Nov 1996 09:41:05 -0600 Message-Id: <199611081541.JAA00123@rocket.comtrol.com> X-Sender: amir@comtrol.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: amir@comtrol.com (Amir Farah) Subject: timeout() function Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello I have a question about the timeout() function in /sys/kern/kern_clock.c file. You can execute a function after a specified length of time using timeout(ftn, arg, ticks) ftn: function to be called args: arguments for the function ticks: delay If I pass "1" for the delay, does it mean the function will get called every 1 second?? I want to be able to call a funtion every 50 milisecond (or less). Can anyone set me straight on this issue. Thanks amir From owner-freebsd-hackers Fri Nov 8 07:48:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA15507 for hackers-outgoing; Fri, 8 Nov 1996 07:48:34 -0800 (PST) Received: from handset.laa.com (laa.com [204.7.172.201]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA15493 for ; Fri, 8 Nov 1996 07:48:28 -0800 (PST) Received: from erlang by handset.laa.com (NX5.67f2/NX3.0M) id AA08574; Fri, 8 Nov 96 10:47:53 -0500 Message-Id: <9611081547.AA08574@handset.laa.com> Received: by erlang.laa.com (NX5.67e/NX3.0X) id AA05635; Fri, 8 Nov 96 10:48:14 -0500 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2) Received: by NeXT.Mailer (1.118.3) From: Sean Willson Date: Fri, 8 Nov 96 10:48:09 -0500 To: hackers@freebsd.org Subject: JDK 1.0.2 on FreeBSD Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I am looking for the Java JDK 1.0.2 on FreeBSD. Can anyone tell me = where to find it or where I can obtain more information on it? I would = greatly appreciate it. Thanks.... Sean Willson --- Sean M. Willson. Lynn-Arthur Associates, Inc. +1 313 995 5590 willson@laa.com Operations Support Systems +1 313 995 5989 = (fax) 2350 Green Road Suite 160 Ann Arbor, MI, 48105 = USA= From owner-freebsd-hackers Fri Nov 8 07:56:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA16531 for hackers-outgoing; Fri, 8 Nov 1996 07:56:07 -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 HAA16472 for ; Fri, 8 Nov 1996 07:56:02 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id CAA08229; Sat, 9 Nov 1996 02:51:00 +1100 Date: Sat, 9 Nov 1996 02:51:00 +1100 From: Bruce Evans Message-Id: <199611081551.CAA08229@godzilla.zeta.org.au> To: hackers@FreeBSD.org, twpierce@midway.uchicago.edu Subject: Re: TIOCSPGRP on ptys? Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >In 2.1.5, TIOCSPGRP ioctls cannot be made on slave >pseudo-terminals. In fact, the source for kern/tty_pty.c seems to >be written to prevent *any* ioctls from being performed on slave >ptys, and to prevent most TIOC ioctls from being performed on >master ptys. > >Am I reading the source correctly? This behavior seems to be >inconsistent with the pty(4) man page: > > The slave device provides to a process an in- > terface identical to that described in tty(4). > >If this is the intended behavior, what is the `correct' Everything is as intended. TIOCSPGRP only works on controlling terminals, which is often not what is wanted. >(i.e. portable, non-deprecated) method for setting the process >group for a pty? I see a TIOCSCTTY ioctl and a `login_tty' >function in libutil, but no documentation, and am not sure whether >these interfaces are stable or experimental. There is no portable method. In BSD4.4Lite, there is essentially only one working method: 1. Stop being a process group leader, e.g., by forking and continuing in the child. This is necessary for step 2 to work. See setsid(2). 2. Open the new tty. 3. Call setsid() to become a session leader. 4. Call ioctl(fd, TIOCSCTTY) to get a controlling terminal. 5. Call tcsetpgrp(fd, groupid) or an ioctl to set the process group. login_tty() does steps (3) and (4) plus some simple plumbing. It is documented in lgin_tty.c :-). These interfaces have been stable for 4+ years. Controlling terminals don't go away until the are completely closed and the session leader exits. Session leaders can change their controlling terminal, but this is not much use for avoiding the fork in step (1) - normally the session leader is a shell, and child processes neither can nor want to change the main controlling terminal. Bruce From owner-freebsd-hackers Fri Nov 8 08:08:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18419 for hackers-outgoing; Fri, 8 Nov 1996 08:08:07 -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 IAA18405 for ; Fri, 8 Nov 1996 08:08:03 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA08647; Fri, 8 Nov 1996 09:07:53 -0700 (MST) Date: Fri, 8 Nov 1996 09:07:53 -0700 (MST) Message-Id: <199611081607.JAA08647@rocky.mt.sri.com> From: Nate Williams To: John Fieber Cc: hackers@freebsd.org, Craig Leres Subject: Re: Who owns PCMCIA? In-Reply-To: References: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Me mostly. > It might be a good idea to update this and the ancillary pages to have > the list of pcmcia hardware supported by freebsd. Just now I was trying > to pick a pcmcia scsi controller and as far as I could tell by looking > at the online handbook, no controllers are supported. That is true. No SCSI controllers are supported by FreeBSD. > But we eventually > found /etc/pccard.conf and found that at least 3 different cards are > supported. If you install the PAO package they are supported, but the PAO package contains lots of additional drivers that are not (yet) in FreeBSD. I asked Poul to allow me to bring them into 2.2, but due to my workload it's probably too late in getting the drivers and patches in 2.2 So, the handbook entries should stay the same, since they are still valid. Nate From owner-freebsd-hackers Fri Nov 8 08:11:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18619 for hackers-outgoing; Fri, 8 Nov 1996 08:11:28 -0800 (PST) Received: from burdell.cc.gatech.edu (root@burdell.cc.gatech.edu [130.207.3.207]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA18613 for ; Fri, 8 Nov 1996 08:11:21 -0800 (PST) Received: from oscar.cc.gatech.edu (cau@oscar.cc.gatech.edu [130.207.107.12]) by burdell.cc.gatech.edu (8.8.Beta.5/8.6.9) with ESMTP id LAA22984; Fri, 8 Nov 1996 11:11:14 -0500 (EST) Received: (from cau@localhost) by oscar.cc.gatech.edu (8.8.Beta.5/8.6.9) id LAA11686; Fri, 8 Nov 1996 11:11:08 -0500 (EST) From: cau@cc.gatech.edu (Carlos Ugarte) Message-Id: <199611081611.LAA11686@oscar.cc.gatech.edu> Subject: Re: Philips CDD2000 CD-R works as HP-4020i To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Fri, 8 Nov 1996 11:11:08 -0500 (EST) Cc: cau@cc.gatech.edu, hackers@freebsd.org In-Reply-To: <199611081137.MAA13440@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 8, 96 12:37: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 > 1) can I use it as a CD reader, by putting in a standard CDROM ? > mount refuses to work on character devices as /dev/rworm0, > and worm.c has no reference to a block device. I tried > > vnconfig /dev/vn0c /dev/rworm0 > > but with no luck I think Jordan answered this one; essentially no for now. I used to keep my old SCSI CD-ROM unit around, but at this moment I'm having to boot from a different kernel (GENERIC should work) that doesn't recognize this as a worm device. > 2) after making the appropriate changes to burncd.sh, I tried to use > the writer in "dummy" mode, with a CDROM instead of a writable disk > inside. No luck either, since I get a couple of 'illegal command' > messages (but perhaps this is just because the writer wants to see a > writable disk instead ?) I have a few ideas about this: That's how I did it at first, test in dummy mode, then burning. You probably have the same thing for the script as I do, but here's the relevant parts that were used to test: echo -n "Place CD in the worm drive now and press return: " read junk scsi -f /dev/rworm0.ctl -c "0 0 0 0 0 0" >/dev/null 2>&1 wormcontrol select HP 4020i wormcontrol prepdisk double dummy wormcontrol track data rtprio 5 team -v 1m 5 < $1 | dd of=/dev/rworm0 obs=20k wormcontrol fixate 1 That was from my "testcd" script; the only difference from the burncd.sh script was adding dummy to the second wormcontrol line. You can leave the quirks as "HP 4020i", and I think "Philiips CDD2000" should also work (that's what I sent to Joerg). I can send you the diffs too if you need that. Most likely, I think, is that it the CDD2000 will not test with a CD-ROM in there (you may need a blank CD-R). I didn't try to do the dummy on a CD-ROM, used a CD-R instead. When in dummy mode, the write light will blink alternating between yellow/orange and green. When in burn mode it stays yellow/orange the entire time. Last thing I can think of is that I'm using firmware version 1.26. It's available via Philips' web site; one of the places to get it would be http://www-us.philips.com:80/pkm/laseroptics/cdr/ but there are mirrors elsewhere. Let me know if there's something else I can do. Carlos -- Carlos A. Ugarte cau@cc.gatech.edu Author of PageMage, a virtual desktop util for OS/2 http://www.cc.gatech.edu/people/home/cau/ If you understand what you're doing, you are not learning anything From owner-freebsd-hackers Fri Nov 8 08:12:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18664 for hackers-outgoing; Fri, 8 Nov 1996 08:12: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 IAA18645; Fri, 8 Nov 1996 08:11:56 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12109; Fri, 8 Nov 1996 09:02:33 -0700 From: Terry Lambert Message-Id: <199611081602.JAA12109@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: dg@root.com Date: Fri, 8 Nov 1996 09:02:32 -0700 (MST) Cc: terry@lambert.org, ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199611080249.SAA04382@root.com> from "David Greenman" at Nov 7, 96 06:49:56 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 patch *is* a kludge: it's a kludge against the fact that there is > >a two stage decommit (which is itself a kludge, with no way to recover > >perfectly valid data hung off an in core vnode buffer list pointer once > >the FS data has been dissociated from that vnode). The problem is the > >race conditions in the two stage decommit during a period of incresing > >demand and high vnode reuse. > > As always, trying to parse what you're saying is difficult. I interpret > what you're saying above as there being a race condition when allocating > inode+vnode pairs (since either one can block and thus someone else might > get in there and try to do the same thing for the same inode). > I fixed that race condition over a year ago by adding a mutex lock and by > a series of allocation order changes. I might have missed a rarely used > filesystem (msdosfs?), but the race condition for FFS has been fixed since > July '95. I understand that this is the official "fix" for the problem. This is the "doctor: Then don't do that" scenario. If that reerence wasn't clear in my earlier post: Patient: It hurts when I do this Doctor: Then don't do that The "doctor: Then don't do that" scenario is not a good way to fix things... it's the difference between: A calls B B has a bug that A tickles Let's change A to not tickle B As opposed to the right thing to do, which is: Let's change B to not have the bug You'll notice that one of the things I asked him was "What FS types do you have mounted?". Without getting into the whole "this code should be infrastructure instead of being duplicated (potentially erroneously) in every file system" argument, my suggested "fix" simply prevented one class of problems from occuring. I didn't claim it would fix everything (as a matter of fact, I've only said that it was a slightly better kludge). With getting into that argument...: My basic problem is that it's bad to build implied state into interfaces, especially if you smear state maintenance to both sides of the interface boundries. If you document exit and entry state for a function in an interface, that's OK, as long as you *must* recross that same boundry to change the state *each time* it is changed. I *do* understand that you have to do that kind of thing, at a minimum to provide locking interfaces. However, even granting that, the way the vnode management currently works *still* violates the architecture model and leaves us with something-that-should-be-a-black-box-but-isn't. The problem we have is that we have one or more state transitions for the locking which occur on both sides of the interface. That's nothing more than bad abstraction in the design of the interface in the first place. My suggested assert "fixes" are also kludges. They invert the service order for the interface to make some function in the stack trace at the time of the panic be the responsible party. Nevertheless, they are a hell of a lot better than a delayed (cascade) failure with no way to find the guilty party. I see little conceptual difference between this and unmapping page zero to trap NULL pointer dereferences when they happen instead of letting something (apparently unrelated) fail at some later time. It was The Right Thing To Do to localize NULL dereferences, and a similar fix is The Right Thing To Do to localize errors in non-opaque interfaces. That all interfaces should be opaque in the first place is kind of irrevent to the applicability if the fix. The service interface call inversion is unavoidable as long as the association of an inode with a vnode is, in effect, registration of a callback function into the FS for later use by vclean. Having two or more inodes point at the same vnode makes problems like those we are seeing *likely*, so long as the association interface is split across the same boundry at which the lock interface is being defined. Someone is bound to make an error implementing the undocumented implied state... I can point to one *right now* in the MSDOSFS directory traversal parent/child race on a VOP_CREATE. It's obvious that we can't consider every possible call graph and its effect on implied state. The only real soloution is to *not allow* state implication so that it isn't ever an issue ever again. For what it's worth, yes, I do claim that my veto-vs-calldown interface reorganization, and the single-entry-singe-exit changes for simplifying the state transition map, would have been the correct first steps on the path to a real fix. 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 8 08:25:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20011 for hackers-outgoing; Fri, 8 Nov 1996 08:25: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 IAA20005; Fri, 8 Nov 1996 08:25:08 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12133; Fri, 8 Nov 1996 09:14:34 -0700 From: Terry Lambert Message-Id: <199611081614.JAA12133@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: dg@root.com Date: Fri, 8 Nov 1996 09:14:34 -0700 (MST) Cc: michaelh@cet.co.jp, terry@lambert.org, ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199611080307.TAA04492@root.com> from "David Greenman" at Nov 7, 96 07:07: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 [ ... somone's proposed assert model ... ] > We've been down this road before. The asserts model isn't very well liked > by a lot of people, including myself. It tends to bloat the sources with a > lot of unuseful checks and isn't flexible enough to accomodate more > algorithmically complex checks. For what it's worth: Proper interface abstraction precludes the need for algorithmically complex checks. The need for complexity arises from the same statite (stateful object) being modified on both sides of the interface. Interfaces are to abstract state, not to imply it. The number of identifiable cross-interface statite manipulations that exist is another was to say "minimum level of fractal complexity visible to an interface consumer". Or to put it in English terminology instead of mathematics: Complexity is inversely proportional to elegance You can put both of these in the "fortunes" file if you attribute them. 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 8 08:27:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20169 for hackers-outgoing; Fri, 8 Nov 1996 08:27:13 -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 IAA20162; Fri, 8 Nov 1996 08:27:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12148; Fri, 8 Nov 1996 09:17:40 -0700 From: Terry Lambert Message-Id: <199611081617.JAA12148@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: dg@root.com Date: Fri, 8 Nov 1996 09:17:40 -0700 (MST) Cc: michaelh@cet.co.jp, terry@lambert.org, ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199611081024.CAA05116@root.com> from "David Greenman" at Nov 8, 96 02:24:38 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 > >Are you going to "out-stubborn" me again? > > I don't think you understand: I understand your position on this and the > benefits as you've articulated them are very clear. I simply disagree with > you on this topic. My opinion is that I don't like what it does to the sources > (adding lots of redundant and usually useless assertions), nor do I like the > style (macroized condition expressions). My opinion on this isn't going to > change, and I'm not the only core member who has this opinion. As an alternative, may I suggest properly abstracting the interfaces so that no matter how the "black box" that implements them acts, it acts correctly? 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 8 08:32:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20538 for hackers-outgoing; Fri, 8 Nov 1996 08:32:45 -0800 (PST) Received: from interlock.lexmark.com (interlock.lexmark.com [192.146.101.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA20532 for ; Fri, 8 Nov 1996 08:32:34 -0800 (PST) Received: by interlock.lexmark.com id AA02293 (InterLock SMTP Gateway 3.0 for hackers@freebsd.org); Fri, 8 Nov 1996 11:32:12 -0500 Message-Id: <199611081632.AA02293@interlock.lexmark.com> Received: by interlock.lexmark.com (Protected-side Proxy Mail Agent-2); Fri, 8 Nov 1996 11:32:12 -0500 Received: by interlock.lexmark.com (Protected-side Proxy Mail Agent-1); Fri, 8 Nov 1996 11:32:12 -0500 To: "hackers%FreeBSD.ORG" From: Larry S Lile Date: 8 Nov 96 11:29:16 EST Subject: Re: Pinnacle RCD Driver Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I apologize for the poor fomatting of this message, and for the waste of bandwidth, but to make it readable I will repost it. ( Lotus Notes / Proportional Fonts / Broken Mail gateway --- Help, help I'm being repressed!! :) > I am currently working on a driver for the Pinnacle RCD 5040i. My > original plan was to attempt to integrate support for this device under > Joerg's worm driver but it differs to much from the HP/Phillips drives > to do this (or at least for me to be able to) I have a pretty good start > on the driver and so far Pinnacle is helping me some of there less > clearly documented scsi commands. > > What I am having trouble with and I know that these are probably > simple questions, but bear with me as I have never had to deal with > Un*x drivers from this side of the street before, are the minor numbers, > (cb)devsw, and the partition information. I am also trying to write the > driver in such a way that I can interface directly back to Julian's cd > driver to give the device full functionality as both an RCD and CD. > > As to minor numbers, I have seen mention of things like "5 bit unit" in > the cd driver, according to documentation Pinnacle sent to me the RCD > is an 8 bit device, but supports all cd commands that the cd driver has > implemented. So do I set up the minor number in the same way Julian > set up the minor number for a cd or should I use the method that Joerg > used for the worm driver as the RCD is a worm device? Or have they > taken two different implementation methods because cd supports both > block and character but worm only currently supports character. > > Second, I have seen what appear to be 2 disperate cdevsw structure > definitions, could some one clarify what exactly the definition of this > should be for me. I have compared the implementation of sd, cd, and > worm but now I am totally confused > > Last, I really don't get the partition stuff in the cd driver whatsoever, > or worse the device filesystem (DEVFS) stuff. > > I am fairly sure that I can write the driver functions to operate the drive, > its just the interface to the kernel and low-level scsi driver that I don't > understand. I have just never had to deal with them before and I don't > have much documentation on what is required to do so. > > Larry Lile > lslile@lexmark.com From owner-freebsd-hackers Fri Nov 8 08:39:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA21022 for hackers-outgoing; Fri, 8 Nov 1996 08:39: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 IAA21016 for ; Fri, 8 Nov 1996 08:39:35 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12213; Fri, 8 Nov 1996 09:30:23 -0700 From: Terry Lambert Message-Id: <199611081630.JAA12213@phaeton.artisoft.com> Subject: Re: Strange messages from my 2.1.0 kernel To: john@starfire.mn.org Date: Fri, 8 Nov 1996 09:30:23 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: <199611080937.DAA03390@starfire.mn.org> from "john@starfire.mn.org" at Nov 8, 96 03:37:42 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 > Can anyone help me understand what these mean? > fhtovp: file start miss 1946157056 vs 68 It might mean you have two nfsnodes pointing to the same vnode... Or it might mean someone is trying to NFS hack your system... Or it might be an mmap() of an NFS file on an FS with a 4k block size and an NFS rzise/wsize of 8K, or vice versa... 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 8 09:09:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA22777 for hackers-outgoing; Fri, 8 Nov 1996 09:09:26 -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 JAA22771 for ; Fri, 8 Nov 1996 09:09:23 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id RAA06234 for ; Fri, 8 Nov 1996 17:09:21 GMT Date: Sat, 9 Nov 1996 02:09:21 +0900 (JST) From: Michael Hancock To: FreeBSD Hackers Subject: queue.h nit again Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Gawd, this bugs the crap out of me. Please change the following and similar in queue.h: #define TAILQ_ENTRY(type) \ struct { \ struct type *tqe_next; /* next element */ \ struct type **tqe_prev; /* address of previous next element */ \ } to either ... #define TAILQ_ENTRY(tag) \ struct { \ struct tag *tqe_next; /* next element */ \ struct tag **tqe_prev; /* address of previous next element */ \ } or ... #define TAILQ_ENTRY(type) \ struct { \ type *tqe_next; /* next element */ \ type **tqe_prev; /* address of previous next element */ \ } The typedef name space and tag name space in are oblivous to each other in C and confusing the two like this is setting a bad example. Poul and John prefer the latter. The former has very little impact on the sources. Regards, Mike Hancock From owner-freebsd-hackers Fri Nov 8 09:20:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23642 for hackers-outgoing; Fri, 8 Nov 1996 09:20:47 -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 JAA23624 for ; Fri, 8 Nov 1996 09:20:40 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA06990; Fri, 8 Nov 1996 12:20:02 -0500 Received: from lambert.org by dg-rtp.dg.com.rtp.dg.com; Fri, 8 Nov 1996 12:20 EST Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.7.5/8.7.3) with UUCP id LAA27519 for freefall.cdrom.com!freebsd-hackers; Fri, 8 Nov 1996 11:51:26 -0500 (EST) Received: from reggae.ncren.net by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA04912; Fri, 8 Nov 1996 11:45:30 -0500 Received: from mcnc.UUCP by reggae.ncren.net (5.65/tas-reggae/may94) id AA14333; Fri, 8 Nov 96 11:45:01 -0500 Received: from ncnoc.ncren.net by reggae.ncren.net (5.65/tas-reggae/may94) id AA14317; Fri, 8 Nov 96 11:44:09 -0500 Received: from stingray.mcnc.org (stingray.mcnc.org [128.109.130.74]) by ncnoc.ncren.net (8.7.4/8.7.3) with ESMTP id LAA19871; Fri, 8 Nov 1996 11:42:36 -0500 (EST) Received: from relay2.UU.NET by stingray.mcnc.org (8.7.5/MCNC/8-10-92) id LAA18851; Fri, 8 Nov 1996 11:41:12 -0500 (EST) for Received: from coyote.Artisoft.COM by relay2.UU.NET with ESMTP (peer crosschecked as: coyote.Artisoft.COM [198.17.250.162]) id QQboys15660; Fri, 8 Nov 1996 11:40:23 -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 JAA12242; Fri, 8 Nov 1996 09:35:19 -0700 (MST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12197; Fri, 8 Nov 1996 09:26:57 -0700 From: Terry Lambert Message-Id: <199611081626.JAA12197@phaeton.artisoft.com> Subject: Re: More info on the daily panics... To: ponds!ponds!rivers (Thomas David Rivers) Date: Fri, 8 Nov 1996 09:26:57 -0700 (MST) Cc: ponds!lambert.org!terry, ponds!Artisoft.COM!ponds!rivers, ponds!Artisoft.COM!ponds!freebsd.org!dyson, ponds!Artisoft.COM!ponds!freefall.cdrom.com!freebsd-hackers, ponds!Artisoft.COM!ponds!lakes.water.net!rivers, ponds!Artisoft.COM!ponds!lambert.org!terry In-Reply-To: <199611080143.UAA03593@lakes.water.net> from "Thomas David Rivers" at Nov 7, 96 08:43:45 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 > > The patch only prevents a condition from occuring instead of panic'ing > > when it does occur. Ie: it prevents one less error condition that can't > > be handled from needing to be checked, and then "not handled" (panic). > > Ok, then we can deduce that my panic was not from this condition, right? > (Since this condition can no longer occur, and I still get the panic...) This particular panic on this particular occasion, anyway. Do you export any FS's to NFS clients? I believe the similar problem to which David refers is a cascade error related to client usage of the VFS (there are too many possiblities at this point, frankly). The NFS, like the vfs_syscalls.c, is a client of VFS services. 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 8 09:20:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23654 for hackers-outgoing; Fri, 8 Nov 1996 09: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 JAA23621 for ; Fri, 8 Nov 1996 09:20:38 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA07019; Fri, 8 Nov 1996 12:20:07 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 8 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 MAA27611; Fri, 8 Nov 1996 12:01:45 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id MAA05136; Fri, 8 Nov 1996 12:02:52 -0500 (EST) Date: Fri, 8 Nov 1996 12:02:52 -0500 (EST) From: Thomas David Rivers Message-Id: <199611081702.MAA05136@lakes.water.net> To: ponds!freebsd.org!dyson, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers, ponds!lambert.org!terry Subject: Re: More info on the daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry writes: > > > > The patch only prevents a condition from occuring instead of panic'ing > > > when it does occur. Ie: it prevents one less error condition that can't > > > be handled from needing to be checked, and then "not handled" (panic). > > > > Ok, then we can deduce that my panic was not from this condition, right? > > (Since this condition can no longer occur, and I still get the panic...) > > This particular panic on this particular occasion, anyway. > > Do you export any FS's to NFS clients? I believe the similar problem > to which David refers is a cascade error related to client usage of the > VFS (there are too many possiblities at this point, frankly). > > The NFS, like the vfs_syscalls.c, is a client of VFS services. > > Yes, I do export some file systems to NFS clients... my /etc/exports: / -alldirs -maproot=0 /usr -alldirs -maproot=0 However, nobody mounts them. I can be sure of this because there are physically only two machines on this network, and the other machine does no NFS mounting... Now, the machine getting the panics is doing some NFS mounting, as described in previous mail. - Dave Rivers - From owner-freebsd-hackers Fri Nov 8 10:57:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA29637 for hackers-outgoing; Fri, 8 Nov 1996 10:57:16 -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 KAA29600 for ; Fri, 8 Nov 1996 10:56:42 -0800 (PST) From: john@starfire.mn.org Received: (from john@localhost) by starfire.mn.org (8.7.5/1.1) id MAA04307; Fri, 8 Nov 1996 12:55:02 -0600 (CST) Message-Id: <199611081855.MAA04307@starfire.mn.org> Subject: Re: Strange messages from my 2.1.0 kernel To: terry@lambert.org (Terry Lambert) Date: Fri, 8 Nov 1996 12:55:02 -0600 (CST) Cc: hackers@FreeBSD.org (FreeBSD hackers) In-Reply-To: <199611081630.JAA12213@phaeton.artisoft.com> from "Terry Lambert" at Nov 8, 96 09:30:23 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Can anyone help me understand what these mean? > > fhtovp: file start miss 1946157056 vs 68 > > It might mean you have two nfsnodes pointing to the same vnode... > Or it might mean someone is trying to NFS hack your system... > Or it might be an mmap() of an NFS file on an FS with a 4k block > size and an NFS rzise/wsize of 8K, or vice versa... Oh! OK! That makes perfect sense, then. A remote system had had my CD NFS mounted, but I rebooted, and my CD does not get automatically booted on mount (I hate to automatically mount removeable media). Thanks! John Lind, Starfire Consulting Services E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417 From owner-freebsd-hackers Fri Nov 8 11:08:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00975 for hackers-outgoing; Fri, 8 Nov 1996 11:08:04 -0800 (PST) Received: from ravenock.cybercity.dk (disn58.cybercity.dk [194.16.57.58]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA00861 for ; Fri, 8 Nov 1996 11:07:12 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.2/8.7.3) id UAA06680 for hackers@freebsd.org; Fri, 8 Nov 1996 20:08:11 +0100 (MET) Message-Id: <199611081908.UAA06680@ravenock.cybercity.dk> Subject: TDV6230 Xterminal question... To: hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 20:08:00 +0100 (MET) From: "Soren Schmidt" 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 Anybody know these ?? Mine suddenly has decided to put a passwd on the setup, anybody know how to get rid of that (I dont know the passwd :( ) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Fri Nov 8 12:14:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05963 for hackers-outgoing; Fri, 8 Nov 1996 12:14:45 -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 MAA05941; Fri, 8 Nov 1996 12:14:37 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id OAA02803; Fri, 8 Nov 1996 14:14:34 -0600 (CST) Received: from Mars.mcs.net (mikebo@Mars.mcs.com [192.160.127.85]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id OAA06140; Fri, 8 Nov 1996 14:14:32 -0600 (CST) Received: (from mikebo@localhost) by Mars.mcs.net (8.8.2/8.8.2) id OAA24913; Fri, 8 Nov 1996 14:14:30 -0600 (CST) From: Michael Borowiec Message-Id: <199611082014.OAA24913@Mars.mcs.net> Subject: /kernel: nfsd send error 55 (No buffer space available) To: hackers@freebsd.org Date: Fri, 8 Nov 1996 14:14:30 -0600 (CST) Cc: bugs@freebsd.org Reply-To: mikebo@tellabs.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I sent this message to the "questions" list, but got nothing... Greetings - I have a Toshiba Tecra 720CDT w/48MB and a 3Com 3C589C PCCARD ethernet. I'm configuring this machine as an NFS server with 4 nfsd's running... My client machine is a 486DX50 w/16MB and a WD8013EPC ISA ethernet. I'm configuring this machine as the NFS client with 4 nfsiod's running... Both are running 2.1.5R. After copying a few files from server to client, the transfer freezes, and the server (laptop) starts displaying this error message, approx. once every 30 seconds: server /kernel: nfsd send error 55 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 rebuilt the server's kernel with more mbuf's, thinking this might solve it: options "NMBCLUSTERS=2048" but get the same problem... and the client must be rebooted each time. The server can be restored to "sanity" by killing all nfsd's and down-ing, then up-ing the interface (zp0). But to play it safe, both client and server were rebooted - same problem. server# netstat -m 155 mbufs in use: 115 mbufs allocated to data 34 mbufs allocated to packet headers 4 mbufs allocated to protocol control blocks 2 mbufs allocated to socket names and addresses 34/34 mbuf clusters in use 87 Kbytes allocated to network (100% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines It doesn't look like many clusters are allocated at all... Does anyone know what might be causing this? Any suggestions? - Mike From owner-freebsd-hackers Fri Nov 8 12:46:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07307 for hackers-outgoing; Fri, 8 Nov 1996 12:46:44 -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 MAA07300 for ; Fri, 8 Nov 1996 12:46:38 -0800 (PST) Received: from localhost (mark@localhost) by vinyl.quickweb.com (8.7.5/8.6.12) with SMTP id PAA05899; Fri, 8 Nov 1996 15:43:17 -0500 (EST) Date: Fri, 8 Nov 1996 15:43:17 -0500 (EST) From: Mark Mayo To: Sean Willson cc: hackers@freebsd.org Subject: Re: JDK 1.0.2 on FreeBSD In-Reply-To: <9611081547.AA08574@handset.laa.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, 8 Nov 1996, Sean Willson wrote: > > Hello, > > I am looking for the Java JDK 1.0.2 on FreeBSD. Can anyone tell me where > to find it or where I can obtain more information on it? I would greatly > appreciate it. Thanks.... 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. 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. :-( 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). Hopefully, the JDK 1.1 release in '97 will clear up a lot of the general compaintes about the shittyness of AWT in 1.0.2, and then we can focus on getting a good java interpreter into FreeBSD. cya, -Mark ------------------------------------------------ | Mark Mayo mark@quickweb.com | | RingZero Comp. www.quickweb.com | ------------------------------------------------ "To iterate is human, to recurse divine." - L. Peter Deutsch > > Sean Willson > > --- > Sean M. Willson. Lynn-Arthur Associates, Inc. +1 313 995 5590 > willson@laa.com Operations Support Systems +1 313 995 5989 (fax) > 2350 Green Road Suite 160 Ann Arbor, MI, 48105 USA From owner-freebsd-hackers Fri Nov 8 13:13:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA09050 for hackers-outgoing; Fri, 8 Nov 1996 13:13:25 -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 NAA09040 for ; Fri, 8 Nov 1996 13:13:21 -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 PAA25961; Fri, 8 Nov 1996 15:12:32 -0600 (CST) Received: by bio-5.bsd.uchicago.edu (5.0/SMI-SVR4) id AA11234; Fri, 8 Nov 1996 15:12:25 +0600 Date: Fri, 8 Nov 1996 15:12:25 +0600 Message-Id: <9611082112.AA11234@bio-5.bsd.uchicago.edu> To: bde@zeta.org.au Cc: hackers@FreeBSD.org In-Reply-To: <199611081551.CAA08229@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 9 Nov 1996 02:51:00 +1100) Subject: Re: TIOCSPGRP on ptys? From: Tim Pierce Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans said: > [I wrote:] > > >In fact, the source for kern/tty_pty.c seems to > >be written to prevent *any* ioctls from being performed on slave > >ptys, and to prevent most TIOC ioctls from being performed on > >master ptys. Clearly I spoke too rashly. I did not notice that ptyioctl() calls ttioctl() for any unhandled ioctls -- only that it calls the line discipline ioctl after checking special cases first. My bad. > In BSD4.4Lite, there is essentially only > one working method: > > 1. Stop being a process group leader, e.g., by forking and continuing > in the child. This is necessary for step 2 to work. See setsid(2). > 2. Open the new tty. > 3. Call setsid() to become a session leader. > 4. Call ioctl(fd, TIOCSCTTY) to get a controlling terminal. > 5. Call tcsetpgrp(fd, groupid) or an ioctl to set the process group. > > login_tty() does steps (3) and (4) plus some simple plumbing. It is > documented in lgin_tty.c :-). These interfaces have been stable for > 4+ years. Thanks for the elucidation. I was not sure whether login_tty() is the preferred mechanism because I could find no documentation for it and did not know how long it has been a part of 4BSD. Should a man3 page be included for it? (I could contribute one if it is agreed that this is a good idea.) From owner-freebsd-hackers Fri Nov 8 13:20:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA09589 for hackers-outgoing; Fri, 8 Nov 1996 13:20:16 -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 NAA09577 for ; Fri, 8 Nov 1996 13:20:11 -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 MAA01673; Fri, 8 Nov 1996 12:52:01 -0800 (PST) Message-ID: <32839D5F.794BDF32@whistle.com> Date: Fri, 08 Nov 1996 12:51:43 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Chris Csanady CC: hackers@freebsd.org Subject: Re: Write-back boot blocks? Why not... References: <199611081241.GAA00324@friley216.res.iastate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Csanady wrote: > > I recently came upon an IDE drive, so I have been poking around at > things to get it to boot off my scsi. I must say, Im sure there are > plenty of new, users that get fairly disgusted trying to this to work. :( > > Anyway, does the NAMEBLOCK_WRITEBACK feature of biosboot work? (documented > in /sys/i386/boot/biosboot/Makefile) I noticed it was commented out. I > think it would be a really nice feature for 2.2 if it worked. If not, perhaps > the BOOT_HD_BIAS variable should be mentioned in the handbook or somewhere > else obvious. :) > > Just thought I'd bring it to everyones attention.. WE (whistle Communications) use the NAMEBLOCK_WRITEBACK feature in our product. it allows us to make a turn-key box that can boot to an alternate root partition if the first one has screwed up.... (actually that's why we wrote it ) the version in -current is not quite correct. you need to check out boot.c with tag JULIAN_HACK to get the version that works corrently. julian (E) From owner-freebsd-hackers Fri Nov 8 13:25:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA09999 for hackers-outgoing; Fri, 8 Nov 1996 13:25:29 -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 NAA09991 for ; Fri, 8 Nov 1996 13:25:26 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id NAA21633 for ; Fri, 8 Nov 1996 13:25:18 -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 WAA25766; Fri, 8 Nov 1996 22:21:19 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA15180; Fri, 8 Nov 1996 22:21:19 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id WAA06895; Fri, 8 Nov 1996 22:19:36 +0100 (MET) From: J Wunsch Message-Id: <199611082119.WAA06895@uriah.heep.sax.de> Subject: Re: changing default sysctl values in kernel... To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 22:19:36 +0100 (MET) Cc: gurney_j@resnet.uoregon.edu, dnelson@emsphone.com (Dan Nelson) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611071534.JAA18370@dan.emsphone.com> from Dan Nelson at "Nov 7, 96 09:34:32 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 Dan Nelson wrote: > You don't want to search for GATEWAY; search for where the sysctl > "forwarding" is linked to a kernel variable. From /sys/netinet/ip_input.c: > > static int ipforwarding = 0; > SYSCTL_INT(_net_inet_ip, IPCTL_FORWARDING, forwarding, CTLFLAG_RW, > &ipforwarding, 0, ""); > > Just set ipforwarding to 1 there, and you should be set. NOOO! Use the variable ``gateway'' in /etc/sysconfig, don't mess with the kernel's static variables for 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 Fri Nov 8 13:33:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10434 for hackers-outgoing; Fri, 8 Nov 1996 13:33:13 -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 NAA10426 for ; Fri, 8 Nov 1996 13:33:11 -0800 (PST) Received: (from freebsd@localhost) by dyslexic.phoenix.net (8.7.5/8.7.3) id PAA04542; Fri, 8 Nov 1996 15:33:08 -0600 (CST) Date: Fri, 8 Nov 1996 15:33:08 -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 Can someone tell me why I am getting these errors on my system when I try to run trafshow on my FDDI (fpa0) device: *** virtual2# trafshow -ifpa0 trafshow: unknown data link type 0xa *** Thanks..is this fixed? Geoff From owner-freebsd-hackers Fri Nov 8 13:52:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11679 for hackers-outgoing; Fri, 8 Nov 1996 13:52:10 -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 NAA11598 for ; Fri, 8 Nov 1996 13:51:43 -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 WAA26470; Fri, 8 Nov 1996 22:51:28 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA15746; Fri, 8 Nov 1996 22:51:28 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id WAA07596; Fri, 8 Nov 1996 22:50:36 +0100 (MET) From: J Wunsch Message-Id: <199611082150.WAA07596@uriah.heep.sax.de> Subject: Re: Philips CDD2000 CD-R works as HP-4020i To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 22:50:36 +0100 (MET) Cc: luigi@labinfo.iet.unipi.it Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611081611.LAA11686@oscar.cc.gatech.edu> from Carlos Ugarte at "Nov 8, 96 11:11:08 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 Carlos Ugarte wrote: > Most likely, I think, is that it the CDD2000 will not test with a > CD-ROM in there (you may need a blank CD-R). You are absolutely right in that. The CD-R drive recognizes a fixated CD-R medium as a CD-ROM only, and simply refuses to even burn in dummy mode. -- 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 Fri Nov 8 13:55:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11859 for hackers-outgoing; Fri, 8 Nov 1996 13:55:04 -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 NAA11839 for ; Fri, 8 Nov 1996 13:54:57 -0800 (PST) Received: (from mail@localhost) by bacall.lodgenet.com (8.6.12/8.6.12) id PAA08910; Fri, 8 Nov 1996 15:54:02 -0600 Received: from garbo.lodgenet.com(204.124.123.250) by bacall via smap (V1.3) id sma008906; Fri Nov 8 15:54:01 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 PAA22713; Fri, 8 Nov 1996 15:54:13 -0600 Received: from jake.lodgenet.com (localhost [127.0.0.1]) by jake.lodgenet.com (8.7.6/8.6.12) with ESMTP id PAA00388; Fri, 8 Nov 1996 15:54:31 -0600 (CST) Message-Id: <199611082154.PAA00388@jake.lodgenet.com> X-Mailer: exmh version 1.6.9 8/22/96 To: amir@comtrol.com (Amir Farah) cc: hackers@freebsd.org Subject: Re: timeout() function In-reply-to: Your message of "Fri, 08 Nov 1996 09:41:05 CST." <199611081541.JAA00123@rocket.comtrol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 15:54:31 -0600 From: "Eric L. Hernes" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Amir Farah writes: >Hello > >I have a question about the timeout() function in /sys/kern/kern_clock.c file. > >You can execute a function after a specified length of time using >timeout(ftn, arg, ticks) > >ftn: function to be called >args: arguments for the function >ticks: delay > >If I pass "1" for the delay, does it mean the function will get called every >1 second?? I want to be able to call a funtion every 50 milisecond (or less). > ticks are 1/100 sec, so with a timeout of 1, your function will be called 100 times a second. If you want faster, you can hook into a clock interrupt, see the pcaudio driver for an example. Drivers that don't use interrupts can use these `callouts' for pseudo-interrupts. > >Thanks > >amir > > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com From owner-freebsd-hackers Fri Nov 8 13:56:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12017 for hackers-outgoing; Fri, 8 Nov 1996 13:56:35 -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 NAA11974 for ; Fri, 8 Nov 1996 13:56:05 -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 WAA26489; Fri, 8 Nov 1996 22:51:54 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA15763; Fri, 8 Nov 1996 22:51:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id WAA07558; Fri, 8 Nov 1996 22:49:36 +0100 (MET) From: J Wunsch Message-Id: <199611082149.WAA07558@uriah.heep.sax.de> Subject: Re: Philips CDD2000 CD-R works as HP-4020i To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 22:49:36 +0100 (MET) Cc: luigi@labinfo.iet.unipi.it, cau@cc.gatech.edu Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <1828.847458543@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 8, 96 05:09:03 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 Jordan K. Hubbard wrote: > > 1) can I use it as a CD reader, by putting in a standard CDROM ? > This is a known problem. The device functions either as a CDROM drive > (if you don't assign it to worm0) or as a worm, but not both. > According to Joerg, this is not trivial to fix and so he hasn't done > it (or maybe it's relatively trivial but he just doesn't have any > time, rendering it non-trivial in a different sense :-). Oh, i didn't say it this way. :-) The code is even already _supposed_ to allow reading the CDs, but it plain simply doesn't do it. Of all the people using a CD-R by now, they all seem to have a working CD-ROM drive anyway, so nobody has been bothered enough by that bug to really look what it is, but everybody just simply preferred swapping the burnt CD-R out into the CD-ROM drive... The only thing that's more difficult to add (without duplicating all the code) is the CD-ROM driver ioctl ``add-ons'' like eject and play support. -- 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 Fri Nov 8 14:01:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA12446 for hackers-outgoing; Fri, 8 Nov 1996 14:01:03 -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 OAA12440 for ; Fri, 8 Nov 1996 14:00:55 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-45.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA27498 (5.67b/IDA-1.5 for ); Fri, 8 Nov 1996 23:00:04 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id WAA04681; Fri, 8 Nov 1996 22:49:56 +0100 (MET) Message-Id: <199611082149.WAA04681@x14.mi.uni-koeln.de> Date: Fri, 8 Nov 1996 22:49:56 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: smp@csn.net (Steve Passe) Cc: hackers@freefall.freebsd.org Subject: Re: motherboard chipset identification In-Reply-To: <199611080640.XAA28148@clem.systemsix.com>; from Steve Passe on Nov 7, 1996 23:40:15 -0700 References: <199611080640.XAA28148@clem.systemsix.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > Hi, > > I need to be able to tell which chipset is being used on a motherboard > during the boot process (Neptune, Triton, Natoma, etc.) Could someone > point me towards the code in the kernel that determines this info??? These are all PCI chip sets, so "pcisupport.c" is your friend :) But I'd rather add some code to intialize some variables accordingly to the PCI code, than have the SMP code decode the PCI chip set ID again. There should be only one place, where PCI chip set specific code has to be maintained, IMHO. Regards, STefan From owner-freebsd-hackers Fri Nov 8 13:58:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12125 for hackers-outgoing; Fri, 8 Nov 1996 13:58:07 -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 NAA12120 for ; Fri, 8 Nov 1996 13:58:04 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id NAA21693 for ; Fri, 8 Nov 1996 13:57:59 -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 WAA26474 for ; Fri, 8 Nov 1996 22:51:30 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA15755 for freebsd-hackers@freebsd.org; Fri, 8 Nov 1996 22:51:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id WAA07348 for freebsd-hackers@freebsd.org; Fri, 8 Nov 1996 22:38:46 +0100 (MET) From: J Wunsch Message-Id: <199611082138.WAA07348@uriah.heep.sax.de> Subject: Re: More info on the daily panics... To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 22:38:46 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611071345.FAA03394@root.com> from David Greenman at "Nov 7, 96 05:45:31 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 David Greenman wrote: > It appears that there > is a bug in the FFS block allocation/free code that is tickled by 4K blocks. > Are any of your filesystems built with a 4K blocksize? Which blocksize is MFS using by default? Remember, i've also got this quite quickly when using an MFS /tmp. -- 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 Fri Nov 8 13:58:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12178 for hackers-outgoing; Fri, 8 Nov 1996 13:58:37 -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 NAA12167 for ; Fri, 8 Nov 1996 13:58:31 -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 WAA26480; Fri, 8 Nov 1996 22:51:41 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA15756; Fri, 8 Nov 1996 22:51:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id WAA07413; Fri, 8 Nov 1996 22:41:52 +0100 (MET) From: J Wunsch Message-Id: <199611082141.WAA07413@uriah.heep.sax.de> Subject: Re: motherboard chipset identification To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 22:41:52 +0100 (MET) Cc: smp@csn.net (Steve Passe) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611080640.XAA28148@clem.systemsix.com> from Steve Passe at "Nov 7, 96 11:40:15 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 Steve Passe wrote: > I need to be able to tell which chipset is being used on a motherboard > during the boot process (Neptune, Triton, Natoma, etc.) Could someone > point me towards the code in the kernel that determines this info??? I think it's in /sys/pci/pcisupport.c. -- 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 Fri Nov 8 14:22:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13944 for hackers-outgoing; Fri, 8 Nov 1996 14:22:50 -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 OAA13918 for ; Fri, 8 Nov 1996 14:22:33 -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 XAA27104; Fri, 8 Nov 1996 23:21:19 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA16364; Fri, 8 Nov 1996 23:21:18 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id XAA07870; Fri, 8 Nov 1996 23:17:01 +0100 (MET) From: J Wunsch Message-Id: <199611082217.XAA07870@uriah.heep.sax.de> Subject: Re: timeout() function To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 23:17:01 +0100 (MET) Cc: amir@comtrol.com (Amir Farah) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611081541.JAA00123@rocket.comtrol.com> from Amir Farah at "Nov 8, 96 09:41:05 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 Amir Farah wrote: > I have a question about the timeout() function in /sys/kern/kern_clock.c file. RTFM timeout(9): NAME timeout, untimeout - schedule timer events SYNOPSIS #include #include typedef void (timeout_t) (void *); typedef timeout_t *timeout_func_t; void timeout(timeout_func_t func, void *arg, int ticks) void untimeout(timeout_func_t func, void *arg) [...] (If you don't have some 2.2 source tree, pick up /usr/src/share/man/man9 from a -current tree.) -- 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 Fri Nov 8 14:23:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14018 for hackers-outgoing; Fri, 8 Nov 1996 14:23:23 -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 OAA13983 for ; Fri, 8 Nov 1996 14:23:09 -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 XAA27117; Fri, 8 Nov 1996 23:21:46 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA16376; Fri, 8 Nov 1996 23:21:42 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id XAA07826; Fri, 8 Nov 1996 23:14:16 +0100 (MET) From: J Wunsch Message-Id: <199611082214.XAA07826@uriah.heep.sax.de> Subject: Re: Strange messages from my 2.1.0 kernel To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 23:14:16 +0100 (MET) Cc: john@starfire.mn.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611081855.MAA04307@starfire.mn.org> from "john@starfire.mn.org" at "Nov 8, 96 12:55:02 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 john@starfire.mn.org wrote: > > > fhtovp: file start miss 1946157056 vs 68 > > > > It might mean you have two nfsnodes pointing to the same vnode... > > Or it might mean someone is trying to NFS hack your system... > > Or it might be an mmap() of an NFS file on an FS with a 4k block > > size and an NFS rzise/wsize of 8K, or vice versa... Or it might be that Terry forgot to use grep(1), so he didn't notice that these messages are from cd9660 f/s... Actually, the cd9660 code is by far too blatant in spitting out kernel printf's whenever it is going to reject a request with a ``stale file handle'' response. > Oh! OK! That makes perfect sense, then. A remote system had had > my CD NFS mounted, but I rebooted, and my CD does not get automatically > booted on mount (I hate to automatically mount removeable media). Why do you hate this? Because someone (IMHO stupidly) made a failure mounting a CD-ROM a fatal error? This can easily be avoided (and i do avoid it). I always disliked this idea. Simply reorganize your /etc/rc so that only mount failures for filesystems that are essential for you will abort the script. Take away the `noauto' for the CD-ROM, and simply try mounting it at boot time. If it's not there, /etc/rc will go on without complaints (except from mountd later about not being able to change the NFS export attributes for /cdrom, but that's benign). -- 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 Fri Nov 8 14:30:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14524 for hackers-outgoing; Fri, 8 Nov 1996 14:30:27 -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 OAA14518 for ; Fri, 8 Nov 1996 14:30:25 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA21733 for ; Fri, 8 Nov 1996 14:23:55 -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 XAA27121; Fri, 8 Nov 1996 23:21:48 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA16379; Fri, 8 Nov 1996 23:21:47 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id XAA07749; Fri, 8 Nov 1996 23:05:04 +0100 (MET) From: J Wunsch Message-Id: <199611082205.XAA07749@uriah.heep.sax.de> Subject: Re: Q: How to read hardware port ? To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Fri, 8 Nov 1996 23:05:04 +0100 (MET) Cc: ts@polynet.lviv.ua Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611081449.PAA00718@ra.dkuug.dk> from "sos@freebsd.org" at "Nov 8, 96 03:49:34 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 sos@freebsd.org wrote: > > How can i read hardware port in Unix ? > Open /dev/io and use the inb/outb etc functions, you must be > root though for this to work (with good reason). Better yet, write a device driver doing the actual hardware work. ;-) -- 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 Fri Nov 8 14:40:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15151 for hackers-outgoing; Fri, 8 Nov 1996 14:40:20 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA15140 for ; Fri, 8 Nov 1996 14:40:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA02599; Fri, 8 Nov 1996 15:40:08 -0700 Message-Id: <199611082240.PAA02599@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-hackers@freebsd.org (FreeBSD hackers) cc: Chuck Robey , joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: motherboard chipset identification In-reply-to: Your message of "Fri, 08 Nov 1996 22:41:52 +0100." <199611082141.WAA07413@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 15:40:08 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I need to be able to tell which chipset is being used on a motherboard > during the boot process (Neptune, Triton, Natoma, etc.) Could someone > point me towards the code in the kernel that determines this info??? Several people have pointed out sys/pci/pcisupport.c. This is a starting point, but the chips of interest to me are non-PCI things, like system controller chips (combo chips that are typically part of the MB "chip-set" and contain the timers, icus, etc.) The IO APIC is sometimes contained in these, and comes in different flavors that need slightly different programming techniques. My specific problem is that you need (so the manuals claim) to access the IOSELREG via byte writes on some flavors, but DWORD writes on others. so its a catch-22 situation, I need to know which flavor it is before I can access it, but I can't safely probe it for clues, cause I don't know which flavor it is. (thank you very much, #$&^*&# Intel) The closest I will come is by knowing what types of other system chips are used, then deducing which IO APIC is most likely to be present from that. The MP spec defines boards without PCI busses, so I need a more general mechanism. Note that it might not be quite this problematic, all I know right now is we have flavors that aren't working, and this appears to be a likely reason. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Fri Nov 8 14:53:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15671 for hackers-outgoing; Fri, 8 Nov 1996 14:53:27 -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 OAA15634 for ; Fri, 8 Nov 1996 14:52:36 -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 XAA27892; Fri, 8 Nov 1996 23:51:44 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA16991; Fri, 8 Nov 1996 23:51:44 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id XAA08251; Fri, 8 Nov 1996 23:50:35 +0100 (MET) From: J Wunsch Message-Id: <199611082250.XAA08251@uriah.heep.sax.de> Subject: Re: FreeBSD Development To: iain@flash.net (J. A. Sigler) Date: Fri, 8 Nov 1996 23:50:35 +0100 (MET) Cc: freebsd-hackers@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32824DA3.167EB0E7@flash.net> from "J. A. Sigler" at "Nov 7, 96 08:59:15 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 J. A. Sigler wrote: > I am greatly interested in FreeBSD development. I am not able to > contribute at this time, as I just recently switched to running BSD on > my desktop workstation. I would like to be on any applicable mailing > lists. Ask majordomo@freebsd.org with a mail just saying `lists'. -- 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 Fri Nov 8 15:03:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA16405 for hackers-outgoing; Fri, 8 Nov 1996 15:03:34 -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 PAA16379 for ; Fri, 8 Nov 1996 15:03:21 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-47.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA28484 (5.67b/IDA-1.5 for ); Sat, 9 Nov 1996 00:03:03 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id AAA05902; Sat, 9 Nov 1996 00:03:03 +0100 (MET) Message-Id: <199611082303.AAA05902@x14.mi.uni-koeln.de> Date: Sat, 9 Nov 1996 00:03:02 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: smp@csn.net (Steve Passe) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers), chuckr@glue.umd.edu (Chuck Robey), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: motherboard chipset identification In-Reply-To: <199611082240.PAA02599@clem.systemsix.com>; from Steve Passe on Nov 8, 1996 15:40:08 -0700 References: <199611082240.PAA02599@clem.systemsix.com> X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > Hi, > > > I need to be able to tell which chipset is being used on a motherboard > > during the boot process (Neptune, Triton, Natoma, etc.) Could someone > > point me towards the code in the kernel that determines this info??? > > Several people have pointed out sys/pci/pcisupport.c. This is a starting > point, but the chips of interest to me are non-PCI things, like system > controller chips (combo chips that are typically part of the MB "chip-set" > and contain the timers, icus, etc.) The IO APIC is sometimes contained Hmmm, but did you take a look at "pcisupport.c" ? Check out the code that dumps the support chip registers if "bootverbose" is true ... > in these, and comes in different flavors that need slightly different > programming techniques. My specific problem is that you need (so the manuals > claim) to access the IOSELREG via byte writes on some flavors, but DWORD writes > on others. so its a catch-22 situation, I need to know which flavor it is > before I can access it, but I can't safely probe it for clues, cause I don't > know which flavor it is. (thank you very much, #$&^*&# Intel) What does it depend on ? Why can't you probe for it ? (Does a probe lock up the system if the wrong flavor is assumed ?) > The closest I will come is by knowing what types of other system chips > are used, then deducing which IO APIC is most likely to be present from that. > The MP spec defines boards without PCI busses, so I need a more general > mechanism. > > Note that it might not be quite this problematic, all I know right now is we > have flavors that aren't working, and this appears to be a likely reason. Regards, STefan From owner-freebsd-hackers Fri Nov 8 15:12:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA17100 for hackers-outgoing; Fri, 8 Nov 1996 15:12: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 PAA17094 for ; Fri, 8 Nov 1996 15:12:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA12772; Fri, 8 Nov 1996 16:02:43 -0700 From: Terry Lambert Message-Id: <199611082302.QAA12772@phaeton.artisoft.com> Subject: Re: Strange messages from my 2.1.0 kernel To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 8 Nov 1996 16:02:43 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org, john@starfire.mn.org In-Reply-To: <199611082214.XAA07826@uriah.heep.sax.de> from "J Wunsch" at Nov 8, 96 11:14:16 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 > > > > fhtovp: file start miss 1946157056 vs 68 > > > > > > It might mean you have two nfsnodes pointing to the same vnode... > > > Or it might mean someone is trying to NFS hack your system... > > > Or it might be an mmap() of an NFS file on an FS with a 4k block > > > size and an NFS rzise/wsize of 8K, or vice versa... > > Or it might be that Terry forgot to use grep(1), so he didn't notice > that these messages are from cd9660 f/s... Actually, the cd9660 code > is by far too blatant in spitting out kernel printf's whenever it is > going to reject a request with a ``stale file handle'' response. Or it might be that the NFS VFS consumer is broken and the vfs_syscalls.c VFS consumer isn't broken, and the two operate differently because the code which should be shared isn't. And it may be that a broken VFS consumer is the only thing that can trigger that. And it may be that Terry knew that already... 8-). > > Oh! OK! That makes perfect sense, then. A remote system had had > > my CD NFS mounted, but I rebooted, and my CD does not get automatically > > booted on mount (I hate to automatically mount removeable media). > > Why do you hate this? Because someone (IMHO stupidly) made a failure > mounting a CD-ROM a fatal error? This can easily be avoided (and i do > avoid it). I always disliked this idea. > > Simply reorganize your /etc/rc so that only mount failures for > filesystems that are essential for you will abort the script. Take > away the `noauto' for the CD-ROM, and simply try mounting it at boot > time. If it's not there, /etc/rc will go on without complaints > (except from mountd later about not being able to change the NFS > export attributes for /cdrom, but that's benign). Or maybe he hates it because NFS should export a directory vnode and all inferior nodes of the same dev_t value, and the NFS exports processing doesn't belong in each FS's mount code (which is what makes you mount the thing before you can export it). And maybe if the cdrom is there, it should be mounted on a directory that the user has mapped for the label, and not mounted if it's not, and never affect NFS at all... like the transient resource it is. And maybe the namei() code should always use a relative root instead of only conditionally using one, so that if the the isn't mounted, I don't have to conditionally not export the mount point so that I don't open a nice security hole for valid NFS users to use fraudulent file handles to escape further up in the directory tree on the device (which since it isn't a mounted CDROM, is the node on the FS that the CDROM would have covered had it been successfully mounted). And then the NFS daemon can set the relative root prior to VOP_LOOKUP so that it's no longer a problem. So maybe it's a security issue which doesn't change even if the removable media didn't fatally fail the boot on a failure to mount. You think? 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 8 15:21:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA17774 for hackers-outgoing; Fri, 8 Nov 1996 15:21:31 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA17762 for ; Fri, 8 Nov 1996 15:21:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA02908; Fri, 8 Nov 1996 16:21:10 -0700 Message-Id: <199611082321.QAA02908@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: se@zpr.uni-koeln.de (Stefan Esser) cc: freebsd-hackers@freebsd.org (FreeBSD hackers), chuckr@glue.umd.edu (Chuck Robey), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: motherboard chipset identification In-reply-to: Your message of "Sat, 09 Nov 1996 00:03:02 +0100." <199611082303.AAA05902@x14.mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 16:21:09 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, >What does it depend on ? > >Why can't you probe for it ? >(Does a probe lock up the system if the wrong flavor is assumed ?) In general they use a register indirection scheme, write the index to IOREGSEL, then read/write the data from/to IODATA. several flavors want you to do a BYTE write to IOREGSEL, while others specify a DWORD (ie long) write to IOREGSEL. The system doesn't lock up, but the IO APIC of the DWORD flavor type doesn't work for us either. Right now the board's owner is helping me sort it all out, but in the long run I would like a more elegant solution than "poke it and see if it pukes". It would be nice to know which flavor it is b4 the first access. My experience with hardware says that even if I find that a particular piece of silicon can be probed "incorrectly" to determine what it can do without perturbing it, another instance of the same part made in the past or the future might not be so forgiving.... That's one of the things that makes this kind of work so fun! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-hackers Fri Nov 8 15:44:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA19296 for hackers-outgoing; Fri, 8 Nov 1996 15:44:35 -0800 (PST) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA19181 for ; Fri, 8 Nov 1996 15:43:53 -0800 (PST) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.6.11/8.6.12) with ESMTP id RAA13386 for ; Fri, 8 Nov 1996 17:43:46 -0600 Received: from localhost by solaria.sol.net (8.5/8.5) id RAA26424; Fri, 8 Nov 1996 17:43:44 -0600 From: Joe Greco Message-Id: <199611082343.RAA26424@solaria.sol.net> Subject: 2.2-961014-SNAP de0 "bad crc" errors To: hackers@freebsd.org Date: Fri, 8 Nov 96 17:43:42 CST X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am in the middle of installing 2.2-961014-SNAP, cvsup, etc., in order to build a box on which to test the 2.2R release candidate code. I am getting Nov 8 23:17:33 newnews /kernel: de0: receive: 00:60:3e:7e:ee:80: bad crc Nov 8 23:17:33 newnews /kernel: de0: receive: 00:60:3e:7e:ee:80: bad crc every few minutes. The host address is that of the Cisco 75XX router here, which makes sense because I am running cvsup right now and receiving data. It does not seem to be hurting anything. The board is an ASUS P/I-P55TP4XE, from rgrimes which had been out of service for a few months. The card, an SMC EtherPower 10/100 which was pulled out of a perfectly functioning 2.1.5R box. I have another SMC card here but do not want to interrupt the wonderful 3K of data per second I am getting (DS3 connectivity is great)... I will play switchoo hardware later this weekend. If this is of some particular interest to anyone, please drop me a line. If it is not, I'll see what happens after a make world and/or hardware switch. I must confess I have not been reading the bug reports for 2.2-961014-SNAP... but I thought I would report it in case anyone was interested. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Fri Nov 8 22:43:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA10701 for hackers-outgoing; Fri, 8 Nov 1996 22:43:46 -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 WAA10696 for ; Fri, 8 Nov 1996 22:43: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 WAA01309 for ; Fri, 8 Nov 1996 22:43:43 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id RAA23191 for freebsd-hackers@freebsd.org; Sat, 9 Nov 1996 17:43:35 +1100 Date: Sat, 9 Nov 1996 17:43:35 +1100 From: Julian Assange Message-Id: <199611090643.RAA23191@suburbia.net> To: freebsd-hackers@freebsd.org Subject: virtual hosting with inetd 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? From owner-freebsd-hackers Fri Nov 8 23:27:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA12161 for hackers-outgoing; Fri, 8 Nov 1996 23:27:18 -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 XAA12154 for ; Fri, 8 Nov 1996 23:27:12 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id SAA00055; Sat, 9 Nov 1996 18:22:36 +1100 Date: Sat, 9 Nov 1996 18:22:36 +1100 From: Bruce Evans Message-Id: <199611090722.SAA00055@godzilla.zeta.org.au> To: amir@comtrol.com, erich@lodgenet.com Subject: Re: timeout() function Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >ticks are 1/100 sec, so with a timeout of 1, your function will be Ticks are 1/hz second. hz just happens to be 100 in standard configurations. Drivers should not assume this. See timeout(9). Bruce From owner-freebsd-hackers Sat Nov 9 00:46:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA15065 for hackers-outgoing; Sat, 9 Nov 1996 00:46:28 -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 AAA15055 for ; Sat, 9 Nov 1996 00:46:23 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id TAA01955; Sat, 9 Nov 1996 19:45:05 +1100 Date: Sat, 9 Nov 1996 19:45:05 +1100 From: Bruce Evans Message-Id: <199611090845.TAA01955@godzilla.zeta.org.au> To: bde@zeta.org.au, twpierce@bio-3.bsd.uchicago.edu Subject: Re: TIOCSPGRP on ptys? Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Thanks for the elucidation. I was not sure whether login_tty() is >the preferred mechanism because I could find no documentation for >it and did not know how long it has been a part of 4BSD. Should a >man3 page be included for it? (I could contribute one if it is >agreed that this is a good idea.) Yes, everything in the library should have a man page. NetBSD has man pages for everything in libutil. Someone should import them. Bruce From owner-freebsd-hackers Sat Nov 9 02:20:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA18107 for hackers-outgoing; Sat, 9 Nov 1996 02:20:56 -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 CAA18102 for ; Sat, 9 Nov 1996 02:20:53 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id LAA29870; Sat, 9 Nov 1996 11:00:50 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.2/8.8.2) with SMTP id JAA27222; Sat, 9 Nov 1996 09:57:12 +0100 (MET) Date: Sat, 9 Nov 1996 09:57:12 +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: <199611081440.GAA06649@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 Fri, 8 Nov 1996, Justin T. Gibbs wrote: > >Please, I'll be very glad if someone help me. > > You didn't have to ask the entire world! One list would have been enough. > > Upgrade to a more recent version of FreeBSD and your problems will probably > go away. The ahc driver in 2.1R was not that great. 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. -- 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 Sat Nov 9 06:49:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA01981 for hackers-outgoing; Sat, 9 Nov 1996 06:49:16 -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 GAA01973 for ; Sat, 9 Nov 1996 06:49:13 -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 GAA07318; Sat, 9 Nov 1996 06:49:00 -0800 (PST) Received: (sendmail@localhost) by suburbia.net (8.7.4/Proff-950810) id BAA16030; Sun, 10 Nov 1996 01:48:42 +1100 Received: from profane.suburbia.net(203.4.184.222), claiming to be "profane.iq.org" via SMTP by suburbia.net, id smtpd16027aaa; Sun Nov 10 01:48:35 1996 Received: (from smtpd@localhost) by profane.iq.org (8.8.2/8.8.2) id BAA12293; Sun, 10 Nov 1996 01:48:40 +1100 (EST) Message-Id: <199611091448.BAA12293@profane.iq.org> Received: from localhost(127.0.0.1), claiming to be "profane.iq.org" via SMTP by localhost, id smtpd012289; Sat Nov 9 14:47:34 1996 To: Darren Reed cc: hackers@freebsd.org Subject: Re: patches for nice text modes (170x48x16 etc) (syscons.c) In-reply-to: Your message of "Sat, 09 Nov 1996 18:39:22 +1100." <199611090923.UAA12140@profane.iq.org> Date: Sun, 10 Nov 1996 01:47:34 +1100 From: Julian Assange Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So how would I use that patch ? Apply the syscons patch to to syscons.c (against 2.2-current, but even if it doesn't patch cleanly against earlier code, changes needed to patch cleanly should only be cosmetic). Rebuild. Apply the SVGATextMode text mode patches to SVGATextMode-1.4 (see my original message for the url). Compile. Configuration is the same as with XFree in terms of setting up mode-lines - just read the SVGATextMode docs, there is plenty of really good material there, and you should have a working TextConfig file with less hair pulling than X. Sync pules are ULF and they re-radiate very poorly. Creating a cron which changes mode-lines randomly every half hour or so is a good way to frustrate all but the most sophsticated automated van eck monitors. Manned units are a different story, but your opponent has to invest in lots of personel time. Since I'm on this issue anyway, you can also choose your colour palette so equal absolute voltage intensities are used on each R,G,B line (check by cable merging - sometimes the there are voltage biases in the colour seperation/generation hardware). Not a substitute for the old aluminium wall paper and a big fat grounding stake, but it does increase the cost and required fidelity of the van eck monitor. If you have already set up X, then you can in many circumstances use the X modelines under text mode. This can be pretty neat if your graphics card can pull the character data fast enough (ET4000's always can. Other cards have lower max dot clocks for text modes than graphics modes. My S3-trio-64 can do around 87Mhz) as you can swap back and forth between text mode and X-mode without any delay for monitor re-syncing. -Julian From owner-freebsd-hackers Sat Nov 9 07:27:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA03681 for hackers-outgoing; Sat, 9 Nov 1996 07:27:13 -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 HAA03672 for ; Sat, 9 Nov 1996 07:27:10 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id KAA05400 for ; Sat, 9 Nov 1996 10:27:54 -0500 (EST) Date: Sat, 9 Nov 1996 10:27:53 -0500 (EST) From: "Marc G. Fournier" To: hackers@freebsd.org Subject: MMAP: how to use... 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... Can anyone direct me to either an online source, or a good book, on MMAP? Thanks... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Sat Nov 9 07:38:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA04696 for hackers-outgoing; Sat, 9 Nov 1996 07:38:14 -0800 (PST) Received: from sunland.gsfc.nasa.gov (sunland.gsfc.nasa.gov [128.183.22.16]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA04691 for ; Sat, 9 Nov 1996 07:38:12 -0800 (PST) Received: from sunbaked.gsfc743 by sunland.gsfc.nasa.gov (8.6.8/1.35) id KAA11010; Sat, 9 Nov 1996 10:37:41 -0500 Received: by sunbaked.gsfc743 (SMI-8.6/SMI-SVR4) id KAA12027; Sat, 9 Nov 1996 10:38:14 -0500 Date: Sat, 9 Nov 1996 10:38:14 -0500 Message-Id: <199611091538.KAA12027@sunbaked.gsfc743> From: Tim Singletary To: freebsd-hackers@freebsd.org Subject: vx driver and 3c900 ??? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've got one of these EtherLink XL 3C900 ethernet adapters, I'm running the 961014 snapshot, I've hacked the vx driver that came with the snapshot so it recognizes the 3C900 card, and I've reached the point where I can ping, telnet etc. Now for my problem: If I attempt to `get' a large file using ftp, nothing transfers -- the connection just seems to hang! But I can still ping and so on from other windows! I simply haven't been able to ftp a binary file! I assume the 961014 snapshot's vx driver is somewhat buggy, and I thought I saw some messages recently about someone working on a replacement driver. Is that at a point where I can try it out? I'd love to help alpha or beta test the thing! Can anyone help me out??? tim From owner-freebsd-hackers Sat Nov 9 08:16:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA06085 for hackers-outgoing; Sat, 9 Nov 1996 08:16:00 -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 IAA06073 for ; Sat, 9 Nov 1996 08:15:41 -0800 (PST) Received: (from smap@localhost) by Guard.PolyNet.Lviv.UA (8.6.12/8.6.12) id SAA21466 for ; Sat, 9 Nov 1996 18:15:23 +0200 Received: from netsurfer.lp.lviv.ua(192.168.0.3) by Guard.PolyNet.Lviv.UA via smap (V2.0beta) id xma021464; Sat, 9 Nov 96 18:15:14 +0200 Received: (from smap@localhost) by NetSurfer.lp.lviv.ua (8.6.12/8.6.12) id SAA07885 for ; Sat, 9 Nov 1996 18:15:12 +0200 Message-Id: <199611091615.SAA07885@NetSurfer.lp.lviv.ua> Received: from ws2.lp.lviv.ua(192.168.0.33) by NetSurfer.lp.lviv.ua via smap (V2.0beta) id xma007879; Sat, 9 Nov 96 18:15:01 +0200 Comments: Authenticated sender is From: "Adrian Pavlykevych" To: hackers@freebsd.org Date: Sat, 9 Nov 1996 18:15:50 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Bootstrap doesn't recognize keyboardless config Reply-to: pam@polynet.lviv.ua Priority: normal X-mailer: Pegasus Mail for Windows (v2.42a) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi everybody, I have stuck trying to setup headless (w/o keyboard, monitor) server. I can force kernel and boot to use serial console via COMCONSOLE and FORCE_COMCOMSOLE compile options, but README.serial in /usr/src/sys/i386/boot/biosboot states that default behaviour of bootstrap code is as follows: if it detects keyboard it starts with video console, if no it switches to serial console. I can't get it to work this way. It seems that bootstrap doesn't detect that keyboard is absent. Can somebody give some sound advices? Adrian Pavlykevych | State University "Lvivska Polytechnica" System Administrator | 12, St. Bandery str, Campus Computer Network | Lviv, 290646 email: pam@polynet.lviv.ua | Ukraine tel/fax:+380 (322) 742041 | From owner-freebsd-hackers Sat Nov 9 09:21:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA09949 for hackers-outgoing; Sat, 9 Nov 1996 09:21:59 -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 JAA09941 for ; Sat, 9 Nov 1996 09:21: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 SAA20968; Sat, 9 Nov 1996 18:21:10 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA09535; Sat, 9 Nov 1996 18:21:09 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id SAA02880; Sat, 9 Nov 1996 18:01:58 +0100 (MET) From: J Wunsch Message-Id: <199611091701.SAA02880@uriah.heep.sax.de> Subject: Re: Bootstrap doesn't recognize keyboardless config To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 9 Nov 1996 18:01:58 +0100 (MET) Cc: pam@polynet.lviv.ua Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199611091615.SAA07885@NetSurfer.lp.lviv.ua> from Adrian Pavlykevych at "Nov 9, 96 06:15:50 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 Adrian Pavlykevych wrote: > ..., but README.serial in > /usr/src/sys/i386/boot/biosboot states that default behaviour of > bootstrap code is as follows: if it detects keyboard it starts with > video console, if no it switches to serial console. I can't get it > to work this way. > It seems that bootstrap doesn't detect that keyboard is absent. README.serial is wrong... this feature has been disabled since we didn't find a way to realiably probe for the existance of a keyboard. It broke too many setups by reverting to a serial console where a keyboard was actually present. D*mn PC hardware! -- 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 9 09:36:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA10656 for hackers-outgoing; Sat, 9 Nov 1996 09:36: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 JAA10651; Sat, 9 Nov 1996 09:36:14 -0800 (PST) Message-Id: <199611091736.JAA10651@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 "Sat, 09 Nov 1996 09:57:12 +0100." Date: Sat, 09 Nov 1996 09:36:14 -0800 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >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? >-- >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 Sat Nov 9 11:00:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA14187 for hackers-outgoing; Sat, 9 Nov 1996 11:00:02 -0800 (PST) Received: from gvr.win.tue.nl (gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA14107 for ; Sat, 9 Nov 1996 10:59:24 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id TAA00333; Sat, 9 Nov 1996 19:58:32 +0100 (MET) From: Guido van Rooij Message-Id: <199611091858.TAA00333@gvr.win.tue.nl> Subject: Re: frefall connectivity from europe In-Reply-To: <199611050542.VAA28065@root.com> from David Greenman at "Nov 4, 96 09:42:43 pm" To: dg@root.com Date: Sat, 9 Nov 1996 19:58:32 +0100 (MET) Cc: roberto@keltia.freenix.fr, 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 > In this case the problem is actually mostly due to problems with the > Stratacom ATM switch at the PB-NAP "losing sync" with CRL's ATM interface. > This coupled with another problem that started happening when the Cisco IOS > was upgraded in one or more of CRL's routers has caused route instability > and packet lossage. I'm told that this should be resolved later tonight > with an IOS patch, and more permanently in the next few days. > If all this weren't enough, we're having problems with the WC T1 being > overloaded due to congestion, losing packets because of input CRC errors, > and occasionally losing carrier on the CSU/DSU. I'm on it... That indeed matches with what I'm seeing: lots of packet loss in general and a complete black hole once every couple of minutes for some seconds. -Guido From owner-freebsd-hackers Sat Nov 9 11:06:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA14482 for hackers-outgoing; Sat, 9 Nov 1996 11:06:12 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA14438 for ; Sat, 9 Nov 1996 11:05:06 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id UAA00348; Sat, 9 Nov 1996 20:03:26 +0100 (MET) From: Guido van Rooij Message-Id: <199611091903.UAA00348@gvr.win.tue.nl> Subject: Re: Inetd mod.. comments? In-Reply-To: from Tom Samplonius at "Nov 6, 96 08:29:31 pm" To: tom@sdf.com (Tom Samplonius) Date: Sat, 9 Nov 1996 20:03:26 +0100 (MET) Cc: julian@whistle.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 Tom Samplonius wrote: > > On Wed, 6 Nov 1996, Julian Elischer wrote: > > > I have some patches to Inetd her that I sent out for comment. > > the only comment I got was > > "Gee that's neat!, I need that" > > > > but no technical reviews or code checks.. > > xinetd has done this for long time already. Why not use that? I still like to see Julian's patch. The reason is that I don't really trust xinetd. It is too big. -Guido From owner-freebsd-hackers Sat Nov 9 11:13:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA14828 for hackers-outgoing; Sat, 9 Nov 1996 11:13:45 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA14820 for ; Sat, 9 Nov 1996 11:13:35 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id UAA00386; Sat, 9 Nov 1996 20:12:48 +0100 (MET) From: Guido van Rooij Message-Id: <199611091912.UAA00386@gvr.win.tue.nl> Subject: Re: Philips CDD2000 CD-R works as HP-4020i In-Reply-To: <199611040717.CAA04756@oscar.cc.gatech.edu> from Carlos Ugarte at "Nov 4, 96 02:17:52 am" To: cau@cc.gatech.edu (Carlos Ugarte) Date: Sat, 9 Nov 1996 20:12:48 +0100 (MET) Cc: 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 Carlos Ugarte wrote: > > About a week ago I posted a message to questions but received no > response. My problem is solved though, and I thought someone might > want to know that the Philips CDD2000 CD-Recorder works under > FreeBSD 2.2-961014-SNAP with very minor modifications. Maybe > someone could make these changes to the tree and add the CD-R to > the list of working CD-R's. > > The only modifications required were to scsiconf.c and worm.c - > adding the vendor ID ("IMS") and model number ("CDD2000/00") in > such a way that it duplicates the HP 4020i entries. Apparently > some of the older CDD2000 drives had a different ID, so this may > not work for all. The quirks are the same as those of the HP drive. > > Philips recently advertised the internal models for US $499 (after a > rebate); this is at least $100 cheaper than the HP drives I > could find around here. I just burnt a CD and was able to read > it from FreeBSD and DOS. The HP is just an oem-ed Philips. They are equal. -Guido From owner-freebsd-hackers Sat Nov 9 11:24:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA15167 for hackers-outgoing; Sat, 9 Nov 1996 11:24:47 -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 LAA15160 for ; Sat, 9 Nov 1996 11:24:44 -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 LAA13263; Sat, 9 Nov 1996 11:23:57 -0800 (PST) Message-Id: <199611091923.LAA13263@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Guido van Rooij cc: dg@Root.COM, roberto@keltia.freenix.fr, FreeBSD-hackers@FreeBSD.ORG Subject: Re: frefall connectivity from europe In-reply-to: Your message of "Sat, 09 Nov 1996 19:58:32 +0100." <199611091858.TAA00333@gvr.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Nov 1996 11:23:56 -0800 From: Amancio Hasty Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Curious, can anyone in Europe convince a company to sponser a FreeBSD ftp site? I mean one with fast access and lots of disk spaces. The hardware now days for such a setup is not that expensive however the connectiviy costs can be high. Amancio From owner-freebsd-hackers Sat Nov 9 12:04:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA17256 for hackers-outgoing; Sat, 9 Nov 1996 12:04:29 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA17251 for ; Sat, 9 Nov 1996 12:04:25 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.2/8.8.2) id VAA00494; Sat, 9 Nov 1996 21:03:19 +0100 (MET) From: Guido van Rooij Message-Id: <199611092003.VAA00494@gvr.win.tue.nl> Subject: Re: frefall connectivity from europe In-Reply-To: <199611091923.LAA13263@rah.star-gate.com> from Amancio Hasty at "Nov 9, 96 11:23:56 am" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Sat, 9 Nov 1996 21:03:19 +0100 (MET) Cc: dg@Root.COM, roberto@keltia.freenix.fr, 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 Amancio Hasty wrote: > > Curious, can anyone in Europe convince a company to sponser a FreeBSD > ftp site? I mean one with fast access and lots of disk spaces. > > The hardware now days for such a setup is not that expensive however > the connectiviy costs can be high. ??? There are lots of mirrors in Europe. One of them is of the NLUUG, which is well-connected, -Guido From owner-freebsd-hackers Sat Nov 9 13:13:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA21309 for hackers-outgoing; Sat, 9 Nov 1996 13:13:55 -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 NAA21286 for ; Sat, 9 Nov 1996 13:13:46 -0800 (PST) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.6/UMIACS-0.9/04-05-88) id QAA04568; Sat, 9 Nov 1996 16:13:18 -0500 (EST) Date: Sat, 9 Nov 1996 16:13:17 -0500 (EST) From: Sujal Patel To: Julian Elischer cc: hackers@freebsd.org Subject: Re: Inetd mod.. comments? In-Reply-To: <3280EF24.ABD322C@whistle.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, 6 Nov 1996, Julian Elischer wrote: > I have some patches to Inetd her that I sent out for comment. > the only comment I got was > "Gee that's neat!, I need that" > > but no technical reviews or code checks.. Well, I looked *briefly* at this patch (I did not review it). It looked pretty good from my brief look, but I'd prefer to see this implemented as part of ipfw. I think this will give you a broader range of servics that can be protected (i.e. sendmail, ssh, etc). It will also moves the protection scheme to the kernel level which makes it faster, more efficient, and safer IMO. I can think of all sorts of cool things that could be done in ipfw (related to this): 1 - Rate limit incoming TCP connections to a specified port. 2 - Rate limit ICMP/UDP traffic. 3 - Limit the number of concurrent TCP connections to a port. 4 - Limit the number of concurrent TCP connections from a host/domain. The way I see it, the only reason to ever do this sort of thing in userspace is if you actually wanted to limit services based on a DNS reverse lookup (i.e. Limit concurrent TCP connections from outside of Europe). Just my 3 cents. Sujal From owner-freebsd-hackers Sat Nov 9 13:21:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA21870 for hackers-outgoing; Sat, 9 Nov 1996 13:21:03 -0800 (PST) Received: from isbalham (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA21862 for ; Sat, 9 Nov 1996 13:20:57 -0800 (PST) Received: from gid.co.uk (uucp@localhost) by isbalham (8.6.12/8.6.12) with UUCP id VAA29164; Sat, 9 Nov 1996 21:19:37 GMT Received: from [194.32.164.2] by seagoon.gid.co.uk; Sat, 9 Nov 1996 21:19:34 GMT X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 9 Nov 1996 21:19:41 +0000 To: Guido van Rooij , hasty@rah.star-gate.com (Amancio Hasty) From: rb@gid.co.uk (Bob Bishop) Subject: Re: frefall connectivity from europe Cc: dg@Root.COM, roberto@keltia.freenix.fr, FreeBSD-hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 9:03 pm 9/11/96, Guido van Rooij wrote: >Amancio Hasty wrote: >> >> Curious, can anyone in Europe convince a company to sponser a FreeBSD >> ftp site? I mean one with fast access and lots of disk spaces. >> >> The hardware now days for such a setup is not that expensive however >> the connectiviy costs can be high. > >??? There are lots of mirrors in Europe. One of them is of the NLUUG, >which is well-connected, Likewise the SunSite in London. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Sat Nov 9 14:17:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24528 for hackers-outgoing; Sat, 9 Nov 1996 14:17:08 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA24523 for ; Sat, 9 Nov 1996 14:17:05 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id PAA00829 for hackers@freebsd.org; Sat, 9 Nov 1996 15:16:58 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id PAA23921 for ; Sat, 9 Nov 1996 15:13:59 -0700 (MST) Date: Sat, 9 Nov 1996 15:13:58 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca Reply-To: Marc Slemko To: hackers@freebsd.org Subject: TCP SYN attack prevention 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'm having a little bit of trouble understanding exactly how the change in -current to help protect against TCP SYN attacks works. The relevant function from uipc_socket2.c: struct socket * sodropablereq(head) register struct socket *head; { register struct socket *so; unsigned int i, j, qlen; static int rnd; static long old_mono_secs; static unsigned int cur_cnt, old_cnt; if ((i = (mono_time.tv_sec - old_mono_secs)) != 0) { old_mono_secs = mono_time.tv_sec; old_cnt = cur_cnt / i; cur_cnt = 0; } so = TAILQ_FIRST(&head->so_incomp); if (!so) return (so); qlen = head->so_incqlen; if (++cur_cnt > qlen || old_cnt > qlen) { rnd = (314159 * rnd + 66329) & 0xffff; j = ((qlen + 1) * rnd) >> 16; while (j-- && so) so = TAILQ_NEXT(so, so_list); } return (so); } How I read the code is that cur_cnt will be the count of the number of times this routine has been called during second; at high rates of attack, this will be approximately equal to the total number of SYN packets received. old_cnt looks like it is the average number of times per second that sodropablereq has been called in the previous one or more (i) seconds; under high rates of attack, i will be 1. TAILQ_FIRST(&head->so_incomp) will be the oldest incomplete connection. qlen will be the current number of incomplete pending connections. Where I get a bit confused is at the (++cur_cnt > qlen || old_cnt > qlen) conditional. I am reading this as saying that the body of the if is only execured if the number of packets so far this second is greater than the length of the queue, or the number of packets per second in the last i second(s) is greater than the length of the queue. That makes no sense at all to me. If somaxconn is set to something moderate like 512 (and the application calls listen() in the right manner to be able to use all of that) then it would take an extremely high rate of attack to enable the random drop. If this conditional isn't enabled, then it just does oldest early drop. Is this code intented to only switch to random early drop from oldest early drop when the rate of attack is extremely high? If so, I'm not sure I quite see the logic behind the current condition. BTW, I notice this code is still disabled in tcp_input.c behind a TCPSYNRED ifdef. From my reading of it, that essentially removes most of the protection from -current and just does the standard BSD thing of dropping the new reqeust. This should probably be fixed up before 2.2; actually, it probably would be a very good thing to have (even if it was just oldest early drop) in 2.1.6. Oh, now I remember, -stable doesn't use the 4.4 queue macros so you can't find the oldest pending connection cleanly. Random drop would still work though. From owner-freebsd-hackers Sat Nov 9 15:20:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27868 for hackers-outgoing; Sat, 9 Nov 1996 15:20:45 -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 PAA27854 for ; Sat, 9 Nov 1996 15:20:41 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA08985; Sat, 9 Nov 1996 18:20:02 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 9 Nov 1996 18: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 OAA28790 for ; Sat, 9 Nov 1996 14:14:56 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id OAA10664 for freebsd-hackers@freefall.cdrom.com; Sat, 9 Nov 1996 14:16:09 -0500 (EST) Date: Sat, 9 Nov 1996 14:16:09 -0500 (EST) From: Thomas David Rivers Message-Id: <199611091916.OAA10664@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Even more info on daily panics... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok - Just so everyone doesn't think I've vanished from the face of the earth :-) I thought I'd provide a little status. I'm now running a 2.1.5-S kernel I grabbed on Oct. 17th. This kernel has two changes to is: 1) The "patch" Terry suggested to vfs_subr.c [which, in itself didn't stop my problem from reoccuring.] 2) The change in vrele() to catch when the usecount goes negative. I installed that kernel on Nov. 7th... It is now Sat Nov 9 14:11:33 EST 1996, and uptime shows: 2:11PM up 2 days, 1:14, 1 user, load averages: 0.81, 0.90, 0.83 That is, the machine has not panic'd since I installed this kernel. There is one possibility - perhaps, when I was trying Terry's suggested patch, I accidently installed the wrong kernel... maybe Terry's patch does work-around the problem. There is another possibility - in the past, the machine would sometimes go for two or three days without a panic. It would rarely go longer than that. I could be in one of these "lulls." There is still another possibility, gcc 2.6.3 has a bug which is tickled by the vrele() code. Changing the source caused the bad code to not be generated [I'll be the first one to admit that I'm reaching here...] Anyway, as soon as something happens, either the typical panic's I've been getting, or a new panic from usecount<0 in vrele() - I'll let everyone know... - Dave Rivers - From owner-freebsd-hackers Sat Nov 9 15:44:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA28921 for hackers-outgoing; Sat, 9 Nov 1996 15:44:46 -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 PAA28908 for ; Sat, 9 Nov 1996 15:44:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id PAA21711; Sat, 9 Nov 1996 15:42:07 -0800 (PST) Date: Sat, 9 Nov 1996 15:42:05 -0800 (PST) From: John-Mark Gurney X-Sender: jmg@nike Reply-To: John-Mark Gurney To: Adrian Pavlykevych cc: hackers@freebsd.org Subject: Re: Bootstrap doesn't recognize keyboardless config In-Reply-To: <199611091615.SAA07885@NetSurfer.lp.lviv.ua> 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, 9 Nov 1996, Adrian Pavlykevych wrote: > Hi everybody, > > I have stuck trying to setup headless (w/o keyboard, monitor) server. > > I can force kernel and boot to use serial console via COMCONSOLE and > FORCE_COMCOMSOLE compile options, but README.serial in > /usr/src/sys/i386/boot/biosboot states that default behaviour of bootstrap > code is as follows: if it detects keyboard it starts with video console, if no it switches to > serial console. I can't get it to work this way. > > It seems that bootstrap doesn't detect that keyboard is absent. > > Can somebody give some sound advices? sure... rebuild the boot blocks with FORCE_COMCONSOLE enabled... edit the makefile for this... then install with a command similar to disklabel -B (of course after make install'ing the boot blocks)... I had to do that to force the boot blocks to come up on the com console... hope this helps.. 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 Sat Nov 9 16:46:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA01008 for hackers-outgoing; Sat, 9 Nov 1996 16:46:55 -0800 (PST) Received: from zygorthian-space-raiders.MIT.EDU (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA01001 for ; Sat, 9 Nov 1996 16:46:48 -0800 (PST) Received: (from mycroft@localhost) by zygorthian-space-raiders.MIT.EDU (8.7.4/8.6.11) id TAA19469; Sat, 9 Nov 1996 19:46:34 -0500 (EST) Date: Sat, 9 Nov 1996 19:46:34 -0500 (EST) From: "Charles M. Hannum" Message-Id: <199611100046.TAA19469@zygorthian-space-raiders.MIT.EDU> To: nate@mt.sri.com Subject: Re: DOS Emulator (was: Re: JDK 1.02) Cc: hackers@FreeBSD.ORG, msmith@atrad.adelaide.edu.au Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Then he/I/whoever will be looking at the huge pile of changes that CMH >> has made to dosemu for NetBSD and integrating them with the BSDI version >> so that the resultant mutant will run at least under BSD/OS and FreeBSD. > > CMH only modified the changes that John Kohl did. John deserves most of > the credit for DOSEMU in NetBSD. That's true of DOSEMU, but in context it seems clear that someone just typoed `doscmd'. As far as I'm aware, I'm the only person who has significantly modified doscmd and made the changes available. From owner-freebsd-hackers Sat Nov 9 18:45:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05877 for hackers-outgoing; Sat, 9 Nov 1996 18:45:42 -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 SAA05872 for ; Sat, 9 Nov 1996 18:45:37 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id VAA14291 for ; Sat, 9 Nov 1996 21:45:54 -0500 (EST) Date: Sat, 9 Nov 1996 21:45:52 -0500 (EST) From: "Marc G. Fournier" To: hackers@freebsd.org Subject: semaphores/shared memory 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 again... 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... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org From owner-freebsd-hackers Sat Nov 9 19:59:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA10148 for hackers-outgoing; Sat, 9 Nov 1996 19:59:20 -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 TAA10142 for ; Sat, 9 Nov 1996 19:59:16 -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 TAA20436; Sat, 9 Nov 1996 19:58:28 -0800 (PST) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id OAA32061; Sun, 10 Nov 1996 14:58:06 +1100 From: Julian Assange Message-Id: <199611100358.OAA32061@suburbia.net> Subject: Re: MMAP: how to use... To: scrappy@ki.net (Marc G. Fournier) Date: Sun, 10 Nov 1996 14:58:06 +1100 (EST) Cc: hackers@FreeBSD.org In-Reply-To: from "Marc G. Fournier" at Nov 9, 96 10:27:53 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Hi... > > Can anyone direct me to either an online source, or a good > book, on MMAP? > > Thanks... Here are some tests I wrote for nntpcache. should give you an idea. #include "config.h" #ifdef HAVE_MMAP /* $Id: mmap_tests.c,v 1.10 1996/11/08 20:29:02 proff Exp $ * * various mmap() implimentations suck; we attempt to find out just how * hard. * * - Julian Assange (proff@suburbia.net) * * Test results: (please send additions to proff@suburbia.net) * * linux 2.0.0 allows shared mmaps only for files, while 1.2.13 * doesn't permit shared mmaps at all. * * Linux suburbia 2.0.0 #29- Thu Jul 11 18:03:20 EST 1996 i586 * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_FILE_SHARED_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_ANON_PRIVATE * HAVE_MMAP_ANON_PRIVATE_CHILD_INHERIT * * Linux server 1.2.13 #6 Wed Feb 28 15:45:11 CST 1996 i486 (forget it) * * program output: * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_ANON_PRIVATE * HAVE_MMAP_ANON_PRIVATE_CHILD_INHERIT * * Freebsd is purrrrfect. * * FreeBSD profane 2.2-CURRENT #0 Sat Jul 27 19:16:00 EST 1996 * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_FILE_SHARED_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_ANON_PRIVATE * HAVE_MMAP_ANON_PRIVATE_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED * HAVE_MMAP_ANON_SHARED_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_ANON_SHARED_PARENT_READ_CHILD_WRITE * * Suprisingly, AIX is faultless too. * * AIX whisky 2 3 000027477600 * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_FILE_SHARED_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_ANON_PRIVATE * HAVE_MMAP_ANON_PRIVATE_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED * HAVE_MMAP_ANON_SHARED_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_ANON_SHARED_PARENT_READ_CHILD_WRITE * * Shared mmap file writes are screwed under BSDI! * * BSD/OS telepath.com 2.1 BSDI BSD/OS 2.1 Kernel #3: Thu Mar 7 10:47:49 CST 1996 * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_ANON_PRIVATE * HAVE_MMAP_ANON_PRIVATE_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED * HAVE_MMAP_ANON_SHARED_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_ANON_SHARED_PARENT_READ_CHILD_WRITE * * SunOS omega.iqm.unicamp.br 5.4 generic i86pc i386 * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_FILE_SHARED_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * * SunOS chaos 4.1C 4.1.3 sun4 * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_FILE_SHARED_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * * SunOS unix1 5.3 Generic_101318-59 sun4m sparc (no shared file write?) * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * * SunOS sydney6 5.5 Generic_103093-03 sun4m sparc SUNW,SPARCstation-20 * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_FILE_SHARED_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * * Novell Unixware 2.03 (System V Release 4.2MP) UNIX_SV aapo 4.2MP 2.03 i386 x86at * * HAVE_MMAP_FILE_PRIVATE_READ * HAVE_MMAP_FILE_PRIVATE_CHILD_INHERIT * HAVE_MMAP_FILE_PRIVATE_WRITE * HAVE_MMAP_FILE_SHARED_READ * HAVE_MMAP_FILE_SHARED_CHILD_INHERIT * HAVE_MMAP_FILE_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_FILE_SHARED_PARENT_READ_CHILD_WRITE * HAVE_MMAP_FILE_SHARED_WRITE * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE * * ULTRIX wolf.cs.washington.edu 4.2 0 RISC (way to go ultrix) * * nothing. zilch. * * OSF1 porky-pig V3.2 214 alpha (unexpected. osf/1 sucks). * * HAVE_MMAP_DEV_ZERO_PRIVATE * HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT * HAVE_MMAP_DEV_ZERO_SHARED * HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT * HAVE_MMAP_ANON_PRIVATE * HAVE_MMAP_ANON_PRIVATE_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED * HAVE_MMAP_ANON_SHARED_CHILD_INHERIT * HAVE_MMAP_ANON_SHARED_CHILD_READ_PARENT_WRITE * HAVE_MMAP_ANON_SHARED_PARENT_READ_CHILD_WRITE */ #include #include #include #include #include #include #include #include #define MM_SIZE (100*1024) #define TEST_FILE "mmap_test.tmp" int caught_sigquit; void sigquit (int sig) { caught_sigquit++; signal (SIGQUIT, sigquit); } void sigalrm (int sig) { caught_sigquit++; signal (SIGALRM, sigalrm); } jmp_buf jmp; void sigsegv (int sig) { signal (SIGSEGV, sigsegv); longjmp (jmp, 1); } /* * TODO: test MAP_INHERIT, MAP_FIXED (can't see that latter being much of an issue) */ void test_child(char *p, char *msg) { char *im = "inherit_magic"; char *pm = "parent_magic"; char *cm = "child_magic"; pid_t pid; int ws; fflush (stdout); if (!setjmp(jmp)) strcpy (p, im); caught_sigquit = 0; signal (SIGQUIT, sigquit); signal (SIGCHLD, SIG_IGN); signal (SIGALRM, sigalrm); pid = fork(); if (pid<0) return; if (pid==0) { if (!setjmp(jmp)) if (strcmp(p, im)==0) printf("%s_CHILD_INHERIT\n", msg); alarm(5); kill (getppid(), SIGQUIT); while (!caught_sigquit) pause (); caught_sigquit = 0; if (!setjmp(jmp)) if (strcmp(p, pm)==0) printf("%s_CHILD_READ_PARENT_WRITE\n", msg); if (!setjmp(jmp)) strcpy (p, cm); fflush (stdout); kill (getppid(), SIGQUIT); exit(0); } /* parent */ alarm(5); while (!caught_sigquit) pause (); caught_sigquit = 0; if (!setjmp(jmp)) strcpy (p, pm); alarm(5); kill (pid, SIGQUIT); while (!caught_sigquit) pause (); if (!setjmp(jmp)) if (strcmp(p, cm)==0) printf("%s_PARENT_READ_CHILD_WRITE\n", msg); signal (SIGQUIT, SIG_DFL); alarm(0); wait(&ws); } int main() { volatile int fd; char *m = malloc(MM_SIZE); char buf[1024]; signal (SIGSEGV, sigsegv); #if defined(MAP_PRIVATE) fd = open(TEST_FILE, O_RDWR|O_CREAT|O_TRUNC, 0666); strcpy (m, "mmap magic"); write (fd, m, MM_SIZE); lseek (fd, 0, SEEK_SET); if (fd>=0) { char *p=(char *)mmap(0, MM_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); if (p!=(char *)-1) { if (!setjmp(jmp)) if (strcmp(p, m)==0) puts("HAVE_MMAP_FILE_PRIVATE_READ"); test_child(p, "HAVE_MMAP_FILE_PRIVATE"); if (!setjmp(jmp)) { strcpy (p, "mmap magic2"); munmap (p, MM_SIZE); read (fd, buf, 12); if (strcmp(buf, "mmap magic2")!=0) puts("HAVE_MMAP_FILE_PRIVATE_WRITE"); } else munmap (p, MM_SIZE); } close (fd); } #endif #if defined(MAP_SHARED) fd = open(TEST_FILE, O_RDWR|O_CREAT|O_TRUNC, 0666); strcpy (m, "mmap magic"); write (fd, m, MM_SIZE); lseek (fd, 0, SEEK_SET); if (fd>=0) { char *p=(char *)mmap(0, MM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (p!=(char *)-1) { if (!setjmp(jmp)) if (strcmp(p, m)==0) puts("HAVE_MMAP_FILE_SHARED_READ"); test_child(p, "HAVE_MMAP_FILE_SHARED"); if (!setjmp(jmp)) { strcpy (p, "mmap magic2"); munmap (p, MM_SIZE); read (fd, buf, 12); if (strcmp(buf, "mmap magic2")==0) puts("HAVE_MMAP_FILE_SHARED_WRITE"); } else munmap (p, MM_SIZE); } close (fd); } #endif #if defined(MAP_PRIVATE) fd = open("/dev/zero", O_RDWR, 0666); if (fd>=0) { char *p=(char *)mmap(0, MM_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); if (p!=(char *)-1) { if (!setjmp(jmp)) { strcpy (p, "mmap magic_dev_zero"); if (strcmp (p, "mmap magic_dev_zero")==0) puts("HAVE_MMAP_DEV_ZERO_PRIVATE"); } test_child(p, "HAVE_MMAP_DEV_ZERO_PRIVATE"); munmap (p, MM_SIZE); } close (fd); } #endif #if defined(MAP_PRIVATE) fd = open("/dev/zero", O_RDWR, 0666); if (fd>=0) { char *p=(char *)mmap(0, MM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (p!=(char *)-1) { if (!setjmp(jmp)) { strcpy (p, "mmap magic_dev_zero_shared"); if (strcmp (p, "mmap magic_dev_zero_shared")==0) puts("HAVE_MMAP_DEV_ZERO_SHARED"); } test_child(p, "HAVE_MMAP_DEV_ZERO_SHARED"); munmap (p, MM_SIZE); } close (fd); } #endif #if defined(MAP_ANONYMOUS) && !defined(MAP_ANON) #define MAP_ANON MAP_ANONYMOUS #endif #ifdef MAP_ANON { char *p=(char *)mmap(0, MM_SIZE, PROT_READ | PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0); if (p!=(char *)-1) { if (!setjmp(jmp)) { strcpy (p, "mmap magic_anon"); if (strcmp(p, "mmap magic_anon")==0) puts("HAVE_MMAP_ANON_PRIVATE"); } test_child(p, "HAVE_MMAP_ANON_PRIVATE"); munmap (p, MM_SIZE); } } #endif #if defined(MAP_ANON) && defined(MAP_SHARED) { char *p=(char *)mmap(0, MM_SIZE, PROT_READ | PROT_WRITE, MAP_ANON|MAP_SHARED, -1, 0); if (p!=(char *)-1) { if (!setjmp(jmp)) { strcpy (p, "mmap magic_shared_anon"); if (strcmp(p, "mmap magic_shared_anon")==0) puts("HAVE_MMAP_ANON_SHARED"); } test_child(p, "HAVE_MMAP_ANON_SHARED"); munmap (p, MM_SIZE); } } #endif unlink(TEST_FILE); exit (0); } #else /* HAVE_MMAP */ # error no working mmap call on this system?! #endif -- "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 Sat Nov 9 20:46:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA12797 for hackers-outgoing; Sat, 9 Nov 1996 20:46:57 -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 UAA12790 for ; Sat, 9 Nov 1996 20:46:53 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id PAA01623; Sun, 10 Nov 1996 15:15:18 +1030 (CST) From: Michael Smith Message-Id: <199611100445.PAA01623@genesis.atrad.adelaide.edu.au> Subject: Re: DOS Emulator (was: Re: JDK 1.02) In-Reply-To: <199611100046.TAA19469@zygorthian-space-raiders.MIT.EDU> from "Charles M. Hannum" at "Nov 9, 96 07:46:34 pm" To: mycroft@mit.edu (Charles M. Hannum) Date: Sun, 10 Nov 1996 15:15:17 +1030 (CST) Cc: nate@mt.sri.com, hackers@FreeBSD.ORG, msmith@atrad.adelaide.edu.au 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 M. Hannum stands accused of saying: > > >> Then he/I/whoever will be looking at the huge pile of changes that CMH > >> has made to dosemu for NetBSD and integrating them with the BSDI version > >> so that the resultant mutant will run at least under BSD/OS and FreeBSD. > > > > CMH only modified the changes that John Kohl did. John deserves most of > > the credit for DOSEMU in NetBSD. > > That's true of DOSEMU, but in context it seems clear that someone just > typoed `doscmd'. As far as I'm aware, I'm the only person who has > significantly modified doscmd and made the changes available. The typo was indeed my fault; sorry for that. I've actually significantly changed doscmd again, but the whole thing is still hung up waiting for the FreeBSD vm86 stuff to happen. (That's a really old message Charles! 8) -- ]] 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 9 21:12:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA14692 for hackers-outgoing; Sat, 9 Nov 1996 21:12:57 -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 VAA14686 for ; Sat, 9 Nov 1996 21:12:45 -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 XAA12202; Sat, 9 Nov 1996 23:12:30 -0600 (CST) Received: by bio-5.bsd.uchicago.edu (5.0/SMI-SVR4) id AA13579; Sat, 9 Nov 1996 23:12:27 +0600 Date: Sat, 9 Nov 1996 23:12:27 +0600 Message-Id: <9611100512.AA13579@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 > 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. Sort of a kluge, but it ought to work. From owner-freebsd-hackers Sat Nov 9 21:22:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA15371 for hackers-outgoing; Sat, 9 Nov 1996 21:22:30 -0800 (PST) Received: from cheops.anu.edu.au (daemon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA15358 for ; Sat, 9 Nov 1996 21:22:24 -0800 (PST) Message-Id: <199611100522.VAA15358@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA249209402; Sun, 10 Nov 1996 12:30:02 +1100 From: Darren Reed Subject: Re: Inetd mod.. comments? To: smpatel@umiacs.umd.edu (Sujal Patel) Date: Sun, 10 Nov 1996 12:30:02 +1100 (EDT) Cc: julian@whistle.com, hackers@FreeBSD.ORG In-Reply-To: from "Sujal Patel" at Nov 9, 96 04:13:17 pm 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: [...] > 1 - Rate limit incoming TCP connections to a specified port. > 2 - Rate limit ICMP/UDP traffic. These two will come when the RSVP folk get things finalised. > 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). Darren From owner-freebsd-hackers Sat Nov 9 23:39:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA21073 for hackers-outgoing; Sat, 9 Nov 1996 23:39:23 -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 XAA21065 for ; Sat, 9 Nov 1996 23:39:20 -0800 (PST) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.6/UMIACS-0.9/04-05-88) id CAA11253; Sun, 10 Nov 1996 02:39:13 -0500 (EST) Date: Sun, 10 Nov 1996 02:39:13 -0500 (EST) From: Sujal Patel To: Darren Reed cc: julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: Inetd mod.. comments? In-Reply-To: <199611100522.VAA15358@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 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? Sujal From owner-freebsd-hackers Sat Nov 9 23:46:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA21490 for hackers-outgoing; Sat, 9 Nov 1996 23:46:35 -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 SMTP id XAA21467; Sat, 9 Nov 1996 23:46:28 -0800 (PST) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id XAA18443; Sat, 9 Nov 1996 23:46:27 -0800 Date: Sat, 9 Nov 1996 23:46:27 -0800 (PST) From: Jaye Mathisen To: hackers@freebsd.org, scsi@freebsd.org Subject: Anybody compiling -current with AHC_DEBUG? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Fails miserably for me on kernel supped 11/8, with undefined structure stuff. cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DAHC_DEBUG -DCOMPAT_43 -DNFS -DFFS -DINET -DKERNEL ../../i386/scsi/aic7xxx.c ../../i386/scsi/aic7xxx.c: In function `ahc_print_scb': ../../i386/scsi/aic7xxx.c:318: structure has no member named `control' ../../i386/scsi/aic7xxx.c:319: structure has no member named `tcl' ../../i386/scsi/aic7xxx.c:320: structure has no member named `cmdlen' ../../i386/scsi/aic7xxx.c:321: structure has no member named `cmdpointer' ../../i386/scsi/aic7xxx.c:323: structure has no member named `datalen' ../../i386/scsi/aic7xxx.c:324: structure has no member named `data' ../../i386/scsi/aic7xxx.c:325: structure has no member named `SG_segment_count' ../../i386/scsi/aic7xxx.c:326: structure has no member named `SG_list_pointer' ../../i386/scsi/aic7xxx.c: In function `ahc_scsi_cmd': ../../i386/scsi/aic7xxx.c:2187: `DEBUGTARGET' undeclared (first use this function) ../../i386/scsi/aic7xxx.c:2187: (Each undeclared identifier is reported only once ../../i386/scsi/aic7xxx.c:2187: for each function it appears in.) *** Error code 1