Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA14398; Sat, 24 Feb 96 19:18:41 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA24189; Sat, 24 Feb 96 19:18:18 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.13/2.3JIK) id TAA11731 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Sat, 24 Feb 1996 19:14:39 -0500 Message-Id: <199602250014.TAA11731@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Delivered-To: Linux-Development-System@senator-bedfellow.mit.edu Precedence: bulk Date: Sat, 24 Feb 96 19:14:35 EST Subject: Linux-Development-System Digest #421 Linux-Development-System Digest #421, Volume #2 Sat, 24 Feb 96 19:14:35 EST Contents: "make" won't work (Fred Broce) Re: The better (more suitable)Unix?? FreeBSD or Linux (Kees J Bot) Re: Running Production USENET on Linux - inode problem? (Sam Trenholme) Re: Weird load behaviour under 1.3.67 (Steve McIntyre) mount cd-rom with kerneld- how? (Mika Sorsa) YO HELP! IDE support broken in 1.3? (Yves Joosen) malloc-bug in libc? (Tobias Edvardsson) Re: The better (more suitable)Unix?? FreeBSD or Linux (Terry Lambert) Re: libc bug: math.h has incorrect prototypes (Ulrich Drepper) Two Problems... (Hans-Joachim Baader) Kernel Change Summary 1.3.67 (Michael Elizabeth Chastain) Kernel Change Summary 1.3.68 (Michael Elizabeth Chastain) Re: need secure OS to entrust millions to (Terry Lambert) Re: 1.3.67 -- beginning to look a lot..like..beta (vergil) Re: Serios problem with e2fsck (1.01), Possible EXT2FS (1.3.66) (Rob Janssen) ---------------------------------------------------------------------------- From: Fred Broce Subject: "make" won't work Date: Sat, 24 Feb 1996 14:09:22 -0500 When upgrading everything to elf...I find I can't run the latest elf make If I replace the old make with the new elf make It gives the error can't find makefile when I try and compile. Any suggestions? Fred ------------------------------ Crossposted-To: comp.unix.bsd.freebsd.misc From: kjb@cs.vu.nl (Kees J Bot) Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Date: Fri, 23 Feb 1996 13:48:09 GMT Terry Lambert writes: [snip] >After some offline prompting, I checked the code path for an >unlink, and it looks like FreeBSD doesn't do the change time >update on the directory inode synchronously. >I think this is probably in violation of POSIX semantic >requirements (else why make the distinction in the standard >between "shall be updated" and "shall be marked for update"?). >Nevertheless, the extra overhead I described is apparently >limited to the SVR4 UFS implementation. Under Minix "shall be marked for update" is done by setting a bit in the in-core inode telling that one of [amc]time must be updated somewhere in the future. "Shall be updated" is done by actually writing the current time into one of [amc]time that has been marked for update. Why? Because getting the current time is an expensive call from the file server to the clock task. The last close of a file, one of the stat() calls or a sync() triggers the time update. He who wrote this code assumed that this is what POSIX meant by "shall be marked for update", i.e. getting the time may be expensive, so you can delay it until "shall be updated". Old-fashioned monolithic operating systems can keep the current time in a global variable, so they need not bother to first mark for and later update a time field, but can update it immediately. -- Kees J. Bot (kjb@cs.vu.nl) Systems Programmer, Vrije Universiteit Amsterdam ------------------------------ Crossposted-To: comp.os.linux.hardware,comp.os.linux.advocacy,comp.os.linux.help,comp.os.linux.networking From: stren@netcom.com (Sam Trenholme) Subject: Re: Running Production USENET on Linux - inode problem? Date: Fri, 23 Feb 1996 06:16:33 GMT > I talked to another sysadmin, and, in mention of this, he suggested that >I go with the UltraSPARC, because Linux apparently has(had?) a problem with >machines that had so many inodes. > > Is this true? What is the limitation of Linux and inodes? You can have up to 4 billion inodes on an ext2 filesystem. mke2fs defaults to one inode every 4096 bytes. This is not enough inodes for a partition that is primarily a news spool. Simply "mke2fs -i 2048 -c" will have an inode every 2048 bytes, which should be wnough for a news spool. I have not heard of problems from people who run news spools with large number of files, running the ext2 filesystem. -- Sam Trenholme - stren@netcom.com - http://ucsee/eecs/berkeley/edu/~set - LINUX! ------------------------------ From: sam1007@hermes.cam.ac.uk (Steve McIntyre) Subject: Re: Weird load behaviour under 1.3.67 Date: 23 Feb 1996 14:06:24 GMT [I know, following up to myself, but...] In article <4gjj0n$oii@lyra.csx.cam.ac.uk>, Steve McIntyre wrote: >Consistently, about three hours after booting, the load shoots up and the >system cpu usage (reported by top) goes over 40% and stays there. There >are no processes accounting for this sudden increase in load. No messages >are generated at all to explain it, but suddenly the system becomes >unusable. I have checked several times if there are any obvious problems, >but to no avail... Any ideas? > >I am running 1.3.67 including the patch Linus posted here to fix the tcp >CLOSE socket problem; that is at least now fixed, but I could handle that >better than the current situation. > >I am about to try 1.3.68 and see if that fixes the problem... Just read Linus' explanation of this on the kernel mailing list; this patch was at fault. 1.3.68 seems very nice so far, but we shall see... -- Steve McIntyre, CURS Secretary "Can't keep my eyes from the circling sky," sam1007@cam.ac.uk "Tongue-tied & twisted, Just an earth-bound misfit, I..." Churchill College my home page Cambridge, UK My PC page ------------------------------ From: sorsa@cc.Helsinki.FI (Mika Sorsa) Subject: mount cd-rom with kerneld- how? Date: 23 Feb 1996 14:09:08 GMT I use kernel 1.3.67 with kerneld, (no config_modversions). My system has a CR-562B cd-rom for which there is a module sbpcd.o. Also there is module for the iso9660 file system for cd's. My problem is how to make mount /dev/sbpcd work automagically, i.e. it should load the cd-rom driver module and isofs module. I only manage to get it load the isofs, the cd-rom-driver I must load separately (they are not dependent according to depmod or modprope -c). Can I use aliases (conf.modules - I have tried many combinations!) or could I just put the isofs depend on sbpcd in modules.dep, or what? -- ? ------------------------------ From: Yves Joosen Subject: YO HELP! IDE support broken in 1.3? Date: Thu, 22 Feb 1996 22:06:02 +0100 HELP, I've been using kernel version 1.2x for quite a while and thought is was time for an upgrade. Upgraded all the way to 1.3.66 and recompiled. I have two IDE controllers, each with one harddisk attached. Everything worked fine with 1.2x. Now I'm getting right after the whole probing proces (which still is correct, my two ide interfaces share irq 14), the following output: Partition check: hda: and some status 0x50 timeout error, 0x58 and unable to access hda. Using the old ide driver for ide0 doesn't work, cause it won't allow sharing irqs. Any clues? Yves. ------------------------------ From: Tobias Edvardsson Subject: malloc-bug in libc? Date: Sat, 24 Feb 1996 16:08:02 +0100 Reply-To: tobias@gcn.se Hello, All! Is there any known bugs in malloc in libc? I4m currently working on a major database project using gcc on a linux-platform and a line I know is correctly written (No warnings and several other people than me have checked this out) gives me segmentation-fault. Please send a E-Mail to me if there is any known bugs in libc malloc! Greetz- -- \\|// -(@ @)- ===oOO==(_)==OOo================================================================= Tobias Edvardsson TEL: +46-(0)31-775 00 80 Vdrmlandsgatan 19 GlobeCom Network GSM: +46-(0)70-896 99 60 413 27 Gvteborg IRC: [Psyker] FAX: +46-(0)31-775 00 85 Sweden E-Mail: tobias@gcn.se WEB: http://www.gcn.se/ ================================================================================= ------------------------------ From: Terry Lambert Crossposted-To: comp.unix.bsd.freebsd.misc Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Date: 22 Feb 1996 20:50:14 GMT mday@park.uvsc.edu (Matt Day) wrote: ] >I think you are confusing "user perception of speed" with "file ] >system researcher perception of speed". ] ] I disagree. I think the impact of the speedup will go far beyond the ] tiny file system researcher community. See below for further support of ] my claim. My initial posting to which you were replying was a defense of the use of synchronus writes to ensure ordering. I think that any possible lack of determinism in crash recovery is simply unacceptable for all but a few cases, and those cases have been adequately explored in other posts. That said, I'm not going to defend sync updates as the *best* method of ensuring structure integrity, only as *a* method, and a irrefutably better than async updates in all cases. [ ... rm and POSIX semantics adding to the overhead ... ] ] >The metadata would not need to be written if the access timestamp ] >did not need to occur, or did not need to "shall be updated" as ] >opposed to "shall be marked for update". ] > ] >The remove operation would modify the directory metadata ] >synchronously only in the case of the directory being truncated ] >back (a new feature of 4.4 UFS), causing the file size to need ] >to change, or in the case of the update actually taking place ] >when the update daemon fired. [ ... ] ] What you have said here is completely wrong! ] ] When removing a directory entry in the BSD FFS, the on-disk inode must ] not be reinitialized or pointed to by a new on-disk directory entry or ] free inode map before all previous on-disk directory entry pointers to ] it have been nullified. To implement this rule, 4.4BSD FFS ] synchronously updates the on-disk directory entry when removing a ] directory entry. You can verify this for yourself by looking at the ] ufs_dirremove() routine in ufs/ufs/ufs_lookup.c in FreeBSD. This occurs ] every time a directory entry is removed. I agree for these operations. BSD also does a sync update of the directory change time in the directory inode. It was this "metadata", not the directory entry itself, to which I was referring when I said this was an unnecessary overhead. I know that you and I disagree on whether the POSIX semantic "shall be updated" means "shall be committed to disk" or not. I know that "shall be marked for update" means that it is permissible to use a delayed write (modify the value in memory and mark the structure dirty). I disagree about the "shall be updated" requiring only a commit to memory rather than to permanent storage. From my perspective, then, POSIX adds unnecessary overhead for preserving what seem to be VMS or other historical semantics for no other apparent reason, other than history. 8-(. ] To summarize: every time you delete a file on FreeBSD, two separate ] synchronous metadata updates occur: one for the directory entry and one ] for the inode. The reason the updates are synchronous is to prevent ] irreparable metadata inconsistencies from occurring. It has absolutely ] nothing to do with POSIX semantics. Three. See above. ] Please remember that the 5-7% performance improvement they measured was ] smaller than one could expect due to the speed of their CPU. The faster ] your CPU, the greater the performance improvement will be if you don't ] do synchronous metadata updates. I agree that 5-7% is on the edge of ] being user perceptible, thus if the improvement is greater on faster ] CPUs (for example, any Pentium), I believe the improvement will be quite ] perceptible. Certainly for you and me. 8-). I believe that computers won't be fast enough until the computer precomputes all posible actions by the user at any given point, and then responds instantly with the right response when the user hits return. Including recompiling the world, or whatever. Even then, I'll probably be annoyed at having to wait for the log output to scroll by. 8-). ] >The SDET is, I admit, more problematic. From the graph in their ] >first paper, however, the increas is from 35 to 52 sripts/hour for ] >a single user, and actualy is widest at 2 users (tending to converge ] >to a smaller difference as number of users increase from 3 on up. ] > ] >A 34% difference (narrowing to ~28% on the graph) is significant ] >enough to be perceptible (though nowhere near 50-70% claimed in ] >the text... the highest I see on the graph is 40 vs 60 on two ] >"users"... a 50% difference). ] ] The numbers they claimed in the text are correct. According to the ] graph, the difference in scripts/hour is 35 vs. 60 in the two user case ] (a 71.4% improvement) and 40 vs. 57 in the 8 user case (a 42.5% ] improvement). I calculated my percentages incorrectly as percentage difference instead of percentage increase (which is what the paper correctly reports. In any case, anything over 15% would probably represent a significant result. ] Anyway, I don't think there's a software developer on the planet that is ] satisfied with how fast his/her system compiles programs. And, by god, ] we're the software developers so we say what goes. :-) 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: drepper@ipd.info.uni-karlsruhe.de (Ulrich Drepper) Subject: Re: libc bug: math.h has incorrect prototypes Date: 23 Feb 1996 16:07:14 +0100 In article ksh@shark.ds.boeing.com (Scott Hunziker) writes: The "__attribute__ ((const))" stuff is a gcc directive that advises the compiler that the function has no side effects. That's not right for log(3), since it sets errno for range and domain errors. In code that looks like AFAIK "__attribute__ ((const))" only means that the result of the function only depends on the argument. I.e., errno = 0; y = log (x); y = log (x); if (errno) wipeout (); will have the same result as your example below (which is correct). errno = 0; y = log (x); if (errno) wipeout(); the (optimizing) compiler can skip the "if" test because it's been told that log(3) won't change errno. Can you prove this? Does this code is generated for you as you describe it (take a look at the asm file). If yes we should talk a bit about "const" with the gcc maintainers (either the optimization is too strong, or ourunderstanding is wrong). -- -- Uli ________--------------------------------------------------------------- \ / Ulrich Drepper / Univ. at Karlsruhe, Germany / CS Dept. / IPD L\inux/ email: drepper@gnu.ai.mit.edu smail: Rubensstr. 5 \ / drepper@ipd.info.uni-karlsruhe.de 76149 Karlsruhe \/1.3.68 ------------------------------------------ Germany -------- ------------------------------ From: hans@grumbeer.pfalz.de (Hans-Joachim Baader) Subject: Two Problems... Date: 21 Feb 1996 09:02:58 +0100 Hi, I have two problems with recent versions of Linux. Currently I have 1.3.66, but the problems were the same with 1.3.62. 1) make menuconfig doesn't work: lxdialog dumps core. It's statically linked with ncurses 1.9.7a. Of course I could recompile it in debug mode and see where it dies, but I wanted to ask first if someone knows the solution... 2) When trying to do 'mt erase' I get a kernel null pointer message. Using zftape 1.00 on /dev/zqft0 and the kerneld daemon. After that, the floppy controller is inaccessible (is it possible to reset it?). Insmod of floppy.o says: inserting floppy driver for 1.3.66 Floppy drive(s): fd0 is 1.44M, fd1 is 1.2M floppy0: Unable to grab IRQ6 for the floppy driver Initialization of floppy failed Hope someone can look into it :-) Hans-Joachim -- hans@grumbeer.pfalz.de Uncle Ed's Rule of Thumb: Never use your thumb for a rule. You'll either hit it with a hammer or get a splinter in it. ------------------------------ From: mec@treflan.shout.net (Michael Elizabeth Chastain) Subject: Kernel Change Summary 1.3.67 Date: 23 Feb 1996 21:09:47 GMT Kernel Change Summary Linux 1.3.67 (1920 lines) Fri 23 Feb 1996 My KCS archive: ftp://ftp.shout.net/pub/users/mec Documentation/devices.{tex,txt}: continuing development. drivers/net/slip.h: fixed #define bug that caused CSLIP telnets to hang in 1.3.61-66 [Craig Schlenter]. fs/fat/inode.c: give 'x' bit to .EXE, .COM, .BAT files. fs/nfs/file.c: total rewrite of read side for new NFS buffer cache [Linus Torvalds]. kernel/ksyms.c: add generic_file_mmap; remove generic_mmap. kernel/sched.c: implement sys_sched_yield and sys_nanosleep. Michael Chastain mec@duracef.shout.net ------------------------------ From: mec@treflan.shout.net (Michael Elizabeth Chastain) Subject: Kernel Change Summary 1.3.68 Date: 23 Feb 1996 21:10:46 GMT Reply-To: mec@duracef.shout.net Kernel Change Summary Linux 1.3.68 (5792 lines) Fri 23 Feb 1996 My KCS archive: ftp://ftp.shout.net/pub/users/mec Documentation/Configure.help: reformatting; CONFIG_BLK_DEV_LOOP, CONFIG_DESKSTATION_RPC44, CONFIG_MIPS_MAGNUM_3000, CONFIG_MIPS_MAGNUM_4000, CONFIG_OLIVETTI_M700, CONFIG_DESKSTATION_TYNE, CONFIG_ACER_PICA_61, CONFIG_DECSTATION, CONFIG_CPU_R3000, CONFIG_ELF_KERNEL, CONFIG_EXTRA_ELF_COMPILER, CONFIG_CPU_LITTLE_ENDIAN, CONFIG_SCSI_ADVANSYS, CONFIG_SCSI_GENERIC_NCR53C400, CONFIG_SCSI_G_NCR5380_PORT, CONFIG_SCSI_NCR53C406A, CONFIG_SCSI_AM53C974, CONFIG_VORTEX, CONFIG_WATCHDOG_NOWAYOUT, CONFIG_WDT, CONFIG_WDT_501, CONFIG_WDT_501_FAN, CONFIG_SOFT_WATCHDOG (1067 lines). Documentation/filesystems/ncpfs.txt: new file. MAINTAINERS: maintainers and source submission procedures [Alan Cox]. drivers/block/loop.c: loopback driver [Theodor Ts'o, Werner Almsberger, Mitch Dsouza, Andries Brouwer]. drivers/net/new_tunnel.c: new IP tunneling [Sam Latinga, Alan Cox]. drivers/pci/pci.c: add SGS_2000, SGS_1764, AMCC_MYRINET, RP80CTA, RP8INTF, RP16INTF, RP32INTF, PCI_VENDOR_ID_RP. drivers/scsi/scsi.c: blacklist "RENO CD-ROMX2A"/"2.03", "ST1581"/"6538". fs/fat/inode.c: boot-time 'showexec' option for 'x' flag on EXE,COM,BAT. fs/proc/array.c: tagged format for /proc/meminfo (after existing lines); new PROC_PID_STATUS. kernel/ksyms.c: add invalidate_inode_pages, __wait_on_page. net/ax25/ax25_route.c: added routing for IP datagram packets [Jonathan(G4KLX)]. net/ax25/ax25_timer.c: added DAMA support [Joerg(DL1BKE)]. net/core/dev.c: SIOCGIFCONF fix if space for under 1 device [Craig Metz]. net/core/net_alias.c: kerneld support [Andreas Schultz]. net/ipv4/igmp.c: igmp_heard_report now only calls igmp_timer_expire if tm->running is true [Christian Daudt]. net/ipv4/route.c: tunnel devices can route to gateways we can't reach. net/unix/af_unix.c: fixed a bug in connect when interrupted [Alan Cox]. Michael Chastain mec@duracef.shout.net ------------------------------ From: Terry Lambert Crossposted-To: comp.os.linux.misc,comp.os.linux.networking,comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc Subject: Re: need secure OS to entrust millions to Date: 24 Feb 1996 19:35:25 GMT mi@aldan.bu.edu (Mikhail Teterin) wrote: > > Honorable Jordan K. Hubbard > wrote on Feb 22, 1996 (in article <312D2029.FF6D5DF@freebsd.org>): > > =Don't get me wrong, I think that free operating systems are great > =(obviously) and perfectly wonderful for many things, but secure cash > =transactions and running life support systems are not the kinds of > =things I'd entrust to them, if only for pure legal liability reasons. > > There must be something wrong with the country, if decisions > are made "for pure legal liability reasons"... Yes, it must mean we have no moral foundation! Wait! Let's legislate morality! Then people will be moral because of the legal liability! Point of the matter is, legal liability is one of the risk factors you have to consider when making a business decision. ] Do not forget, BTW, about recent break-in to Citibank computers by ] a guy from Russia. I do not think Citibank was using Linux (or ] FreeBSD). So far, this looks like an attempt at urban legend creation. I haven't seen a real report on this. I did see a quite inappropriate posting to the -curent mailing list *claiming* that such a break-in had occurred. On the other hand, this could have been part of a plot to damage Citibank ...as long as we are indirectly referencing postings about plots, like the one which made the claim. If one were paranoid, one might construe the subject as a targetting mechanism for memetic broadcast. When anyone starts making claims and presumes unproven premises, you have to wonder if the claims are a subtext and the premises are the real intended message. For instance, the "Aliens meet with Bill Clinton" claim (one of my very favorites) presumes the existance of aliens. When you question it, you say "they did not" -- the "they" reference is tacit acceptance of the premise. I refuse to accept your assumed premise that Citibank was in any way compromised without independent confirmation. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: vergil Subject: Re: 1.3.67 -- beginning to look a lot..like..beta Date: Fri, 23 Feb 1996 15:13:55 -0600 Jon Mitchell wrote: > > clameter@miriam.fuller.edu (Christoph Lameter) writes: > > >Even Linus posted a message about the big problems with 67. > >Last halfway stable version in terms of network support is 57. > > Try 1.3.68 > > >We are a long way from a stable version right now. > > See above. In comparison with 67, it seems amazingly quick, the tcp > problems are gone, but I can't report on the ppp problems since I don't > use it. .68 is good stuff. I'm using ppp and it might be my imagination, but everything is a lot faster... I'm not dealing with leftover connections stuck in FIN_WAIT2 after days and days. The swapping is faster and more intelligent (IMHO). I have a fairly vanilla system, so there might be bugs that I never get to see, but I've been very pleased with my kernel. Christopher Wall ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Serios problem with e2fsck (1.01), Possible EXT2FS (1.3.66) Reply-To: pe1chl@wab-tis.rabobank.nl Date: Sat, 24 Feb 1996 22:36:23 GMT In <4gm50q$501@news.uni-paderborn.de> aurel@uni-paderborn.de (Aurel Balmosan) writes: >Hi, >I have a serios problem with e2fsck (1.01): I am using the kernel >version 1.3.66 and booted up using the boot command line: > linux ide0=serialize This doesn't look like a filesystem problem, but more like a hardware problem. The hardware is flipping bits somehow. Could be memory, disk controller, cable, disk, etc. Rob +------------------------------------+--------------------------------------+ | Rob Janssen rob@knoware.nl | BBS: +31-302870036 (2300-0730 local) | | AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU | +------------------------------------+--------------------------------------+ ------------------------------ ** 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 ******************************