Date: Fri, 15 Nov 1996 12:09:11 +0000 From: "RIVERA, ELADIO " <E0R8047@acs.tamu.edu> To: hackers@freefall.freebsd.org Cc: freebsd-hackers-digest@FreeBSD.ORG Subject: Re: hackers-digest V1 #1641 Message-ID: <Pine.VMS.3.91-vms-b4-acs.961115120809.20504A-100000@VMS1.TAMU.EDU> In-Reply-To: <199611151659.IAA29419@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Nov 1996 owner-hackers-digest@freefall.freebsd.org wrote: Does anyone have any hints about Unix I would really appreciate the help. Thanks goat boy > > hackers-digest Friday, 15 November 1996 Volume 01 : Number 1641 > > In this issue: > Re: userland PPP giving weird load numbers > Re: Interesting URL > multicast - does NT 4.0 have it? Does Linux have it? > Re: FreeBSD 2.2-ALPHA is now available. > Re: Sockets question... > Re: Q: system specific binaries > Re: Q: system specific binaries > Re: Sockets question... > Re: Sockets question... > Re: FreeBSD 2.2-ALPHA is now available. > Re: Sockets question... > Today's panic. > Re: multicast - does NT 4.0 have it? Does Linux have it? > Re: Sockets question... > Re: Q: How to read hardware port ? *HELP* > Re: Programming technique for non-forking servers? > Re: Programming technique for non-forking servers? > Contribution of Intel EtherExpress Pro/10 driver > > ---------------------------------------------------------------------- > > From: hm@kts.org (Hellmuth Michaelis) > Date: Fri, 15 Nov 1996 12:45:06 +0100 (MET) > Subject: Re: userland PPP giving weird load numbers > > > > > I see this too all the time, from 2.0.5 all the way to 2.1.5. While > > > > /usr/sbin/ppp is running, the load average hangs around 1.0. Sometimes, > > > > it'll drop. It's odd ... it's usually when ppp is idle that it hangs > > > > around 1.0. > > > > > > I had this phenomenon too - but NOT with ppp. An isdn userland daemon i am > > > working on showed this exact behaviour; when it was running, the system load > > > was constantly 1.0 or very nearby. This all is under 2.1.5 (and 2.1 too). > > > The process wasn't doing anything (or very little). > > > > But what _was_ it supposed to be doing? > > Ok, when this happened, the daemon was in a tight read() loop, where the > read() timed out every second in the driver. Basically after implementing > select() in the driver and using that with a one second timeout made the > problem go away. > > In the whole application several one second timeouts exists at several > drivers in the kernel - i'm quite shure there is a problem with something > like several timeouts timing out simultaneously causing something. > > I just ran out of ideas where to search for and what to search for so i > stopped looking for the real problem. But i'm able to reproduce it. > > hellmuth > - -- > Hellmuth Michaelis hm@kts.org Hamburg, Europe > (A)bort, (R)etry, (I)nstall BSD ? > - -------------------------------------------------------------------------------- > kts.org will move and will be not available from November 20th for 10 days > - -------------------------------------------------------------------------------- > > ------------------------------ > > From: John Fieber <jfieber@indiana.edu> > Date: Fri, 15 Nov 1996 09:11:58 -0500 (EST) > Subject: Re: Interesting URL > > On Thu, 14 Nov 1996, Chuck Robey wrote: > > > I found an interesting URL full of some neat C++ graphics and network > > code. I'm always complaining to friends that C++ doesn't have enough > > public code out there, so this is a nice surprise I thought I'd share. > > Speaking of C++, there is a showstopper problem in 2.2-ALPHA with > respect to STL. The fix appears to be simple and a patch has > been submitted via send-pr. I have neither space nor time at > this final hour to check it out personally or I would commit it > myself, but it would *really* be a shame to ship 2.2 with an > inoperable STL because of 3 missed files in the stdc++ library... > > - -john > > == jfieber@indiana.edu =========================================== > == http://fallout.campusview.indiana.edu/~jfieber ================ > > > ------------------------------ > > From: Christoph Kukulies <kuku@gilberto.physik.rwth-aachen.de> > Date: Fri, 15 Nov 1996 16:16:02 +0100 > Subject: multicast - does NT 4.0 have it? Does Linux have it? > > As the subject asks: Do NT 4.0 and Linux 2.x have multicast > routing in their kernel, i.e. can they act as a multicast router > resp. run mrouted? > > - --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > ------------------------------ > > From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> > Date: Fri, 15 Nov 1996 07:18:11 -0800 (PST) > Subject: Re: FreeBSD 2.2-ALPHA is now available. > > > > I have clients with 2 and 3 of these cards in one system running 32 and > > > 48 ports respectifully. It will work for you when you go above your > > > current 4 port utilization. > > > > > > You are correct about the 8 port not having modem control, but I think > > > the (not positive here) the 4 port does. If not I _know_ the 6 port > > > board does. > > > > 4 port does not, 6 port does. > > > > Unless the product offering has changed lately. > > Thanks Joe, combining your statement with what another person said > defanitly qualifies the fact that the BB1004 does not have modem > support, and that the IOAT66 (6-port) does. > > Jordan, can you please list this in the serial board section of the > release/whatever notes: > > Boca BB1004 4-Port serial card (Modems NOT supported) > Boca IOAT66 6-Port serial card (Modems supported) > Boca BB1008 8-Port serial card (Modems NOT supported) > Boca BB2016 16-Port serial card (Modems supported) > > - -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation, Inc. Reliable computers for FreeBSD > > ------------------------------ > > From: Bruce Evans <bde@zeta.org.au> > Date: Sat, 16 Nov 1996 02:29:19 +1100 > Subject: Re: Sockets question... > > >% man 2 read > >(SunOS version) > >... > >READ(2V) SYSTEM CALLS READ(2V) > > > > system guarantees to read the number of bytes requested if > > the descriptor references a normal file which has that many > > bytes left before the EOF (end of file), but in no other > > case. > > > >Key words, "but in no other case".. > > FreeBSD says the same thing in the same words except for English > improvements. It lies :-). Short reads are possible even for > normal files because the read might be into a partially invalid > buffer. ffs_read() returns the blocks that are successfully > read instead of unwinding the read and returning an EFAULT error. > Example: > > - --- > #include <stdio.h> > #include <stdlib.h> > > #define SIZE 0x10000 > > main() > { > void *buf; > int n; > > > buf = malloc(0x10000); > n = read(0, buf, 0x10000); > printf("read %d\n", n); > } > - --- > > This prints 65536 here. A watertight example can be probably be > constructed using mmap(). > > Short writes to normal files are more likely. They occur when the > disk fills up and for partially invalid buffers. There are more > serious problems for the latter case. > > Bruce > > ------------------------------ > > From: "John S. Dyson" <toor@dyson.iquest.net> > Date: Fri, 15 Nov 1996 10:43:10 -0500 (EST) > Subject: Re: Q: system specific binaries > > > > > > > Hi, > > > > Does anyone have any experience with customising FreeBSD so that only > > binaries which are compiled on a system itself will actually run on > > that system ? > > So the local compiler has to give a key to each binary when it's > > compiled, and when executed there'd be a check for that key. ? > > That way only people who have access to the compiler may generate > > binaries, and no 'foreign' binaries will be executed by the syetem. > > > > If this is too easy to break, is there perhaps a way to specify > > from which directories binaries may be executed ? > > > Perhaps, formulate a system whereby the flags bits on a file are used > in some way... Note that I am not talking about the "protection" bits, > but there is another group of interesting things called flags bits that > can be placed only under the control of the kernel. Just a thought. > > (Perhaps an "annoint" command???) > John > > ------------------------------ > > From: jlemon@americantv.com (Jonathan Lemon) > Date: Fri, 15 Nov 1996 10:01:10 -0600 > Subject: Re: Q: system specific binaries > > > > Does anyone have any experience with customising FreeBSD so that only > > > binaries which are compiled on a system itself will actually run on > > > that system ? > > > So the local compiler has to give a key to each binary when it's > > > compiled, and when executed there'd be a check for that key. ? > > > That way only people who have access to the compiler may generate > > > binaries, and no 'foreign' binaries will be executed by the syetem. > > > > > > If this is too easy to break, is there perhaps a way to specify > > > from which directories binaries may be executed ? > > > > > Perhaps, formulate a system whereby the flags bits on a file are used > > in some way... Note that I am not talking about the "protection" bits, > > but there is another group of interesting things called flags bits that > > can be placed only under the control of the kernel. Just a thought. > > > > (Perhaps an "annoint" command???) > > Now, why does this remind me of nettrek's "blessed" binaries? > - -- > Jonathan > > ------------------------------ > > From: Karl Denninger <karl@Mcs.Net> > Date: Fri, 15 Nov 1996 10:07:47 -0600 (CST) > Subject: Re: Sockets question... > > > > I have an application which sends a query to a back-end server -- and that > > > server can return literally hundreds of KB of data in response. > > > > > > On very long responses, it just STOPS. > > > > > > The writing end thinks it wrote all of the data, netstat -an shows nothing > > > in the socket buffers, the reader is waiting in read() for more data (it > > > never saw the end marker, and in fact never saw more than half of the > > > response!) > > > > If the socket is not in non-blocking mode, and you do a write(2) of N > > bytes to it, and the write call returns anything other than -1 or N, > > then that is a bug. > > The mode has not been modified; it should be in *blocking* mode. The write > returns the correct number of bytes in each case. > > > If the sending socket returns N, but not all of the data gets to > > the receiving socket, then that is either a bug or a network problem. > > Bingo. Send more than about 400KB in a stream transaction and you WILL see > this. Its very repeatable. > > Bascially, what we do is this: > > The query goes to the server. It specifies the moral equivalent of a > "select" call in ESQL (this is a home-brew database application). > > The server computes the response, and squirts out ~8500 records in response, > each of which is ~140 bytes long. This is 8500 write(2) calls, one for each > record. All return with no errors. > > About 2700 of the records get to the other end. The rest DISAPPEAR. They > are NOT in the socket buffers (netstat -an shows *zero* bytes in the > queue). > > I have *also* seen this if you zmodem a file to a terminal server port. You > have a very good chance of long files not getting there intact. I thought > this was a terminal server problem, but I'm no longer convinced -- this > looks like a problem in the network code. > > Note that for the NETWORK case if we compile an on older machine running a > - -CURRENT kernel (built around the July timeframe, has gcc 2.6.3 on it) the > application does NOT exhibit this problem. > > Compile on the -current machine, and it DOES. > > In both cases the application is linked -static. > > > >From write(2): > > > > When using non-blocking I/O on objects such as sockets that are subject > > ^^^^^^^^^^^^ > > to flow control, write() and writev() may write fewer bytes than request- > > ed; the return value must be noted, and the remainder of the operation > > should be retried when possible. > > > > OK, it doesn't come right out and say directly that it _won't_ do that > > when using blocking I/O. But that is the implication. And it is the > > historical behavior. And it is the behavior that probably 90% of > > network applications are written to expect. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Karl Denninger <karl@mcs.net> > Date: Fri, 15 Nov 1996 10:13:58 -0600 (CST) > Subject: Re: Sockets question... > > > > > Are you checking the return value from write() to make sure it actually > > > > thinks that N bytes were _written_? > > > > > > > > ... JG > > > > > > Uh, hang on a second... > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > would expect to see a write(2) call to the socket come back with a short > > > count for any reason other than the remote having closed or some other > > > kind of transport error (ie: host unreachable, etc)? > > > > Yes: a nonblocking socket write will most definitely display this > > behaviour. > > Yes, but I did not set nonblocking mode on that socket. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Joe Greco <jgreco@brasil.moneng.mei.com> > Date: Fri, 15 Nov 1996 10:13:49 -0600 (CST) > Subject: Re: FreeBSD 2.2-ALPHA is now available. > > > > 4 port does not, 6 port does. > > > > > > Unless the product offering has changed lately. > > > > Thanks Joe, combining your statement with what another person said > > defanitly qualifies the fact that the BB1004 does not have modem > > support, and that the IOAT66 (6-port) does. > > Actually cruising the Boca Web site is handy... ( :-) :-) ) > > http://www.bocaresearch.com/docs/prodlist.htm > > Product Code: BB1008 > Eight-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix > and PC-MOS. Includes eight six-foot RJ-11 to DB-25 cables. > > Product Code: BB1004 > Four-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and > PC-MOS. Includes four six-foot RJ-11 to DB-25 cables. > > Product Code: IOAT66 > I/O ports for ISA/EISA. Six high-speed RS-232 serial ports with 10-pin RJ-45 > connectors and 16C550 buffered UARTs. Excellent product for bulletin board > and fax server applications. > > Product Code: BB2016 > 16-port serial expansion BOCABOARD for ISA. Drivers for SCO Unix/Xenix and > PC-MOS. External concentrator supports up to 16 RJ-45 ports. > > Unfortunately their use of "RJ-45" is incorrect, it's actually a ten pin > connector, allowing for full modem control. > > > Jordan, can you please list this in the serial board section of the > > release/whatever notes: > > > > Boca BB1004 4-Port serial card (Modems NOT supported) > > Boca IOAT66 6-Port serial card (Modems supported) > > Boca BB1008 8-Port serial card (Modems NOT supported) > > Boca BB2016 16-Port serial card (Modems supported) > > That is reasonable. > > I have been toying with the idea of picking up an IOAT66, but I've had > bad experiences with a BB2016 (interrupt problems) and I am a bit > hesitant to try a Boca serial board again. :-) I guess that's fine > since I don't think I know anyone who sells them anyways. But they > ARE very inexpensive! > > ... JG > > ------------------------------ > > From: Joe Greco <jgreco@brasil.moneng.mei.com> > Date: Fri, 15 Nov 1996 10:17:30 -0600 (CST) > Subject: Re: Sockets question... > > > > > > Are you checking the return value from write() to make sure it actually > > > > > thinks that N bytes were _written_? > > > > > > > > > > ... JG > > > > > > > > Uh, hang on a second... > > > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > > would expect to see a write(2) call to the socket come back with a short > > > > count for any reason other than the remote having closed or some other > > > > kind of transport error (ie: host unreachable, etc)? > > > > > > Yes: a nonblocking socket write will most definitely display this > > > behaviour. > > > > Yes, but I did not set nonblocking mode on that socket. > > Did you receive a signal? That is known to cause similar behaviour on > SunOS... > > However, if you received a return value from write() equal to the number > of bytes you supplied to write(), I would state that the problem is > almost certainly elsewhere. > > ... JG > > ------------------------------ > > From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> > Date: Fri, 15 Nov 1996 07:23:40 -0500 (EST) > Subject: Today's panic. > > Well, I got a panic last night just after 1am - a different > time; but it's a panic I've reported before. > > "panic: ifree: freeing free inode" > > in ffs_vfree(). > > Recall, this is a 2.1.5-STABLE kernel I grabbed on Oct. 17th > (should I refresh this?), with Terry's suggested check in > vfs_subr.c and David's check for v_usecount==0 in vnode_pager.c > [Previous mail contains the context diff's for these two files.] > > Here's the traceback - but we've seen it before.... > > Again, let me say how much I appreciate everyone's effort on this! > > - Dave Rivers - > > > > [ponds.water.net]$ gdb -k kernel.9 vmcore.9 > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.13 (i386-unknown-freebsd), > Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... > IdlePTD 1e4000 > current pcb at 1d5484 > panic: ifree: freeing free inode > #0 0xf0193d2b in boot () > (kgdb) where > #0 0xf0193d2b in boot () > #1 0xf0112b83 in panic () > #2 0xf0176f67 in ffs_vfree () > #3 0xf017c1f2 in ufs_inactive () > #4 0xf0128d65 in vrele () > #5 0xf0128cab in vput () > #6 0xf017f724 in ufs_remove () > #7 0xf012ad6e in unlink () > #8 0xf019c0a6 in syscall () > #9 0xf019156b in Xsyscall () > #10 0x2d9a in ?? () > #11 0x2b2a in ?? () > #12 0x2507 in ?? () > #13 0x19b9 in ?? () > #14 0x10d3 in ?? () > (kgdb) [ponds.water.net]$ > Script done on Fri Nov 15 07:15:14 1996 > > ------------------------------ > > From: Bill Fenner <fenner@parc.xerox.com> > Date: Fri, 15 Nov 1996 08:20:44 PST > Subject: Re: multicast - does NT 4.0 have it? Does Linux have it? > > In message <199611151516.QAA04115@gilberto.physik.rwth-aachen.de> you write: > >NT 4.0 > > No. Microsoft apparently has no plans for implementing this, and I have > it on good authority that they use some FreeBSD machines as their internal > multicast routers =) > > >Linux 2.x > > More recent versions, yes. I haven't tried them but have been assured that > they work well. > > Bill > > ------------------------------ > > From: Karl Denninger <karl@mcs.net> > Date: Fri, 15 Nov 1996 10:24:05 -0600 (CST) > Subject: Re: Sockets question... > > > > > > > Are you checking the return value from write() to make sure it actually > > > > > > thinks that N bytes were _written_? > > > > > > > > > > > > ... JG > > > > > > > > > > Uh, hang on a second... > > > > > > > > > > Are you saying that the behavior of a *TCP* connection is such that you > > > > > would expect to see a write(2) call to the socket come back with a short > > > > > count for any reason other than the remote having closed or some other > > > > > kind of transport error (ie: host unreachable, etc)? > > > > > > > > Yes: a nonblocking socket write will most definitely display this > > > > behaviour. > > > > > > Yes, but I did not set nonblocking mode on that socket. > > > > Did you receive a signal? That is known to cause similar behaviour on > > SunOS... > > Can't. Any signal on that process is a SERIOUS error; its a DBMS! We have > a generic "oh shit" trap for all signals set; it does not go off. > > > However, if you received a return value from write() equal to the number > > of bytes you supplied to write(), I would state that the problem is > > almost certainly elsewhere. > > > > ... JG > > Bingo. > > - -- > - -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service > | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal > > ------------------------------ > > From: Slavik Terletsky <ts@polynet.lviv.ua> > Date: Fri, 15 Nov 1996 18:25:40 +0200 > Subject: Re: Q: How to read hardware port ? *HELP* > > Andrew.Gordon@net-tel.co.uk wrote: > > > Does your port actually want byte-wide reads? There are other macros > > in /usr/include/machine/cpufunc.h for 16-bit or 32-bit reads. > no difference, the hardware just catches the trial of reading 0x443 port > > Say, if i am using port 0x443 and have no driver compiled for it - > can i read this port at all? (without driver!) > - -- > # Slavik Terletsky # University "Lvivska Poytechnica" # > # Network Administrator # mailto:ts@polynet.lviv.ua # > > ------------------------------ > > From: Hal Snyder <hal@vailsys.com> > Date: Fri, 15 Nov 1996 10:31:33 -0600 > Subject: Re: Programming technique for non-forking servers? > > Not exactly on subject, but does anyone know of a C++ class library for > network servers? Or is C++ still mainly for cooking application-level > code? > > I've looked as socket++, but it seems to have been abandoned, not sure > why. > > ------------------------------ > > From: Bruce Evans <bde@zeta.org.au> > Date: Sat, 16 Nov 1996 03:36:41 +1100 > Subject: Re: Programming technique for non-forking servers? > > >> mset and mclear would be implemented as lib functions because Intel does > >> have an atomic test and set. > > > >Yes it does: the "xchg" instruction. Load 1 into a register, then "xchg" > >the register with the memory location containing the lock. Look at the > >new value of the register to find out whether the lock was already > >locked. > > It also has many other instructions suitable for locking primitives: > > bt, btc, btr, bts (386 up) > sal (386 up) (standard trick) > cmpxchg (486 up) > xadd (486 up) > cmpxchg8b (Pentium (up?)) > > >It even works in a multiprocessor system. According to the > >Intel book: > > > If a memory operand is involved, the LOCK# signal is asserted for the > > duration of the exchange, regardless of the presence or absence of the > > LOCK prefix or of the value of the IOPL. > > I think the other instructions work in multiprocessor systems if they > have a `lock' prefix. The optional locking makes them more useful on > uniprocessors (actually, except for `sal' they are usually too slow to > be worth using except for locking. E.g., on Pentiums `bt' of a memory > variable takes 26 times as long as a simple instruction). > > Bruce > > ------------------------------ > > From: Javier Martin Rueda <jmrueda@diatel.upm.es> > Date: Fri, 15 Nov 1996 17:53:37 UTC+0100 > Subject: Contribution of Intel EtherExpress Pro/10 driver > > I've read the handbook on how to contribute new pieces of code to FreeBSD, > and I've done what is says, namely: > > 1. The driver has a BSD-style copyright. > > 2. I've uploaded it to ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming, with > filename if_ex-961115.tar.gz. > > 3. I'm sending a message to hackers@freebsd.org telling about this, so that > someone can commit/review/whatever the driver. > > I hope it is not too late to include this driver in FreeBSD 2.2, assuming you > find it appropriate enough. > > > ------------------------------ > > End of hackers-digest V1 #1641 > ****************************** > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.VMS.3.91-vms-b4-acs.961115120809.20504A-100000>