From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 2 Apr 94 10:13:08 EST Subject: Linux-Development Digest #596 Linux-Development Digest #596, Volume #1 Sat, 2 Apr 94 10:13:08 EST Contents: Re: TCP/IP-Bug in 1.0 Kernel? (Rene COUGNENC) 1.0.0 zombies-bug? (Steve Tinney) Linux on the IBM TP 750[c] & 2.88 MB FD (Stacy D. Coil) Re: SLIP Server setup: Routing and interface ??? (Angelyn P. Williams) kernel level nfs server (Craig I. Hagan) Re: System headers. (Ken Pizzini) login on remote machine from kernel? (Alberto S Alonso) Re: IDE Performance Package (Byron Thomas Faber) Re: IPX compliancy? (Byron A Jeff) Re: Amiga FileSystem, Anyone? (Bill Hay) Re: IPX compliancy? (Steven Grevemeyer) Re: Linux on the IBM TP 750[c] & 2.88 MB FD (Paul Vojta) System headers. (Don Garrett) Re: mt commands that won't work (Zenon Fortuna) Re: TCP/IP-Bug in 1.0 Kernel? (khockenb@vaxc.stevens-tech.edu) ---------------------------------------------------------------------------- From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: 31 Mar 1994 15:38:27 GMT Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC) Ce brave Mike Horwath ecrit: > Rene COUGNENC (rene@renux.frmug.fr.net) wrote: > : The problem is not only whith ftp, but whith any program. The network works > Hmm... > Our configuration matches almost exactly. I have a small network at home (...) > I wonder where the fundamental differences are that cause problems. > (thinking hard...) I am actually testing all kernels from 1.0 to 1.0.5 to try to find which patch level introduced something making my 386/25 going into these problems. So far, everything is Ok for 1.0 to 1.0.2. I am actually running 1.0.3, it seems OK but I have to wait for at least 1 day of uptime to be sure. The problem (for me) I tracked in 1.0.5 (and 1.0.4 apparently), is that after about 12 hours, the system starts getting "input overruns" on the serial port, and every serial connections work really bad. UUCP or Zmodem stops whith 'too many errors', and on SLIP or PPP sessions, the connection seems to hang. Ping is ok but transfering more than 1Kbyte hangs. (Of course, the serial port is equiped whith a 16550, hardware flow-control works, I ran 1.0 during 10 days whithout any overrun error.) If, as it seems to be, the 'bug' has been introduced in patch4, I think we all should stop computers and do something else, there is really nothing related in this small patch... :-) -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ From: sjt@enlil.museum.upenn.edu (Steve Tinney) Subject: 1.0.0 zombies-bug? Date: 1 Apr 1994 17:55:35 GMT After 16 days of uneventful uptime, my Linux 1.0.0 kernel began to fail to terminate processes properly. Each processed that I closed, working within XFree 2.0, became a zombie. No other problems were apparent, and I carried on working for an hour or so until I was ready to restart. I shut down X, tried to logout, logout didn't terminate as usual. Flipped to another VT, logged in as root, all the processes associated with the ID I was trying to log off were now zombies. Tried to logout root, wouldn't terminate. Flipped to another VT, logged in as root again and did a 'shutdown -r now'. That did the trick: no funny messages, no filesystem corruption, return to normalcy. The only thing that I can think of that may have triggered this was that I did manage to fill up the root partitition to 100%. I deleted the contents of /tmp and /usr/tmp to free 15M or so of space. Sometime thereabouts, the zombies began rising. Anyone else seen anything similar? Steve ====================================================================== Steve Tinney Babylonian Section University Museum of the University of Pennsylvania sjt@enlil.museum.upenn.edu Phila, PA. 215-898-4047 ------------------------------ From: coil@osc.edu (Stacy D. Coil) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Linux on the IBM TP 750[c] & 2.88 MB FD Date: 1 Apr 1994 16:43:05 GMT Reply-To: coil@osc.edu A while back, there was a discussion of the TP750 and linux. A person said that linux can on run on the ThinkPad with a floppy driver modification. Could that person e-mail me exactly what they modified. When Linux probes for the floppy it finds an unknown type (6). I modified the routine find_base in the floppy driver to fool linux that type 6 is actually type 4. However this doesn't seem to work. I am trying to get the machine to boot off a two floppy system (a boot disk and a root disk). If anyone has any ideas, please let me know. Thankyou --Stacy coil@osc.edu Ohio Supercomputer Center When (hopefully) I get linux installed, I will post what I had to do with some patches to the kernel. ------------------------------ From: angelyn@fridge.jpl.nasa.gov (Angelyn P. Williams) Crossposted-To: comp.os.linux.admin,comp.os.linux.help Subject: Re: SLIP Server setup: Routing and interface ??? Date: 1 Apr 1994 21:03:57 GMT I am not alone!!! I was having this same problem late last night. Did you find a solution? (specifically, ping and traceroute work; telnet says 'Connection established' but never gives a login prompt) Eagerly awaiting your reply, A. ------------------------------ From: hagan@opine.cs.umass.edu (Craig I. Hagan) Subject: kernel level nfs server Date: 1 Apr 1994 21:40:33 GMT hi, i was reading the README from the nfs server for linux that comes with slackware, and i noticed this reference in it: " This is a user-level (no kernel mods) NFS server, unlike Der Mouse's which does add system calls to improve performance. This is an NFS client implementation, which would require changes to both kernel and system utilities. " I was wondering if someone could point me to the other nfs server, as i need something that has half decent performance (nothing against linux, but, this is the one stumbling block i have run into) -- craig ------------------------------ From: ken@chinook.halcyon.com (Ken Pizzini) Subject: Re: System headers. Date: 1 Apr 1994 23:31:56 GMT In article <2ni4o3$og3@aurora.engr.latech.edu>, Don Garrett wrote: > I have libc 4.5.19, and gcc 2.5.8. When I compile with -ansi, there >are a number of function prototypes that aren't visible to me. (fdopen >is what started this) > > Checking the system header, stdio.h, I find that fdopen, and a >number of others are blocked off (in this block): If you use -ansi, gcc defines __STRICT_ANSI__ under the assumption that you want to be sure that *any* system with an ANSI compiant C compiler/library will be able to run your code. Things like fdopen are _not_ in the ANSI standard. fdopen in particular is a POSIX.1 standard routine which allows you to glue file descriptors returned by open(), dup(), pipe(), etc. onto functions which want to use the ANSI stdio functions. If you want to generally use ANSI C (X3.159-1989) code with the additional library support of Posix, BSD, etc., just use gcc without either of the -traditional or -ansi options. --Ken Pizzini ------------------------------ From: a_alonso@iastate.edu (Alberto S Alonso) Subject: login on remote machine from kernel? Date: 1 Apr 94 06:38:45 GMT I was wondering if there is a way in which the kernel will log into a remote machine, and stablish a term conection everytime I reboot the machine. I'm also interested in the kernel watching that this conection is not lost, and in case it is to reconect again. I thought of two posibilities: 1.-Writing a script to log into the other machine automatically (which I don't know how to do). and execute a script in that machine that would make term run. By using this script from the /etc/rc it would work everytime that reboots, and then I don't know how to watch the connection. I guess by looking to /.term/connect ??? 2.-Modify the kernel source. In this case I guess it is quite complicated, so that the kernel handles all this and in that case I don't have to worry about anything else. But I don't really know that much about the kernel (even though I'm reading the KHG which helps a lot). Any ideas are really apreciated. Thanks in advance Alberto -- Alberto Alonso |The power is something no one will ever user name: a_alonso@iastate.edu |know what it really is, but still everyone Electrical Engineering. |wants to have it. That is the root of the |human nature. (Anonymous) ------------------------------ From: bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber) Subject: Re: IDE Performance Package Date: 1 Apr 1994 01:09:21 GMT davem@extro.ucc.su.OZ.AU (David Monro) writes: >FYI, my other drive is a "Conner Peripherals 170MB - CP30174E", which also >has 16 sector multimode capability - with that drive I get no speedup, in >terms of elapsed time to read data, but it consumes a lot less cpu (like >22% instead of 60%). Again, your mileage may vary. I have this same drive and my drive actually slows down as far as reads are concerned. However, the system time spent on reading has dropped from around 90% to around 15% or less. So it saves alot there. I'm not sure which is more useful.. I'm trying out the 16-sector mode now. Byron -- `Playing this disk at loud volume may permanently damage your speakers or other sound components.' -LFO b-faber@uiuc.edu ------------------------------ From: byron@cc.gatech.edu (Byron A Jeff) Subject: Re: IPX compliancy? Date: Sat, 2 Apr 1994 01:25:01 GMT In article <1994Mar29.194035.29185@uk.ac.swan.pyr>, Alan Cox wrote: >In article <1994Mar28.164356.29938@news.unomaha.edu> whitney@genisys.unomaha.edu (Cary Whitney) writes: >>Where can a person get information about this test IPX layer? >> >sunacm.swan.ac.uk:/pub/Linux/Networking/BETA > >I hope (Linus permitting) to have a better version in the 1.1 kernel Might I suggest that instead of helping Novell and their closed-minded attitutes that maybe is may be good to look at other alternatives: - Russ Nelson recently posted about a LanManager Server/Client for Linux. This package allows Linux to interoperate with LanManager Clients. This included the free DOS lanmanager client from Microsoft (of all people) and Workgroups for Windows. - Mike Durkin has a most excellent shareware NFS client for DOS. An evaluation copy can be found at polyslo.calpolu.edu:/pub/mdurkin/nfs 0.24 is the latest revision. Novell has no intention of helping us. Let us not bother to help them. BAJ --- Another random extraction from the mental bit stream of... Byron A. Jeff - PhD student operating in parallel! Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu ------------------------------ From: WiSH@dumain.demon.co.uk (Bill Hay) Subject: Re: Amiga FileSystem, Anyone? Reply-To: WiSH@dumain.demon.co.uk Date: Fri, 1 Apr 1994 21:23:07 +0000 In article kevin@frobozz.sccsi.com "Kevin Brown" writes: > > Sigh. I'd better quit while I'm not too far behind. :-) > > What I remember when dealing with DOS was that the call interfaces > expected filenames that followed the 8+3 convention. > > If the system call interfaces don't have any expectations on what > the filenames are supposed to look like (I don't have access to > any good references anymore, so I can't look it up), then I completely > agree with you (though I would then have to wonder exactly why > applications would break as badly as you seem to imply, notwithstanding > the fact that they would be optimized around an essentially > 12-character filename length limit). > > But if the system call interface itself has such a restriction, > then replacing the services wouldn't do much good: you'd still have > to adhere, in the interface, to the restriction. IIRC correctly DOS has two call interfaces for file control. FCBs and handles the FCB system (mostly used by older programs and those which need to create a volume label) does indeed have an 8.3 limitation. The handles (since v2 I think) has no inherent limitation being essentially a quick copy of the UNIX system. -- Bill Hay ------------------------------ From: grevemes@vtc.tacom.army.mil (Steven Grevemeyer) Subject: Re: IPX compliancy? Date: 1 Apr 1994 21:26:00 -0500 byron@cc.gatech.edu (Byron A Jeff) writes: : : Novell has no intention of helping us. Let us not bother to help them. : : BAJ : --- : Another random extraction from the mental bit stream of... : Byron A. Jeff - PhD student operating in parallel! : Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu Unfortunately, though this is a nice thought -- it is a bit shortsighted. Novell has a very large position within the desktop network world. Regardless of their technical pros/cons which I won't debate -- except to say I have a lot of equipment that doesn't run IPX and it is very painful -- any usage of Linux within the commercial market place is going to require IPX support. What is put up with (gateways, Internetwork routers, etc) to interface a Sun workstation with a Novell network will NOT be tolerated to connect a Linux box. -- Steven E. Grevemeyer Phone: (810)574-5106 FAX: -5008 US Army TACOM/Software Enginnering Division (AMSTA-OS) Vetronics Technology Center Warren, MI 48397-5000 Email: grevemes%vtc@tacom-emh1.army.mil ------------------------------ From: vojta@powdermilk.berkeley.edu (Paul Vojta) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Re: Linux on the IBM TP 750[c] & 2.88 MB FD Date: 2 Apr 1994 00:16:33 GMT In article <2nhiup$qf1@mane.cgrg.ohio-state.edu>, Stacy D. Coil wrote: >A while back, there was a discussion of the TP750 and linux. A person said >that linux can on run on the ThinkPad with a floppy driver modification. >Could that person e-mail me exactly what they modified. That person was me. Actually, I don't own a TP750; I own a desktop system (with AMI M/B and 2.88 Teac floppy drive). The modification works for my desktop system, and I assumed it would work on the TP750. Unfortunately, people tell me it doesn't. Instead you might try the earlier solution that was posted. Namely, run the BIOS setup program and tell the machine that it has a 1.44 floppy drive. I have redirected followups to comp.os.linux.help. --Paul Vojta, vojta@math.berkeley.edu ------------------------------ From: dgarrett@orbit.cs.engr.latech.edu (Don Garrett) Subject: System headers. Date: 1 Apr 1994 21:46:43 GMT [ Article crossposted from comp.os.linux.misc ] [ Author was Don Garrett ] [ Posted on 1 Apr 1994 21:46:02 GMT ] I have libc 4.5.19, and gcc 2.5.8. When I compile with -ansi, there are a number of function prototypes that aren't visible to me. (fdopen is what started this) Checking the system header, stdio.h, I find that fdopen, and a number of others are blocked off (in this block): > #if !defined(__STRICT_ANSI__) || defined(_POSIX_SOURCE) > extern FILE *fdopen __P((int, __const char *)); > extern int fileno __P((FILE*)); > extern FILE* popen __P((__const char*, __const char*)); > extern int pclose __P((FILE*)); > #endif Why is it defined this way? I keep running across other functions that are in the libs, and seem to work, but effectively not predefined. This was one of my absolute least favorite aspects of SunOS. I don't think I should be defining _POSIX_SOURCE by hand. Some others like 'getdtablesize' are blocked off behind other #defines like __USE_BSD. How should I go about getting access to these functions legitimately? Especially, how can I do it so that my code is portable? (I HATE #ifdef's done for portability). Seems funny, but I almost always find the I have more #ifdef's related to which headers to include than anything really different between systems. -- Don Garrett Louisiana Tech dgarrett@engr.latech.edu University http://info.latech.edu/~dgarrett/ -- Don Garrett Louisiana Tech dgarrett@engr.latech.edu University http://info.latech.edu/~dgarrett/ ------------------------------ From: zenon@resonex.com (Zenon Fortuna) Subject: Re: mt commands that won't work Date: Fri, 1 Apr 1994 12:30:18 GMT In article <1994Mar30.214944.456@ancient.trillium.se> wolle@ancient.trillium.se (Wolfgang Feldmann) writes: >I wonder if it's supposed to be so that mt commands others than erase, >reten, rewind or weof won't work. I'm using linux 1.0, the newest >ftape and slackware's mt. >I'm longing for beeing able to back up more than one tar file to a tape. > >Wolfgang > 1. YOU ARE ABLE to backup more than one tar file (as I am doing it all the time) because the "mt fsf n" works, so you can position yourself after arbitrary file. Of course to use just # mt fsf 1 (or similar) your /dev/tape must be identical to /dev/nrmt0 (e.g. a hard- or symbolic link). 2. There is a bug, however, in the "mt(1)", which does not allow mt to write to the tape (e.g. "mt eof" or "mt weof" won't work). I hope the mt(1) will be corrected in the next release. For time being you can correct it for yourself: I quote now the posting of Eyal Lebedinsky: ... The source is part of 'cpio'. I went into /var/adm/packages and did a 'grep ^bin/mt' (simple when you know where to look). The sources (for the slackware distrib) are on ftp.cdrom.com in the /pub/linux/slackware_sources directory, organized by disk name and package. Now I have the missing man page. For the original problem, the reason it will not write is because mt explicitly opens the tape in read only mode. For myself I changed (around line 220) the O_RDONLY to O_RDWR and did a 'make mt'. ... So make yourself a new mt(1), which would work without write restrictions. zenon@resonex.com ------------------------------ From: khockenb@vaxc.stevens-tech.edu Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: Fri, 1 Apr 1994 18:06:42 GMT In article <2nfbfj$56@renux.frmug.fr.net>, rene@renux.frmug.fr.net (Rene COUGNENC) writes: > Ce brave Rene COUGNENC ecrit: > >> I am actually testing all kernels from 1.0 to 1.0.5 to try to find which >> patch level introduced something making my 386/25 going into these problems. >> So far, everything is Ok for 1.0 to 1.0.2. > >> I am actually running 1.0.3, it seems OK but I have to wait for at least >> 1 day of uptime to be sure. > > After 11 hours uptime, 1.0.3 started missing most received characters > on the serial port. > > So the problem seems to be in patch3, and related to something about > interrupts... I've noticed that after about 4 days of uptime, my 1.0.4 system seems to get "sluggish", and things seem to be slowing down (the spinning globe in Mosaic, window redraws, etc.) Rebooting cleared the problem, but I'd still like to know what's causing it :-( 486dx2/66, 12Megs ram, 1.0.4 kernel. ------------------------------ ** 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 ******************************