Subject: Linux-Development Digest #545 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Sun, 13 Mar 94 03:13:08 EST Linux-Development Digest #545, Volume #1 Sun, 13 Mar 94 03:13:08 EST Contents: setserial & pcmcia card Take a look at this netstat, please... (Paul Smith) Re: select (Matthias Urlichs) Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?) (Matthias Urlichs) Re: Modula-3 compiler (Michel Dagenais) Re: telnet uid length <=8?? (John F. Haugh II) Re: YP or NIS for linux? (John F. Haugh II) Re: VT's must all use the same font [was Re: Loaded fonts discarded aft] (Andries Brouwer) Re: Amiga File System, once again (Hamish Macdonald) Re: A truely non-debugging Kernel? (John F. Haugh II) Re: finger access requirements (John F. Haugh II) Re: AMD 486DX problem (with Linux?) (Charles T Wilson -- Personal Account) ---------------------------------------------------------------------------- From: alan@qsss01.gs.com () Subject: setserial & pcmcia card Reply-To: alan@qsss01.gs.com Date: Fri, 11 Mar 1994 03:37:14 GMT i posted this article to c.o.l.help a while back, but did not hear anything. perhaps there is a serial driver expert here who can help me out. i have a notebook computer running linux .99pl14w, with a mhz 14400 pcmcia faxcard. if I boot dos first after powering on the system, i am able to configure the fax card as either com3 or com4, and then reboot linux and have it recognize the faxcard as either ttys2 or ttys3. the notebook also has a mouse connected to com1 (the external device) and a trackball (an internal device). the problem that I have is that if I configure the faxcard as COM3 (ttys2) it gets disabled when i start X and enable the mouse on COM1 (ttys0), or if I configure the faxcard as COM4 (ttys3) the same happens when I start X and enable the built in trackball. i have tried various combinations of setserial, and even searched through to see if there is anything in any of the FAQ's, but I could not uncover anything that would allow me to overcome this conflict. is there a way to do this ? or am i hitting a serial driver limitation ? Alan ========== _/ Alan M Buckwalter _/ _/ _/ +1 212 902 5586 _/ _/ _/ _/ _/ alan@qsss08.eq.gs.com _/ _/ _/ ------------------------------ From: psmith@iies.ecn.purdue.edu (Paul Smith) Subject: Take a look at this netstat, please... Date: Thu, 10 Mar 1994 20:07:07 GMT Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (State) tcp 148 0 eucd.adpc.purdue.:1130 TSX-11.MIT.ED:ftp-data CLOSE_WAIT off (0.00/0) 0 tcp 716 0 eucd.adpc.purdue.:1234 wcarchive.cdr:ftp-data CLOSE_WAIT off (0.00/0) 0 I did this netstat at ~3:00 PM (my time). I had performed these two ftp's over *4* hours earlier. Why haven't these closed down? Also, my system seems to have lost about on hour on the system clock... why? Please see also my other posts/replies related to problems with networking and gopher/gn servers. Tx, -Paul ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: select Date: 12 Mar 1994 21:08:42 +0100 In comp.os.linux.development, article , evansmp@mb48026.aston.ac.uk (Mark Evans) writes: > Matthias Urlichs (urlichs@smurf.noris.de) wrote: > : In comp.os.linux.development, article , > : fgm@doc.ic.ac.uk (Frank McCabe) writes: > : > I have come across an apparent problem with the select system call. > : > > : Wrong. You've come across a bug in your program. > > This is the second example I have spotted of someone doing this.... > At least. I assume the zero'th example is the instance in the rpc library, which would fire off nonstop requests to the portmapper if it dares to time out the first time. :-( > : Yes. Read the documentation. You're reusing your timeout values. > : The first time you call select(), it zeroes the variable because no more > > I thought it actually set the value to the time remaining of the original > timout. Thus it zeros if the select ends due to a timeount. But it may > not end up as zero if it is due to any fd's being ready. > Of course, but... > It could be that you will get unpridictable behaviour on timeout, before > getting to the state of no timout. > ... which could of course also happen. Hit me for fitting my explanation to what most likely did happen, instead of mentioning anything that might possibly explain the observed effect. :-/ > : This is mentioned in both the SunOS and Linux manpages for select(). > > What happens is that quite a few versions of select(), including on Suns, > never write to the timeout. Which is also mentioned in the SunOS manpage. ;-) -- Message will arrive in the mail. Destroy, before the FBI sees it. -- 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: Possibly-fatal ISOFS bug +PATCH (Re: A truly non-debugging Kernel?) Date: 12 Mar 1994 21:27:08 +0100 In comp.os.linux.development, article , doug@midget.towson.edu (Doug McNaught) writes: > > >Geez! The kernel has _so much_ debugging code (sanity checks, etc) that > >I wonder how much smaller it could be. It seems most kernel developers > >have never heard of #ifdef... Just a thought :-) > You might like sanity checks if you see the two fatal bugs in fs/isofs/inode.c I found yesterday. The appended patch fixes them. > Well, I'd rather give up some memory and have something that panics > and shuts itself down rather than blindly hosing my filesystems and/or > hardware... I *like* sanity checks. A lot. Most sanity checks don't add much code and are not in any time-critical paths. The rest might well be #ifdef'd. For instance, while tracing kernel malloc code and zeroing out the allocated buffers to prevent overrun and reuse is a very nice and debuggingly-helpful idea, it also eats up a lot of CPU time. So it's conditional. (Assuming that Linus someday puts the kmalloc-debugging code back into the kernel.) NB: The whole idea of kmalloc()ing the data space for an inode should be ripped out of the isofs code. Returning a random error message on random file system requests, just because memory is low and the files happen to be on a CD-ROM, is not my idea of reliability. The patch affixed below only prevents you from simply crashing instead of getting the error message in a low-mem situation. Better, but not optimal. 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. diff -rub /usr/src/linux.netbsd/fs/isofs/inode.c ./fs/isofs/inode.c --- /usr/src/linux.netbsd/fs/isofs/inode.c Thu Feb 24 18:47:08 1994 +++ ./fs/isofs/inode.c Sat Mar 12 04:00:56 1994 @@ -344,18 +344,23 @@ if ((inode->i_ino & (bufsize - 1)) + *pnt > bufsize){ cpnt = kmalloc(1 << ISOFS_BLOCK_BITS, GFP_KERNEL); + if(cpnt == NULL) { + printk(KERN_INFO "NoMem for ISOFS inode %d\n",inode->i_ino); + brelse(bh); + goto fail; + } memcpy(cpnt, bh->b_data, bufsize); brelse(bh); if (!(bh = bread(inode->i_sb->s_dev,++block, bufsize))) { kfree_s (cpnt, 1 << ISOFS_BLOCK_BITS); printk("unable to read i-node block"); goto fail; - }; + } memcpy((char *)cpnt + bufsize, bh->b_data, bufsize); pnt = ((unsigned char *) cpnt + (inode->i_ino & (bufsize - 1))); raw_inode = ((struct iso_directory_record *) pnt); - }; + } inode->i_mode = S_IRUGO; /* Everybody gets to read the file. */ inode->i_nlink = 1; @@ -463,11 +468,6 @@ #endif brelse(bh); - if (cpnt) { - kfree_s (cpnt, 1 << ISOFS_BLOCK_BITS); - cpnt = NULL; - }; - inode->i_op = NULL; if (inode->i_sb->u.isofs_sb.s_cruft != 'y' && isonum_723 (raw_inode->volume_sequence_number) != 1) { @@ -486,6 +486,11 @@ else if (S_ISFIFO(inode->i_mode)) init_fifo(inode); } + if (cpnt) { + kfree_s (cpnt, 1 << ISOFS_BLOCK_BITS); + cpnt = NULL; + } + return; fail: /* With a data error we return this information */ -- I, I am not a Marxist. -- Karl Marx (1818-1883) -- 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: dagenais@froh.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Modula-3 compiler Date: Sat, 12 Mar 1994 17:09:14 GMT You can ftp Modula-3 for Linux from gatekeeper.dec.com. Look in "pub/DEC/Modula-3/release-3.1". The binaries are available on ftp.vlsi.polymtl.ca:lude/modula3-3.1/run/linux.tar.Z. However, 3.1 was the first release of the new native compiler and a few things need to be fixed. The 3.2 release should be out shortly at which time i will try to get the full distribution working, with shared libraries, and some install instructions. A that point i will announce it on c.o.l.a.. -- ===================================================================== Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 ===================================================================== ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: telnet uid length <=8?? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Sat, 12 Mar 1994 19:50:26 GMT In article <2lgrgh$buo@nic.ott.hookup.net> root@borg.ott.ca (Sys admin) writes: >Only people with user id's of 8 chars or less can use my >telnet port. they can log onto my linux system through the >serial port, but not over the internet through telnet. >(or even locally for that matter.. if they have 9 char or > >userids!!!!) The only limitation I know of in Shadow is 32 characters (see lmain.c) or an entire password file line <= BUFSIZ in length (see pwent.c). If you're having a problem, make sure you have the right version of software. If you're just asking a question the answer should be "there is no 8 character limitation". -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: YP or NIS for linux? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Sat, 12 Mar 1994 19:53:39 GMT In article <2lpu08$983@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes: >Alternately, since the original question was what to do if you have a >too-big passwd file, you replace the linear lookup in the passwd file >with gdbm access and forget about yp. That was my point exactly. The current NYS package, which is designed ostensibly to replace all of the getpw*() and getsp*() functions does not support any of the DBM file formats. I intend to get a copy of NYS and put in NDBM support whenever I get Shadow out the door this spring. (GDBM will do NDBM, so I view NDBM as a more portable interface.) >Sometimes, the simple but reliable solution doesn't scale well enough to be >useable. I have spoken with people who use DBM files to support /etc/passwd files with upward of 30,000 users. I'm not aware of any scalability problems with DBM files. I am aware of problems pushing YP maps that are that size. -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: aeb@cwi.nl (Andries Brouwer) Subject: Re: VT's must all use the same font [was Re: Loaded fonts discarded aft] Date: Sat, 12 Mar 1994 13:24:45 GMT joel@rac3.wam.umd.edu (Joel M. Hoffman) writes: ... >So I NEED different fonts on different VT's. ... >Who made this decision? I understand the code was rewritten (which is >probably a good thing, because I'm a Pascal programmer, and don't >really know C....), but why was the behavior changed? You asked this question before, and I answered it. Now you ask it again, and the answer will be the same. Several implementations of font loading code were floating around, and I liked Crosser's version best, polished it a little and proposed including it in the standard kernel, which Linus did. [So, no behaviour was changed, but a choice was made.] Now should there be a separate font for each VT? If everyone wants it, then yes. If many people want it, then it should at least be a configuration option. But there is a danger of pollution: there are many potentially nice things, and at configuration time one could easily have fifty keyboard/console-related questions. Separate fonts for each VT take a lot of memory, and are used by relatively few Linux users, so cannot be the default, I think. How inconvenient is it not to have these separate fonts? I also use several fonts, but maybe not as much as you do, and for me the following construction is quite satisfactory: % loadkeys string F1 = "chvt 1; setfont -16 font1 " string F2 = "chvt 2; setfont -16 font2 " string F3 = "chvt 3; setfont -16 font3 " % Now pressing a function key (while at the shell prompt) brings me to the right VT and sets the right font. (But if not at a shell prompt I have to make a detour: Alt-F6 to find a shell, followed by F2, say, to get to the right VT with the right font.) Thus, at the cost of at most one additional keystroke when changing VTs, I save many Kb of memory. Of course this is a kludge, but my vision of future development is not one with a VT for English, one for Hebrew and one for Russian, but Unicode on all VTs, so that you can mix all alphabets everywhere. After 1.0. Andries ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Subject: Re: Amiga File System, once again Date: 10 Mar 1994 21:28:38 GMT >>>>> On 10 Mar 1994 05:06:54 EST, >>>>> In message <2lmrfu$db9@wizard.uark.edu>, >>>>> dfaulkne@comp..uark.edu (Donald Faulkner) wrote: Donald> So how about it... are there plans for an amiga file system Donald> for Amiga Linux? There is an "Amiga Fast File System" filesystem for Linux/68k. It cannot write to an Amiga FFS, and I have not tested it on floppies yet. This filesystem was taken from the work of someone (I'm afraid I can't remember who) who did this work for Linux/PC (he wanted to read an old Amiga SCSI hard disk from his PC, I believe). The only modifications I've made to it were to conditionalize the longword swapping that had to be done for the i386. I regularly use this filesystem to copy files I've downloaded (using AmigaDOS) to my Linux/68k hard disk partitions. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: A truely non-debugging Kernel? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Sat, 12 Mar 1994 19:56:24 GMT In article doug@midget.towson.edu (Doug McNaught) writes: >In article <2loo9h$fo8@aurora.engr.latech.edu> ramos@engr.latech.edu (Alex Ramos) writes: > >>Geez! The kernel has _so much_ debugging code (sanity checks, etc) that >>I wonder how much smaller it could be. It seems most kernel developers >>have never heard of #ifdef... Just a thought :-) > > Well, I'd rather give up some memory and have something that panics >and shuts itself down rather than blindly hosing my filesystems and/or >hardware... I *like* sanity checks. A lot. That's all or nothing thinking -- ship the kernel with #ifdef DEBUG and after a few weeks when you are happy, recompile with -UDEBUG. -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: finger access requirements Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Sat, 12 Mar 1994 20:26:15 GMT For your amusement -- In article richard.soderberg@mic.ki.se writes: >Hello! >In order to be readable by fingerd .plan and .project has to reside in a >directory (my home) that is executable by all, right (?). >This doesn't seem very attractive to me. Is there a workaround for this that >will allow people to see the .plan and .project files without compromomising >security? Is it possible to put these files somewhere else? Any alternative >fingerd? >TIA >/RS -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: ctwilson@rock.concert.net (Charles T Wilson -- Personal Account) Subject: Re: AMD 486DX problem (with Linux?) Date: 13 Mar 1994 03:36:35 GMT In article <2lknvi$b5f@serra.unipi.it>, Romano Giannetti wrote: >In comp.os.linux.development, Charles T Wilson -- Personal Account (ctwilson@rock.concert.net) wrote: >> My apologies if it's bad netiquitte to post a file like this in >> this newsgroup, but I was glancing at this thread, and thought >> you might be interested in this program, which tells you a lot >> about how your processor/compiler handles lots of things, floating >> point representation among them. It's kinda old, but I think it's >> still valid...enjoy. > >But _before_ comment out the following lines around line#450: > > while (size!=0) { > while (malloc(size)!=(char *)NULL) > total+=(size/2); > size/=2; > } > >that drive my Linux box to a quiet dead :-) after a lot of swapping. >BTW: is this normal? I cannot afford test it on another Unix. My conf >is Linux pre-1.0, 8M ram, 16M swap. The box don't crash nor panic, >only get more and more slow if I don't ctrl-c the program. Well, my apologies again...I hadn't run this in several kernel versions, where it worked fine. At this point in the code it's trying to see how much mallocable space there is. It ran *much* faster on older kernels, but seems to really bog down on my pl14 kernel...sorry if I caused problems. For the record, I've never known it to do this on any other unix, and I've run it on quite a few. Sorry if I caused anyone else any worries.. -- /-----------------------------------------------------------------------\ | Tom Wilson | "I can't complain, but sometimes | | ctwilson@rock.concert.net | I still do." | | | -Joe Walsh | ------------------------------ ** 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 ******************************