Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA02926; Wed, 20 Dec 95 07:18:34 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA12232; Wed, 20 Dec 95 07:18:33 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id HAA18771 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Wed, 20 Dec 1995 07:13:47 -0500 Message-Id: <199512201213.HAA18771@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Date: Wed, 20 Dec 95 07:13:44 EST Subject: Linux-Development-System Digest #138 Linux-Development-System Digest #138, Volume #2 Wed, 20 Dec 95 07:13:44 EST Contents: cpp: output pipe has been closed error (Naresh Sharma - aio fac L en R) Re: Bogus BogoMips - udelay problems (Joe Philipps) HELP on undelete feature (Panuccio Antonello) ISDN and CAPI (Honore B.-LAMIH) Generic SCSI problem (Pierre Ficheux) Re: Nakamichi CD changer support (Remco Treffkorn) Re: [patch] Make 3.74 under 1.3.4x (John Kennedy) Re: gcc 2.7.2 and 1.2.13 kernel (Volker Schmidt) gcc-2.7.2 breaks sound driver 2.90.2 in 1.2.13-elf (Volker Schmidt) Directory: just a file? (Bob Nelson) Re: fatal signal 11 on cc1 everytime i try to compile a kernel.. (Rogier Wolff) Re: Linux has poor memory management? (Larry Daffner) RE: A question regarding Syslogd and Klogd (BOFH) Re: Linux Security - C2 and beyond (Markus Kuhn) Re: Directory: just a file? (Jan Mattsson) Re: Kernel Change Summary 1.3.48 (Alain Knaff) ---------------------------------------------------------------------------- From: sharma@IS.TWI.TUDelft.NL (Naresh Sharma - aio fac L en R) Subject: cpp: output pipe has been closed error Date: Tue, 19 Dec 1995 10:25:39 GMT Hi Folks, I've been getting the following errors while trying to compile the recent kernels ie 1.3.48, NCR 53c810 scsi, ibcs2 etc.. gcc: internal compiler error: program cc1 got fatal signal 11 cpp: output pipe has been closed Also the following error: VFS: Wrong block size on device 08:03 Problem: block on freelist at 0009ed4 isn't free Sometimes I get the following error execvp: gcc: Out of memory I have 32 mb ram and 32 mb swap. Does anyone have a clue ? -- Greetings, __ N.Sharma@IS.TWI.TUDelft.NL __________/ F c'____---__=_/ Naresh _______________o_____o___________http://is.twi.tudelft.nl/~sharma/ ------------------------------ From: rchandra@hal9000.buf.servtech.com (Joe Philipps) Subject: Re: Bogus BogoMips - udelay problems Date: 20 Dec 1995 04:51:13 GMT Reply-To: rchandra@letter.com In article <4aoeb9$8qk@leonard.anu.edu.au>, Paul Gortmaker wrote: >If he/she only gets 2.5 bogomips [with an AMD 486-100], then >something is misconfigured >on their system. Oddly enough w/ AMI and Am486DX/4-100, with caching set to write-back, I get 3.16 BogoMips. With write-thru, I get 50.08. gofigger. I must have the exact same motherboard as the reporter in the BogoMips-HOWTO. (Or is that a mini-HOWTO?) >In a few of the network drivers, the global "jiffies" counter (which >counts timer interrupts) is used. Speaking only of 1.2.13: I was trying to find out where the timer value was loaded in the code (turns out irq.c of all places). I did a find -exec grep ( <== Reader's Digest version :^) on 11932 (which for the usual crystal would be the counter value). Much to my surprise, both hd.c and ide.c have " jiffies * 11932 ". Anyone else think that sticking such constants into the middle of things is a Very Bad Thing? I would have hoped it might be something more like jiffies * LATCH. ------------------------------ From: Panuccio Antonello Subject: HELP on undelete feature Date: Mon, 18 Dec 1995 23:51:43 +0100 Does anyone have an undelete feature using undelete bit in inode flags ? Please e-mail to panuccio@mbox.vol.it. Thanks ... ------------------------------ From: honore@antok.news.univ-lille1.fr (Honore B.-LAMIH) Subject: ISDN and CAPI Date: 15 Dec 1995 17:06:52 GMT Hi, I'm looking for software (shareware or public domain preferred) that uses the CAPI 2.0 interface under Linux. It's not very important what the software does but it should work correctly. Thanks for any help ======================================== HONORE Bertrand Bureau 102 - LAMIH Le Mont Houy Universite de Valenciennes 59304 Valenciennes FRANCE tel : (33) 27 14 12 34 (4122) e-mail : honore@univ-valenciennes.fr ========================================= -- ################################################## HONORE Bertrand LAMIH - Bureau 102 Universite de VALENCIENNES Le Mont Houy 59304 Valenciennes France e-mail: honore@univ-valenciennes.fr http://titan.univ-valenciennes.fr:1234/ ################################################# ------------------------------ From: pierre@rd.lectra.fr (Pierre Ficheux) Subject: Generic SCSI problem Date: 18 Dec 1995 14:38:52 GMT Hi, I've got a problem with the generic SCSI driver (/dev/sgx) under Linux-1.2.13 (seems to be the same under 1.3.45). The driver does *not* any error to the environment even in case of SCSI problem with the unit :( That's a big problem for example with a SCSI printer because a "PAPER OUT" error (for example) cannot be detected... Well, it works fine with Solaris (and i hate Solaris !) so could you help me (please Email), that's **URGENT** Thanks by advance, -- ._______________________.______________________________________________. +-----------------------'----------------------------------------------'| | Pierre FICHEUX | tel : +33 57 97 80 00 || | Lectra Systemes | fax : +33 57 97 82 32 || | ZI Marticot | E-mail: pierre@rd.lectra.fr || | 33610 CESTAS, FRANCE | WWW: http://www.alienor.fr/~pierre || `----------------------^-----------------------------------------------' Linux lInux liNux linUx linuX Linux lInux liNux linUx linuX Qui se ressemble, s'assemble, edite ses liens ... ------------------------------ From: remco@fiat.ugraf.com (Remco Treffkorn) Subject: Re: Nakamichi CD changer support Date: 20 Dec 1995 04:49:48 GMT uri@vnet.ibm.com wrote: ... : CDROM support with Linux 1.3.42 . Please let me know if there is : any support for a CDROM changer. Seems like creating a custom driver may : be worth the effort. ... No need! Just reconfigure your kernel to "probe all LUNs" on scsi devices. The seven disks are mapped to seven LUNs on only one device ID. ------------------------------ From: warlock@csuchico.edu (John Kennedy) Subject: Re: [patch] Make 3.74 under 1.3.4x Date: 19 Dec 1995 19:53:31 GMT In article <4b6t25$1176@news.missouri.edu>, wrote: > The following Patch fixes Make 3.74 for use > with the newest 1.3.x kernels. ... The ELF fix (from libc 5.2.18) worked just fine on 1.3.48 with make-3.74. Here is an edited-down release.libc-5.2.18: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This is the public release of the Linux C library release 5.2.18. ... A dirent bug, which erroneously defined d->reclen to d->namlen if USE_GNU was defined, has been fixed. Unfortunately, some GNU packages depend on this bug. GNU make 3.xx is one of them. A patch is included here. Please recompile GNU make before installing this library. Otherwise you have to use "make -f Makefile" to specify which Makefile to use when rebuilding GNU make. A back door has been added for the file descriptor in DIR. You need to define DIRENT_ILLEGAL_ACCESS to access the dd_fd field. You should use dirfd () to get the the file descriptor in DIR. Use this at your own risk. ... ---- RCS file: /home/cvs/gnu/make/dir.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 dir.c *** 1.1.1.1 1995/06/25 03:27:16 --- dir.c 1995/06/25 03:55:22 *************** *** 20,26 **** #if defined (POSIX) || defined (HAVE_DIRENT_H) || defined (__GNU_LIBRARY__) #include ! #ifndef __GNU_LIBRARY__ #define D_NAMLEN(d) strlen((d)->d_name) #else /* GNU C library. */ #define D_NAMLEN(d) ((d)->d_namlen) --- 20,26 ---- #if defined (POSIX) || defined (HAVE_DIRENT_H) || defined (__GNU_LIBRARY__) #include ! #ifndef __BAD_GNU_LIBRARY__ #define D_NAMLEN(d) strlen((d)->d_name) #else /* GNU C library. */ #define D_NAMLEN(d) ((d)->d_namlen) =================================================================== RCS file: /home/cvs/gnu/make/glob/glob.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 glob.c *** 1.1.1.1 1995/06/25 03:27:18 --- glob/glob.c 1995/06/25 03:56:01 *************** *** 64,70 **** #if defined (POSIX) || defined (HAVE_DIRENT_H) || defined (__GNU_LIBRARY__) #include ! #ifndef __GNU_LIBRARY__ #define D_NAMLEN(d) strlen((d)->d_name) #else /* GNU C library. */ #define D_NAMLEN(d) ((d)->d_namlen) --- 64,70 ---- #if defined (POSIX) || defined (HAVE_DIRENT_H) || defined (__GNU_LIBRARY__) #include ! #ifndef __BAD_GNU_LIBRARY__ #define D_NAMLEN(d) strlen((d)->d_name) #else /* GNU C library. */ #define D_NAMLEN(d) ((d)->d_namlen) ------------------------------ Crossposted-To: comp.os.linux.misc From: volker@illuminatus.mz.rhein-main.de (Volker Schmidt) Subject: Re: gcc 2.7.2 and 1.2.13 kernel Date: Wed, 20 Dec 1995 06:38:59 GMT "Leonard N. Zubkoff" writes: >In article <4b5tk5$aha@qns2.qns.com> mjarvis@qns2.qns.com (Michael Jarvis) writes: > Mark Nordberg (Mark Nordberg (mark@quickening.catt.ncsu.edu)) wrote: > > Has anyone else had problems with gcc 2.7.2 and kernel 1.2.13 elf. > > I seem to think that gcc-2.7.2 has a problem. I am using the > > precompiled version released to the public. Has anyone else seen this > > problem? > I'm having trouble compiling the 1.2.13 kernel with gcc 2.7.2 as well. >The following patch will fix this problem: Thanks Leonard! That brought the-stable-kernel-users back to business. But this works only if you disable the orginal sound driver 2.90.2. If you try to use it, you'll get a recursion to deep for the sound-include header. I don't tested with the sounddriver 3.01. Have anyone these things back and working? -volker -- Volker Schmidt volker@illuminatus.mz.rhein-main.de ------------------------------ From: volker@illuminatus.mz.rhein-main.de (Volker Schmidt) Subject: gcc-2.7.2 breaks sound driver 2.90.2 in 1.2.13-elf Date: Wed, 20 Dec 1995 06:43:42 GMT After installing gcc-2.7.2 I tried to compile the kernel with the standard sound driver. With no success. I got a message: Header recursion to deep, or somesuch. I have applyed the asm-386.h fix. Anyone out there with kernel-1.2.13-elf, gcc-2.72, the latest binutils, a freshly compiled kernel _and_ working sound? -volker -- Volker Schmidt volker@illuminatus.mz.rhein-main.de ------------------------------ Crossposted-To: comp.os.linux.development.apps From: bnelson@netcom.com (Bob Nelson) Subject: Directory: just a file? Date: Wed, 20 Dec 1995 06:08:11 GMT After several years of programming in C and about 3 years of working with Linux, I'm surprised that only now I pose this query: K&R2 (p. 179) state "...a UNIX directory is just a file...". As most of you know, the remainder of section 8.6 deals with an implementation of opendir, readdir and closedir. (They do allow that there are some system specific issues "left as an exercise"). What strikes me as interesting is using open() followed by read() to access the contents of the directory "file". Trying the code shown on p. 184 yields EISDIR on the read() call (just like in MS-DOS! :)). I've always used the POSIX functions to access the contents of a directory in the past (and naturally, will continue to do so in the future). So...the question...what are some of the UNIX variants where a directory entry is simply a file -- since that appears to not be the case in Linux? -- ============================================================================= Bob Nelson: Dallas, Texas, U.S.A. - bnelson@netcom.com Linux for fun, M$ for $$$...and the NFL for what really counts! ============================================================================= ------------------------------ From: wolff@socrates.et.tudelft.nl (Rogier Wolff) Subject: Re: fatal signal 11 on cc1 everytime i try to compile a kernel.. Date: 20 Dec 1995 10:14:17 GMT Reply-To: r.e.wolff@et.tudelft.nl Ben Elliston (bje@fresh.air.net.au) wrote: : In article <49hkpf$pet@goliat.eik.bme.hu>, : chexum@bankinf.banki.hu (Janos Farkas) writes: : >I think almost everyone had or has this problem, but I'm now pretty sure : >that it's a memory/motherboard problem... I even had kernel oopses with : I also know a couple of people who have successfully pinpointed the problem : to being bad cache RAM. Correct you are, For more information have a look at: http://einstein.et.tudelft.nl/~wolff/sig11/ Roger. -- *** War doesn't determine who's right ****** War determines who's left. *** ** EMail: R.E.Wolff@et.tudelft.nl * Tel +31-15-2783643 or +31-15-2137459 ** *** my own homepage *** ------------------------------ From: ldaffner@convex.com (Larry Daffner) Subject: Re: Linux has poor memory management? Date: 19 Dec 1995 10:46:53 -0600 In rnation@porgy (Robert Nation 885-9815) writes: >>: Sheduler: Choose a process in core to run. >>: Swapper: Steal page not recently/often used. >> >>How would u suggest changing one or both to fix this problem? >You could try to balance the percentage of memory that each process gets. >For example, if you have 20 MB of memory in use, but only 10 MB of physical >memory, you could try to maintain each process with 50% of its pages in >physical memory at once. This, IMHO, is a patently bad idea... Suppose I have 2 processes running, one which takes up a large chunk of VM but spends 99% of it's computing time on 1 page, and the other a small program which touches most of it's VM on a short cycle. Are you suggesting that these programs should both have equal proportions of VM? That sounds grossly inefficient to me. Whatever algorithm you use to decide which pages are candidates, you can't base it on the pure VM size of the program. Also what about all those processes that spend most of their life waiting (getty's come to mind here). Are yu suggesting they should have half their address space in memory as well, even tho it might be days before they're asked to run? Different processes are going to have different physical memory needs. It's silly to try and equal them out artificially. >Alternately, you could give a penalty to pages from big programs, when >selecting a page to swap out. This might be a little more reasonable, if it gets a slightly different wording.. How about... "...you could give a penalty to pages from programs which have a large physical memory allocation, when selecting.." Penalty, of course, not meaning that all their pages are taken, but that pages using lots of physical memory have their pages kept on a shorter cycle. Thus, it becomes more difficult for, say, a database which may go through it's address space rapidly to have a stranglehold on physical memory. Just my .02 -Larry -- Larry Daffner - Software Engineer | email: ldaffner@convex.com | Convex Computer Corporation | tel: (214)497-4274 / home: (214)380-4382 | Hare's Law: Inside every large program is a small program struggling to get out. ------------------------------ From: BOFH Subject: RE: A question regarding Syslogd and Klogd Date: Wed, 20 Dec 1995 10:12:27 +1300 FYI I checked the binary of syslogd and it looks like that the .pid files are hard coded to be in /etc directory. :( >I am running the Slakware 2.2 (Infomagic) distribution and have noticed >that both syslogd and klogd and putting their .pid files in the /etc >directory, instead of the /var/run directory. >If anyone has an idea why this happens, or has a fix (Other I suppose >there is always recompiling syslogd and klogd), I would be greatly >interested. ------------------------------ From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) Subject: Re: Linux Security - C2 and beyond Date: 18 Dec 1995 01:02:46 +0100 Reply-To: mskuhn@cip.informatik.uni-erlangen.de hm@seneca.Linux.DE (Harald Milz) writes: >Scott Johnson (johnsos@holmes.ece.orst.edu) wrote: >> Why? Is one of the requirements of C2 security that source code for the >> applications be unavailable? >No. But as long as there's source code available (namely for the kernel) and >someone is root (we agree that someone must be root, right?) you cannot >expect the kernel to contain secure structures and stuff. Root can >re-configure, re-compile and install any kernel (and applications/libraries >etc.) he likes. How about C2 security then? Or did I miss something? I've been messing around with debuggers and disassemblers in the kernels and data structures of operating systems for which no source code was available. Actually, becoming root under SunOS by patching the kernel data structures is the first exercise in an advanced system programming course held each year at the University of Erlangen. It is pretty easy to find critical tests and replace them with nop instructions if you know what you are looking for. It does not make really much difference, whether the source of the OS under attack is available to the potential attacker or not. You definitely can patch operating systems or write trojan modules without the source. I've seen it done by others before in order to hack up e.g. commercial software network license servers. Having the source available only simplifies for the attacker looking for security leaks. But we don't want to have security by obfuscation, do we? It is of course a requirement in the formal certification procedures that the source code is available to the examiners. I am not very familiar with the orange book procedure details, but for the European ITSEC security criterias, for the evaluation levels E3 and higher, the source and various levels of documentation and formal security models have to be available for examination. Markus -- Markus Kuhn, Computer Science student -- University of Erlangen, Internet Mail: - Germany WWW Home: ------------------------------ From: janm@mydata.se (Jan Mattsson) Crossposted-To: comp.os.linux.development.apps Subject: Re: Directory: just a file? Date: 20 Dec 95 10:06:10 GMT Reply-To: janm@mydata.se bnelson@netcom.com (Bob Nelson) writes: >I've always used the POSIX functions to access the contents of a >directory in the past (and naturally, will continue to do so in the >future). So...the question...what are some of the UNIX variants where a >directory entry is simply a file -- since that appears to not be the >case in Linux? System V variants. If you do 'cat .' on a SysV machine you get a lot of gibberish on your screen. -- Jan Mattsson email: Jan.Mattsson@mydata.se Software Engineer phone: +46 8 6290900 Mydata Automation AB fax: +46 8 6290909 ------------------------------ From: knaff@imag.fr (Alain Knaff) Subject: Re: Kernel Change Summary 1.3.48 Date: 19 Dec 1995 07:29:44 GMT Reply-To: Alain.Knaff@imag.fr Michael Elizabeth Chastain (mec@treflan.shout.net) wrote: You forgot integrated compressed ram disk support. That's what the following changes are about :-) [...] : arch/i386/boot/compressed/*: rearrange gzip code (1904 lines). This has been done so that the cramdisk code may access it as well. [...] : fs/buffer.c: handle protected buffers in 'refill_freelist'. This has been done because the new ramdisk lives in the buffer cache. Formerly, data had to be copied from the actual ramdisk to the buffer cache, resulting in twice as much memory being used. Protected buffers are a new concept. Tey are ramdisk data. These have to be treated specially because the buffers are the only copy of the data: they're not backed by a physical device. -- Linux - Where do you want to fly today ? Windows 95 - Makes a grown man cry Alain ------------------------------ ** 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 ******************************