Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA12552; Mon, 18 Dec 95 12:23:12 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA28869; Mon, 18 Dec 95 12:23:11 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id MAA15479 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Mon, 18 Dec 1995 12:17:08 -0500 Message-Id: <199512181717.MAA15479@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Date: Mon, 18 Dec 95 12:17:04 EST Subject: Linux-Development-System Digest #132 Linux-Development-System Digest #132, Volume #2 Mon, 18 Dec 95 12:17:04 EST Contents: Re: Linux Security - C2 and beyond (Molnar Ingo) Re: Does Linux support (or will) RAID 5 drives and/or Hot plugged drives ? (Mats Andtbacka) Re: Kernel protection against device drivers! (Simon Karpen) Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? (Alain FAUCONNET) keystroke interpretation with termcap (A. Rohde) "swap=" and "buff=" for LILO (Jeff Voskamp) 'make' fails with 1.3.47? (sbeer@ibm.net) Driver for SMC91C92 Ethernet chip (Suzuki Mitsugu) Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? (Bob Lorenzini) So how goes the 8086 port? (Arcadio Alivio Sincero) Re: Quotas over NFS? (Colm Buckley) Re: GCC 2.7.2 and kernel 1.3.46 trouble (Horst von Brand) Re: Possible bug in .3.43 and .3.45 HELP: Looking for gcc-2.6.3/ELF sources (j.j.vanderheijden@mail.student.utwente.nl) Re: AHHHH (Colten Edwards) Re: Unusual disk activity under 1.3.45... (Jason Mcmullan) ---------------------------------------------------------------------------- From: mingo@teto.sch.bme.hu (Molnar Ingo) Subject: Re: Linux Security - C2 and beyond Date: 17 Dec 1995 21:16:51 GMT Joe Buck (jbuck@synopsys.com) wrote: : Similarly, many programs that are distributed in source form are written : sloppily, in a way that is difficult to understand; there's plenty of room : for flaws or nasties. Eric Allman (sendmail's author) gave the other : sysadmins source to sendmail, and it had a back door that let him become : root on their machines. Do you KNOW that every svgalib program you run is : free of such back doors? They run setuid root; have you checked the : source code? Huh? Once i have access to the console, i really do not need to run an svgalib program to get root ... :) (or do you play svgadoom thru the net? :) ------------------------------ From: mandtbac@news.abo.fi (Mats Andtbacka) Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc Subject: Re: Does Linux support (or will) RAID 5 drives and/or Hot plugged drives ? Date: 18 Dec 1995 06:50:09 GMT Reply-To: mandtbac@abo.fi Bart Peirens, in <4b1fv7$31o@ping1.ping.be>: >dmtech@magi.com (Andrew Mileski) wrote: [...] >>There is a Linux driver for Raid-1 and Raid-2. *ANY* kind of disks >>work (supposedly). >OK, It's good project, but at this state: >no raid5, >no recovery tools !! >no hot swap etc.. IMNSHO those things are far better done in hardware anyway - hot swap, for example, would be tough to achieve without at least a specialized case and connectors to facilitate it; trying to do it with your standard average PC-case internal SCSI (or even >shudder< EIDE) chain would be plain silly. The way to do good RAID-5 is to put it in a case of its own with the disks controlled by a dedicated host adapter of some sort, and then have that thing talk to the host computer over SCSI-3 or similar; the OS would see it as just one big fast SCSI disk. There's absolutely no good reason to handle such things in system software. - M. "and if there is, you can run NT" A. -- " ... got to contaminate to alleviate this loneliness i now know the depths i reach are limitless... " -- nin ------------------------------ From: karpens@sauron.ncssm.edu (Simon Karpen) Subject: Re: Kernel protection against device drivers! Date: Sun, 17 Dec 1995 20:29:44 GMT In article <4ammqh$aj0@news.siemens.at> mingo@news.siemens.co.at (Ingo Molnar) writes: Joe Nardone (joe@access4.digex.net) wrote: : Aurel Balmosan (aurel@xylo.owl.de) wrote: : : Is there a project which developes a kernel protection against devices drivers. : Seriously, how would you implement such a thing? It would be : very difficult to impose those kinds of restrictions on device : drivers, since they must run at a kernel-level and have that : open access to the system and its hardware. That's kind of : the point. Like in OS/2 or in WinNT, using the other rings too, not only ring 0 and 3. dont know if it makes sense, since there are no "heaps of third party device drivers" in Linux Um... OS/2 has no kernel protection from at least some types of device driver. Alpha/beta versions of the ext2 driver will cause a total system lockup under really heavy load. In fact, the IFS code is still 16 bit. I use Linux primarily, but sometimes need DOS/Win apps and am not going to put up with that heap of garbage. Linux actually behaves much better than OS/2 with a development device driver. -- Simon Karpen visit my homepage at karpens@ncssm-server.ncssm.edu http://www.ncssm.edu/~karpens root@ncssm-server.ncssm.edu sysadmin for NCSSM's workstation network karpens@opus.ncssm.edu ------------------------------ From: af@biomath.jussieu.fr (Alain FAUCONNET) Subject: Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? Date: 18 Dec 95 10:18:00 GMT On Thu, 14 Dec 1995 14:28:00 +0100 (GMT+0100), I wrote: > > I've been bothered for a long time by "frame with bad fcs" and "frame > > tossed, reason = 4" messages on my TI Travelmate 4000M when there is > > high incoming traffic on the 38.4 kb/s PPP link (causing poor overall > > transfer rates because of retries). After triple-checking PPP and > > modem configuration, I have put a RS-232 testing box between the PC > > and the modem, and saw that the RTS and CTS lines never seemed to > > show any transition. The tty modes do include 'crtscts', and so does > > the PPP config file. The modem is configured for hardware flow control > > and the cable is OK. > > I have recompiled drivers/char/serial.c with SERIAL_DEBUG_FLOW and > > SERIAL_DEBUG_THROTTLE on and saw no sign of those routines being > > called during an incoming ftp transfer, although the messages > > mentioned above did appear. Could it be the tty upper layers or the > > PPP code not calling them on input buffer overflow ? Probably not. I > > tried doing transfers with kermit instead of PPP. Same symptoms: > > retried packets, bad CRCs and "cua0: input overrun" messages. *But* > > when I abort the transfer by ^C, I *do* see CTS going low (and the > > kernel debug messages due to the settings mentioned above) because > > the buffer fills up. This mechanism does work, then. > > My conclusion is: the driver doesn't pick up characters fast enough > > from the UART and the chip gives input overrun status. Strange. The > > chip on this machine supposedly is the best one (16550A) and according > > to the driver sources, the only one which has an useable internal > > character FIFO. On an otherwise idle 486 DX4/100, I would expect the > > driver to handle an incoming data flow at 38.4 kb/s. I'm baffled. "Theodore Ts'o" replied: >Well, at home, I'm using a 386/40 running at 38.4, talking to a 28.8 >modem doing PPP, and I'm not having any problems at all. So yes, a 486 >DX4/100 certainly will have the computing oomph to keep up with things. >If you're getting "cua0: input overrun" messages, the problem is not >with the RTS/CTS flow control --- in the first place, PPP doesn't need >any flow control mechanism because as soon as an incoming packet comes >in, memory is allocated and shoved to the network layer, just as it >would be an ethernet card. Any sort of flow control vis-a-vis TCP >connections is done at the TCP layer. In the second place, if there was >some sort of bottleneck at that level --- suppose that the kernel >lowered CTS, but characters kept on coming in --- in the N_TTY line >discpline layer, characters would just be silently dropped. >The fact that you're getting the "cua0: input overrun" message does mean >that for whatever reason, by the time the serial driver was able to get >control after a serial interrupt and try to read characters from the >UART, the UART was forced to drop some characters on the floor. >This can be caused by trying to run too many serial ports at 115200 on a >slow computer, but that's clearly not your problem. Other potential >causes is that some other device driver (the IDE disk driver is a really >bad this way) keeps interrupts off too long, and by the time the serial >driver can get control, it's too late. If you can correlate the input >overrun messages to disk activity, then you should take a look at man >page for the "hdparm" program. In particular, take a look the "-u" >option, which is documented for solving the input overrun message, but >which causes SEVERE DISK CORRUPTION for some IDE interfaces. Read the >man page, including the part of backing up your hard disk first, and >decide for yourself if you're willing to risk it. [rest deleted] ``hparm -u 1 /dev/hda'' did it for me. And yes, I did a full backup before. I have been running like this since then, forcing a fsck at every boot, nothing nasty happened so far and all signs of serial overruns have disappeared :-). I now happily get over 3 kb/s over an incoming ftp on my V34 modem PPP link. I realize that this might not apply to every configuration, so mine is: Texas Instruments Travelmate TM4000M DX4/100 500Mb internal Toshiba IDE hard disk 20Mb RAM Linux 1.2.13 I might add this to my Mini-HOWTO ftp.biomath.jussieu.fr:/pub/linux/TM4000M-mini-HOWTO.txt.Z after some more testing... Many thanks to all who provided useful information, and especially to: "Theodore Ts'o" ciro@stud.unipg.it (Ciro Cattuto) garcia@pc5.ece.cmu.edu (Brad Garcia) (and others who posted followups here) _Alain_ -- Alain FAUCONNET Ingenieur systeme - System Manager AP-HP/SIM Public Health 91 bld de l'Hopital 75013 PARIS FRANCE Medical Computing Research Labs Mail: af@biomath.jussieu.fr Tel: (+33) 1-40-77-96-19 Fax: (+33) 1-45-86-80-68 I've RTFMed. It says: "Refer to your system administrator" But... I *am* the system administrator :-] ------------------------------ From: exp109@modcomp.physik.uni-kiel.de (A. Rohde) Subject: keystroke interpretation with termcap Date: 18 Dec 1995 10:46:08 GMT Reply-To: rohde@physik.uni-kiel.de Hi, I'm hacking on keystroke interpretation for an editor. I use the GNU termcap library (and I have a good reason not to use ncurses). I have the documentation, but there's no example given. The call char * tgetstr("k1", *pointer_to_whereever) returns a pointer to the string. The contents of this string is the escape-sequence which is emitted, when I press F1 (if the termcap *really* represents the keyboard mapping). I read characters with getch(). What I get after 5 calls is: \033 [ 1 1 ~ My problem is, that I have to know, which character is the end of the escape sequence. If I type: 'F1 a b c d e' for example, I get \033 [ 1 1 ~ a b c d e. Where is the end of the escap sequence? Backspace emits usually Control-H or (octal) \177 = (decimal) 127. Is there any piece of electronic/virtual paper available? How do I enable the 'Application cursor key' mode (curses?)? When I press the UpArrow, xterm sends \033 [ A in the normal mode. A couple of applications activate the 'Application cursor key' mode and xterm sends \033 O A instead. Axel ------------------------------ From: jeff@bifrost.voskamp.waterloo.on.ca (Jeff Voskamp) Subject: "swap=" and "buff=" for LILO Date: Thu, 14 Dec 1995 20:50:54 GMT I know that they have to do with the "kswap" patches that have been folded into the kernel. I've found the default values, but I don't want to have to read more kernel source to get what they all mean. What do those strings of integers mean, and how do they affect the operation of my machine? Jeff Voskamp ------------------------------ From: sbeer@ibm.net Subject: 'make' fails with 1.3.47? Date: 15 Dec 1995 15:34:17 GMT Reply-To: sbeer@ibm.net I loaded 1.3.47 sources, all libc, ld.so, libg++, binutils, gcc are ELF, latest and greatest. Slack/ELF (Aug 95) distrib as base point. With a.out 1.2.8 kernel, kernel compiles fine (I even fixed host_byte problem mentioned here). New 1.3.47 zImage runs OK, X (on Mach64), JAVA JDK run fine, Netscape v2b3 OK with JAVA applets (with minor glitch but good enough for our JAVA applet development work). Problem: When the 1.3.47 kernel is running, 'make' has a problem finding rules in Makefile (e.g. for 'clean', 'mrproper', etc.), per -d switch (or so it seems to this relative linux newbie). make version is 3.73. Same make with 1.2.8 a.out kernel running (but all else same) runs fine. Tried for testing linux-1.2.9 sources and Makefile, same problem, i.e. it seems to relate to the make 3.73 and 1.2.47 running-kernel combination. BTW, when make is force-fed the top Makefile (-f switch) it gets stuck deeper down looking for other rules (you can tell I'm not a 'make' expert). Has anyone seen anything like this? Am I doing/missing something stupid? I would greatly appreciate getting any useful pointer. Steve Beer - sbeer@ibm.net ------------------------------ From: vsuzuki@kankou.cs.uec.ac.jp (Suzuki Mitsugu) Subject: Driver for SMC91C92 Ethernet chip Date: Sat, 16 Dec 1995 09:04:51 GMT I got an VL-BUS type Ethernet card based on SMC91C92. (The board was manufactured by LONGSHINE.) It seemed to be that this chip has not been supported by Linux yet. Is there some working group for this chip ? I am willingly to be an ALPHA or BETA tester. Thanks, +-------------------------------------------------+ + Mitsugu Suzuki (gian@cs.uec.ac.jp) + + + + The University of Electro Communications + + + + 1-5-1 Chofugaoka, Chofu-si, Tokyo 182, Japan + + Dept. of Computer Science and + + Information Mathematics + + + + Tel: +81-424-83-2161 ex.4462 + + Fax: +81-424-82-3055 + +-------------------------------------------------+ ------------------------------ Crossposted-To: comp.os.linux.hardware From: Bob Lorenzini Subject: Re: Serial overrun on 16550A @ 38.4K DX4/100 1.2.13: driver problem ? Date: Fri, 15 Dec 1995 18:04:20 GMT I also suffered from overrun problems and if I recall correctly I had to use setserial to enable the buffer in the 16550a. Bob hwm@netcom.com _______________________________________________________________________________ The Microsoft Network is prohibited from redistributing this work in any form, in whole or in part, without a license. Such a license is available to Microsoft for $500/msg. Redistribution without permission constitutes an agreement to the above terms. If a violation is noted, notify postmaster@microsoft.com and hwm@netcom.com. (c) 1995 Ryan Tucker. _______________________________________________________________________________ ------------------------------ From: lotu@wam.umd.edu (Arcadio Alivio Sincero) Subject: So how goes the 8086 port? Date: 18 Dec 1995 15:04:56 GMT How can I follow the development of the 8086 port of Linux? Is there a mailing list? I'd like to be able to put Linux on my old 8086's boxes .. and then network them all together ... Arcadio ------------------------------ From: cbuckley@cs.tcd.ie (Colm Buckley) Subject: Re: Quotas over NFS? Date: 18 Dec 1995 15:34:16 GMT > == bosse@ing.umu.se (Bo Branten) >> == Miguel de Icaza (miguel@athena.nuclecu.unam.mx) >>> == cbuckley@tcd.ie (Colm Buckley) >>> Just turned on quotas with 1.3.47 and the quota-1.50 package, and >>> everything seems to be working okay... except that quotas don't >>> seem to work over NFS. I have rpc.rquotad running on the server as >>> suggested, but still things aren't working. Is there something else >>> I have to do to enable quotas over NFS? >> Quotas included with the kernel currently only support the ext2fs. >> You will have to wait for the nfs quota to work. > Quotas in Linux works well over NFS. The only thing you need to do is > running rpc.rquotad on the server and have quotas enabled in the > clients kernel. Thanks for the advice, but it doesn't seem to work properly... to "enable quotas in the client's kernel", what do I have to do? Colm -- Colm Buckley | EMail: Colm.Buckley@tcd.ie Phone: (+353 1) 6082336 Computer Science Dept | WWW: http://isg.cs.tcd.ie/cbuckley/ Trinity College | finger cbuckley@isg.cs.tcd.ie for more info. Dublin 2, Ireland | "Never trust a programmer with a screwdriver." ------------------------------ From: vonbrand@pincoya.inf.utfsm.cl (Horst von Brand) Subject: Re: GCC 2.7.2 and kernel 1.3.46 trouble Date: 17 Dec 1995 15:14:19 -0300 In article , Arthur D. Jerijian wrote: >[Problems compiling modules-1.2.8] My linux box is far away, so this is from memory: Look at the line where it complains, I remember a ',' or ';' is missing somewhere. Also, use the option for the old interpretation of variables defined in a for in g++, look at the manual in info, the man page is rather old. I actually patched modules to compile clean, but... -- Dr. Horst H. von Brand vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 626364 x 431 Universidad Tecnica Federico Santa Maria Fax: +56 32 625217 Casilla 110-V, Valparaiso, Chile ------------------------------ From: coyote@step.polymtl.ca () Subject: Re: Possible bug in .3.43 and .3.45 Date: 16 Dec 1995 03:09:51 GMT Reply-To: coyote@step.polymtl.ca In article <4aki2k$ete@newsserv.zdv.uni-tuebingen.de>, koenig@tat.physik.uni-tuebingen.de (Harald Koenig) writes: >In <4acka1$10ql@charles.cdec.polymtl.ca> coyote@step.polymtl.ca (Vincent Cojot) writes: > >> Upon bootup, with both 1.3.43 and 1.3.45 compiled with all my standard >> options (that I have been using since 1.1.95) here is what happens: > >> "Loading Linux...." comes up, the screen then jumps a tiny bit to the left >> and back, the "d" charcater with the cursor underneath appears at the top >> left of the screen and it just hangs there. > >same happend to me some versions ago. the reason was, that the uncompressed >kernel code size exceeded 1MB! ommiting some drivers not used for bootstraping >and using modules for these drivers fixes this problems (choose any unneeded >drivers of your choise...) This sounds a lot like what happened: If I were to remove the sound driver, then the kernel would boot Ok most of the time. Here are the results I got: 1.3.41+sound: OK 1.3.41/no_sound: OK 1.3.42+sound: NO 1.3.42/no_sound: OK 1.3.43+sound: NO 1.3.43/no_sound: OK 1.3.45+sound: NO "OK" means it booted fine, "NO" means it exhibited the problem shown above. The thing is that I don't have many drivers to spare. Why is there this 1mb kernel limit? (that's just out of curiosity..) -- ,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-, Vincent S. Cojot, Computer Engineering. Ecole Polytechnique de Montreal, Comite Micro-Informatique. coyote@step.polymtl.ca, coyote@info.polymtl.ca They cannot scare me with their empty spaces Between stars - on stars where no human race is I have it in me so much nearer home To scare myself with my own desert places. - Robert Frost ------------------------------ From: j.j.vanderheijden@mail.student.utwente.nl Subject: HELP: Looking for gcc-2.6.3/ELF sources Date: 18 Dec 1995 15:22:29 GMT Reply-To: j.j.vanderheijden@mail.student.utwente.nl I'm trying to build gpc, the GNU pascal compiler. gpc is based on gcc-2.6.3, but the regular GNU gcc-2.6.3 release doesn't support ELF. gpc will not build with gcc-2.7.x I remember there was a (beta) Linux/ELF gcc-2.6.3 on tsx-11 some time ago, in the packages/GCC directory. Does somebody still have this one? Thanks, JanJaap vd Heijden ------------------------------ From: edwards@panasync.canuck.ca (Colten Edwards) Subject: Re: AHHHH Date: 14 Dec 1995 09:13:46 GMT Jon M. Taylor (taylorj@ecs.ecs.csus.edu) wrote: : In article <4ahhog$n8q@panasync.canuck.ca>, : Colten Edwards wrote: : >Linus is back, a new patch is available. Thought I was actually going : >through withdrawal symptoms for the last week. :) Actually managed to : >install a new HD, reinstall linux distro from RedHat, get everything : >working and patched, recompile X twice : : I haven't gotten .46 to correctly compile on my system yet. : Either my kernel source has gotten screwed up with all the patch : installing and backing out I've done lately, or there are errors in the : patch. Anyone else having problems compiling it? This isn't gcc : segfaulting on me, BTW. I'm using 2.7.0. Never had any trouble compiling 46/47.. Seems to be running fine except that damn MMAP problem... Colten Edwards ------------------------------ From: jmcc@m5.vi.ri.cmu.edu (Jason Mcmullan) Subject: Re: Unusual disk activity under 1.3.45... Date: 18 Dec 1995 15:03:12 GMT Sangria (sangria@inlink.com) wrote: : Has anyone notice an unusal disk activity under the 1.3.45 : kernel? : Almost like clock work, I come home from work, sit infront of : another machine, and while working, my Linux machine would : suddenly start with a barrage of disk activity. : This would go on for about 5 minutes and everything would : return to normal once again. : At the time when this activity is going on, there is nothing : running on Linux except a copy of bash, which is sitting : idle... Just wondering... You didn't happen to have any cron jobs set to run at about the same time you get off of work do you? Also, since the kswap patches are in, it could be the kernel syncing pages that were dirties a while back but were never pushed into swap by newer ones. -- Copyright 1995 Jason McMullan; all rights reserved; license for the Microsoft Network to distribute this text for US $100,000 per copy is hereby granted; all other use of this text by the Microsoft Network, including storing, relaying, or reuse is expressly prohibited; distribution by the Microsoft Network indicates full acceptance of the licensing terms. MICKEY# 4729-304-8732 ------------------------------ ** 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-System-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development.system) via: Internet: Linux-Development-System@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-System Digest ******************************