Subject: Linux-Development Digest #558 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Wed, 16 Mar 94 15:13:08 EST Linux-Development Digest #558, Volume #1 Wed, 16 Mar 94 15:13:08 EST Contents: Re: Problem with NET-2 and Winsock Gopher/HTTP clients? (Alan Cox) Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS] (Kevin Brown) Fork fails - what's the problem??!? (James D. Levine) Matrox drivers (John Wagner) information about mount's code needed (AUQUIER DENIS) Interesting use of "buffers" in new Linux 1.0 (+ late pl15) (Gene Choi) info about a sys-call: open (CAVELIER TRISTAN) Re: 127.x.x.x (was Re: UDP report card) (Heath I Hunnicutt) Re: Annoying interactive bug in nslookup? (Andreas Busse) Re: Interesting use of "buffers" in new Linux 1.0 (+ late pl15) (Kai Petzke) Re: DIP: tty: getc: I/O error (Matthias Urlichs) Re: Annoying interactive bug in nslookup? (Matthias Urlichs) Re: Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?) (Matthias Urlichs) ---------------------------------------------------------------------------- From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: Problem with NET-2 and Winsock Gopher/HTTP clients? Date: Tue, 15 Mar 1994 17:38:16 GMT In article <1994Mar15.150623.10604@selway.umt.edu> demeler@selway.umt.edu (Borries Demeler/Biophysics) writes: >I'm experiencing the same problem (winqvt/trumpet winsock dll, pl15) although >acceptable, since the problem can be avoided by scrolling somewhat slower. >When connecting to an Ultrix DEC I never experience the problem. My setup >is 486-50/8 MB Ram/20 MB Swap/SMC Elite/thin net. > If you are running anything earlier than real 1.0 then get 1.0 if you have telnet hangs. Only if they continue after that start to worry and file bug reports. Charles Hedrick and Linus pretty much butchered and rewrote the TCP layer between pl14n and 1.00 Alan ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS] Date: Tue, 8 Mar 1994 10:52:32 GMT In article jhenders@jonh.wimsey.com (John Henders) writes: >crfisher@nyx10.cs.du.edu (I am being repressed.) writes: [...] >> Although it may seem that every newsgroup in the c.o.l.* >> series actually have the word flame in them, they do not. I am so >> sick of the petty replies and responses I see here all the time. >> If you can not help someone then do not bother to even reply. > > So it helps people to encourage them to post to the wrong group, >does it? what about the people who are trying to use the group for the >reason it was created? Don't they count, in your worldview? There is no good answer to this problem. Part of the reason it exists to begin with is that comp.os.linux.development is badly named because a lot of people wanted to be "cute" and have the abbreviation come out c.o.l.d. (otherwise, they would have been more sensible and just named the group comp.os.linux.kernel, which *clearly* refers to linux kernel development, which is actually this group's charter). So now they, and a lot of other people, are paying for this original urge to be "cute". The answer to this is really quite simple, of course: create comp.os.linux.kernel, and move all kernel discussion there, while retaining comp.os.linux.development for what it appears it should be for: software development issues under Linux. Screw the newsgroup creation rules, there's *good reason* to do this (User Interface Issues 101), and rules shouldn't *ever* just blindly apply. Of course, that's not all of it. Much of the problem is that people who want answers will post to whatever newsgroup they find to be most convenient, instead of posting to whatever newsgroup is appropriate. However, the answer to this is not as much of a no-brainer as you might think. Many times, the question being asked can legitimately be asked in at least two newsgroups. Is an XFree configuration question more properly asked on comp.windows.x, comp.os.linux.help, comp.os.linux.admin, or what? How do you know going into it whether the question is Linux-specific or not? There are a *lot* of questions that are even harder to categorize. Another facet of the problem is that the traffic on comp.os.linux.help is *tremendous*. How likely do you think it is that someone who really knows what they're talking about will get to your question within a day if you ask it there? If it's an oft-asked question, many of the responses will be along the lines of "I'd like to know, too". At least on c.o.l.d., you're likely to be talking to people who really know what's going on. If *I* had a question that I wanted to be sure to get a good answer to, I'd email someone I knew was likely to have the answer. This is based on my experience with posting questions to newsgroups. Even for *appropriate* questions, I've had trouble getting answers to my questions on this newsgroup (c.o.l.d.). Case in point: up to at least 0.99.13, there seems to be a problem with stack integrity in the core dump file written as a result of a SIGABRT that originated in the process that was signalled (most often from abort()). I haven't characterized this with other signals, so don't offhand know if it's a general problem or one specific to SIGABRT (conjecture: it's a problem with any signal that causes core to be dumped). I asked *twice* about this problem here on c.o.l.d. and got *zero* responses, and this is *obviously* the right group to ask the question on. My questions were separated by a couple of months. Someone else managed to ask the same question. He likely got no responses as well. I have a workaround: kill the process from another process, i.e. have your abort() code do a fork() and kill the parent from the child. But this isn't implemented in the library, so anything using the library code will produce an almost useless core dump (experience says that the stack image is one of the most important pieces of debugging information contained in the core dump). Some of us, like myself, ask very few questions to the net. This isn't because we respect newsgroup charters, read the FAQ, or any other such thing (though those things happen to be true). It's because we happen to be capable enough to peruse the source to find the answers to our questions if we have to. This is how I managed to get screen to work on my system (a while back. I don't know if newer versions work out of the box). It took a few hours, but I didn't have to go to the newsgroup to find my answers (it would take a few days, at least, for me to figure out the core dump problem, which is why I haven't bothered). But folks, this is *not* a common capability, and you'll continue to be perturbed by the volume of "newbie" questions until you realize this!! This is particularly true if you don't even answer the *expert* questions, like the core dump question. In any case, if someone asks a question on the newsgroup that happens to be inappropriate, how long does it take to figure out that you can just skip it? A couple of seconds? If you're using a *real* newsreader, like trn, then you can often just skip the thread based on the subject line (I know this often doesn't work, however). You might spend 1 minute out of 30 or so skipping newbie questions, and that's on a *bad* day. Is it really worth it, then, to get all up in arms about an inappropriate posting? Not everyone has as much of a clue as you might. If they did, there would be a lot fewer questions (inappropriate or not) being asked. > John Henders - Wimsey Information Services > GAT/MU/AE d- -p+(--) c++++ l++ u++ t- m--- > e* s-/+ n-(?) h++ f+ g+ w+++ y* -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ Crossposted-To: comp.os.linux.help From: jdl@netcom.com (James D. Levine) Subject: Fork fails - what's the problem??!? Date: Wed, 16 Mar 1994 07:10:46 GMT I'm having the problem that I fork fails, usually after about 41 processes running (about 15 for root, the rest for my normal login). I thought for a long time that I had reached the max procs per unpriviledged user, so I went the route of bumping up the NR_TASKS in tasks.h, and rebuilt the kernel. Same problem. Over and over. Tonight fork failed at around 33 processes, so I don't really know what's up. This happened as it often does when I'm trying open a new xterm window and run some program in it (tonight that was elvis). Is it possible that I'm hitting some other resource limit, for example, the max # of ptys, when fork/exec tries to set up stdin/stdout for the new process? Any help in solving this problem would be very much appreciated. I've got the RAM, I've got the MIPS, but I ain't got the processes... ------------------------------ From: jwagner@mental.mitre.org (John Wagner) Subject: Matrox drivers Date: 15 Mar 1994 18:14:28 GMT Reply-To: jwagner@mental.mitre.org (John Wagner) so has anybody written a driver for the Matrox MGA-II cards for Xfree-86 yet?? I just got my new system with the 4meg version and would like to run linux on it, but I've heard that the drivers that come with the card do NOT support Xfree. I could still use my 386 to run linux, but the pentium sure would be nice :) -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + John Wagner My company doesn't even know what I do. :) + + jwagner@mitre.org empire isn't a game, it a life style! :) + + Bowling IS a sport, you try catching those balls! + + + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ From: essai@vub.ac.be (AUQUIER DENIS) Subject: information about mount's code needed Date: 16 Mar 1994 11:11:19 GMT Hello, Could you help me ? I try to understand some procedures in the kernel of linux. In particular about "sys_mount" (and "sys_unmout" :)) ) "do_mount" (and "do_unmount") These procedures are in the linux/fs/super.c file please help me. Thank you Denis. dauquier@ulb.ac.be ------------------------------ From: genie@fraud.berkeley.edu (Gene Choi) Subject: Interesting use of "buffers" in new Linux 1.0 (+ late pl15) Date: 16 Mar 1994 07:55:45 GMT I've noticed something interesting about Linux's use of memory lately. In specific, I'm referring to Linux's use of the buffer cache (reported by "free" command as the buffers category). I've noticed that starting with pseudo-late pl15 and 1.0, my buffers never seems to decrease below 3000. Is this what it's supposed to do? Wouldn't it make more sense to use this buffers to store real things in memory rather than start using swap to swap things out, while maintaining the cache? It's interesting that this change was made suddently amidst the pl15 series (where nothing was supposed to change except for bug fixes). Anyone else notice this? -Gene genie@xcf.berkeley.edu ------------------------------ From: tcavel@vub.ac.be (CAVELIER TRISTAN) Subject: info about a sys-call: open Date: 16 Mar 1994 11:41:35 GMT Hi, Could you help me ? I have to do a work concerning the sys-call, open (under linux) I have some problems to understand macro including assembler source precisely FD_CLR in "types.h" If you have any other information about sys-call open, send them to me. Thanks by advance. Tristan. tcavel@is1.vub.ac.be ------------------------------ From: heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt) Crossposted-To: comp.protocols.tcp-ip Subject: Re: 127.x.x.x (was Re: UDP report card) Date: 16 Mar 1994 08:32:27 GMT longyear@netcom.com (Alfred Longyear) writes: >It seems to me that the address 127.x.x.x is not special. What is special >is the loopback device. This assumption is wrong. 127 is specified in the RFCs as being a pseudo- network that includes the loopback address. The fact that it is specified in the RFCs as a special address pretty well contradicts your premise. >If you don't have a route for 127.x.x.x to the "lo" device, but have a default >route to an ethernet controller, for example, then requests to 127.0.0.1 will >go out the wire just as requests to any other IP address. Until a route is >created to the loopback device, the address 127.x.x.x is an unknown address >just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it >to a real ethernet address and subsequently the request would go out the >default route. The difference is that the IP layer can make the correct decision not to put anything to 127.* on any external interface. The idea that someone should need to configure their system to not violate the RFCs is ridiculous. There is a large responsibility on the part of the stack to not allow stupid things like sending 127.* out on the net. >I guess what I am saying is that the routing of frames is not a function >solely of the device's IP address, nor is it a function soley of the device >type. There is no magical "override" which says that "Oh, you have address >127.0.0.1. I won't bother to look it up. I know that this is the loopback >device and will simply put it there". You really should research these issues before posting. For starters, see the Hosts Requirements RFC. There is indeed something "magical" about any address on the 127 net. Whether you set your system up with 127.0.0.1 as a loopback or not is your problem. No matter what, you should never send packets to 127.anything out any interface, regardless of the routing table's (mis)configuration. ------------------------------ From: andy@resi.waldorf-gmbh.de (Andreas Busse) Subject: Re: Annoying interactive bug in nslookup? Date: 16 Mar 1994 08:27:12 GMT In article <1994Mar13.063213.26466@unlv.edu>, ftlofaro@unlv.edu (Frank Lofaro) writes: |> In article ggw@cds.duke.edu writes: |> >I've been using Linux (Slackware 1.1.2 0.99pl15 plus lots of sources) |> >on a Pentium for several weeks now. The system is quite stable and |> >is in regular use as our internet firewall/gateway machine. |> >(Seagate N12400 with Adaptec 1542c SCSI disk, Diamond Stealth video, |> >SMC Elite Combo ethernet card, zoom 14.4 modem, STB 4com, tb+) |> > |> >The only annoying thing that I can't find an easy answer/solution for |> >is that the nslookup program doesn't like the "enter" key at the end of |> >an inquiry (it takes two returns for it to recognize a query.) |> > |> >This has to be a known problem, but I can't find a mention in the NET HowTo |> >(or am I blind?) and looking at the code seems to imply that it may be a |> >problem in "flex"? |> > |> >Any comments would be appreciated. |> > |> >-- |> >Gregory G. "Wolfe" Woodbury @, but not speaking for Duke Univ. |> >System Admin Demographic Studies Box 90408 Durham NC 27708 |> >ggw@cds.duke.edu ggw@acpub.duke.edu ggw@wolves.durham.nc.us |> >"Myth is metaphor, and ritual is the enactment of myth." |> |> If you get weird problems with interactive programs compiled with flex, |> have flex get called with the -I (interactive) option. |> A better replacement for nslookup is DIG. It works fine on my linux 0.99.14 box, which we use as firewall machine too. Since I have DIG I haven't used nslookup anymore. Get it ! Andy =============================================================================== Waldorf Electronics GmbH | Phone: +49 (0)2636-80294 R&D Department | Fax: +49 (0)2636-80188 Neustrasse 9-12, 53498 Waldorf, Germany | email: andy@waldorf-gmbh.de =============================================================================== ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: Interesting use of "buffers" in new Linux 1.0 (+ late pl15) Date: 16 Mar 94 12:28:10 GMT genie@fraud.berkeley.edu (Gene Choi) writes: >I've noticed that starting with pseudo-late pl15 and 1.0, my buffers >never seems to decrease below 3000. Is this what it's supposed to do? ... >Anyone else notice this? Well, I noticed with some pl15 kernel, that the buffers would not go below half of the memory I had. This was real bad, when doing memory extensive work under X. With pre-1.0, it went away, again. Linux still seems to give more priority to buffers, than it used to be before, but this is ok. I think, it is a good idea to have more buffers than just a minimum. Otherwise, the kernel will read the same blocks (like currently used inodes and directories) again and again. Better do some swapping instead. Kai -- Kai Petzke Advertisement by Microsoft in a well-known German magazine: If you don't like our programmes, then make your own ones. However, they expect you to use Microsoft products for this -:) ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: DIP: tty: getc: I/O error Date: 15 Mar 1994 23:29:52 +0100 In comp.os.linux.development, article <2lqn56$tdq@watnews1.watson.ibm.com>, uri@watson.ibm.com writes: > > Please, please... Don't kill DIP with "-9", unless you're willing to > cope with your serial port left in some weird state, from which it's > rather difficult to recover. > You're both right. The combination of the kernel noting that nobody uses the port, and the subsequent reset of the port by getty, should, however, return the port to usability. If not, I'd regard that as a kernel bug. -- You would if you could but you can't so you won't. -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: Annoying interactive bug in nslookup? Date: 16 Mar 1994 13:40:38 +0100 In comp.os.linux.development, article <2lsmip$54m@nepahwin.cs.laurentian.ca>, grant@nepahwin.cs.laurentian.ca (Grant R. Guenther) writes: > > Well, it has certainly been around for a while (it was there in the pl10 > MCC kit that I ran last year ...) but I think most people use 'host'. Actually, I'm using "dig". It can do everything that nslookup can do, except zone transfers -- and these are better with named-xfer anyway. -- I'm not unemployed - I'm looking for the perfect job. -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?) Date: 16 Mar 1994 13:55:52 +0100 In comp.os.linux.development, article , eric@tantalus.nrl.navy.mil (Eric Youngdale) writes: > > >The _other_ bug fixed by the patch can bite you anytime. I think the fact > >that it doesn't seem to have seriously bitten anybody yet is nothing short of > >amazing. > > No, I think that kfree is atomic, and until you call some other > function that requests memory, you can technically still use the memory. > You're ignoring the fact that kmalloc is callable from an interrupt and may grab the memory almost immediately after you've freed it. > It is > wrong, of course, and I forwarded these patches to Linus, but it does not > surprise me in the least that no one has encountered this. Probably because the only user of kmalloc at interrupt time is networking, and most people simply don't talk to their CD-ROM and receive large network messages, which are most likely to cause a reuse of the block, at the same time. -- RISC assembly programmers do it 1073741824 times a second. -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************