From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 27 Oct 93 13:13:13 EDT Subject: Linux-Development Digest #193 Linux-Development Digest #193, Volume #1 Wed, 27 Oct 93 13:13:13 EDT Contents: Re: GCC 2.4.5.... how do I compile the !@#$ thing? (Dan Odom) Linux file system for OS/2: info requested (Jeff Garzik) Re: A free Plan-9, anyone? (Yves LACHANCE) Re: Bugs in Quota-Patches (SLS 1.03, 0.99pl12) (Marco van Wieringen) Re: Lots of zombies with ALPHA-pl13j (David Barfoot) Hitachi CD-ROM Driver (Wolfgang Thoene) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Matthias Urlichs) Writing CD-ROM Device-driver (Wolfgang Thoene) Re: GCC 2.4.5.... how do I compile the !@#$ thing? (Jeremy Bettis) FASYNC (Chuck Fee) NFS bug (and hacky fix...) (James Hightower) Re: Slowness in scsi disk access (Michael O'Reilly) Re: Andrew File System (Markus Nullmeier) 2.88MB support? (was Re: 1.72MB floppies) (al-b@minster.york.ac.uk) Intel EE 16, register/progr. docu, driver Re: Slowness in scsi disk access (Wayne Schlitt) ---------------------------------------------------------------------------- From: danodom@matt.ksu.ksu.edu (Dan Odom) Subject: Re: GCC 2.4.5.... how do I compile the !@#$ thing? Date: 26 Oct 1993 12:20:07 -0500 amodra@lands.sa.gov.au writes: >Compile and install them, then recompile gcc to use the latest >libraries with: > make distclean > configure --target=i386-linux --prefix=/usr > make CC=/usr/bin/gcc CFLAGS=-O2 LDFLAGS=-s > make install >Of course, it's a lot simpler just to get the latest binaries of >everything :-) Yes, it is. Where are they? Not any place obvious on TSX-11. All I can find there are the sources. -- Dan Odom danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS Member of the League for Programming Freedom ------------------------------ From: gtd543a@prism.gatech.EDU (Jeff Garzik) Crossposted-To: comp.os.linux Subject: Linux file system for OS/2: info requested Date: 26 Oct 93 05:59:53 GMT Reply-To: gtd543a@prism.gatech.edu I am considering writing an OS/2 IFS that would read linux partitions natively. Unfortunately, I don't run linux and don't know where the source code for the most commonly used filessystem is. I would appreciate it if anyone can direct me to the filesystem source code and any accompanying document. Thanks! (Follow-ups directed to e-mail b/c I don't read these newsgroups) -- Money is the root of all evil, and man needs roots ------------------------------ From: yveslach@binkley.cs.mcgill.ca (Yves LACHANCE) Subject: Re: A free Plan-9, anyone? Date: 26 Oct 1993 18:09:22 GMT Eric Jeschke (jeschke@cs.indiana.edu) wrote: >johnsonm@calypso.oit.unc.edu (Michael K. Johnson) writes: >:users want, and it is *certainly* not what Linus wants, if he still >:feels as he did during his famous "discussion" with Andrew S. >:Tannenbaum, who told Linus that he would have flunked him in an >:Operating Systems class... >Interesting. I'd like to see a transcript of that discussion >if it was online. I bet others would too... Yes, I too would be interested in that transcript. -- Yves Lachance Montreal, Canada ------------------------------ From: mvw@hacktic.nl (Marco van Wieringen) Subject: Re: Bugs in Quota-Patches (SLS 1.03, 0.99pl12) Date: 26 Oct 1993 20:12:08 +0100 >I have another bad error with enabled quota. Every time I get an >uucp login over a serial line the system freezes during the >logout procedure. If I log in using this line with any human id >everythings works ok. All logins on local vc's are OK, too. Can you be more specific about what happens, I will take a look but a bit more specific error makes life much easier. >I think it has something to do with id's below some value, I think >it was 100. It is 10 and can be changed with the define in the linux/quota.h header file. But uid and gids below 10 should have quotas don't you think so. Mostly root and the daemons are there so why bother normal users start much higher. >These accounts doesn't get any limitation or so and there >might be an error. Perhaps someone already found it? The previously See above it's not an error but why should we bother about thos id's. Quota for root is impossible even on BSD systems, because with the quota struct for root we pass on expire times to the kernel. >posted patch didn't influence this behavior, BTW. Marco. M. v Wieringen v892273@si.hhs.nl mvw@hacktic.nl ------------------------------ From: david@brede.demon.co.uk (David Barfoot) Subject: Re: Lots of zombies with ALPHA-pl13j Date: Tue, 26 Oct 1993 18:49:37 +0000 Byron Thomas Faber (bf11620@ehsn3.cen.uiuc.edu) wrote: : root@darktower.wastelands.com (System Administrator) writes: : >Anyone else had a problem with loads of zombies forming with pl13j? [stuff deleted] : There is a reason for calling it Alpha you know. Meaning, it probably : has bugs. Which he acknowledged in his post. He only seemed to be checking if it was a problem peculiar to his system. If bugs aren't aired then they don't get fixed! David. ------------------------------ From: thoene@woto.oche.de (Wolfgang Thoene) Subject: Hitachi CD-ROM Driver Date: Mon, 25 Oct 1993 21:56:17 GMT Hi folks i use an Hitachi CR3500 CD-ROM drive. This drive uses an interface-card that uses no interput (it's an polling device). Because i've an detailed tech. discription of the commands ... of the drive i'd like to write an device drive for the drive. I know need an small smaple device driver that uses polling and not interups i just readed the kernel-driver-handbook from the doc project and think i could do the work. Because i've no ftp access please mail sources . thanks in advance Wolfgang Thoene ============================================================================ Wolfgang Thoene | thoene@woto.oche.de Plauenerstr.29 | Member of Individual Network e.V 50170 Kerpen | Germany ================================+=========================================== -- Wolfgang Thoene | thoene@woto.oche.de Plauenerstr.29 | Member of Individual Network e.V 50170 Kerpen | Germany ================================+=========================================== ------------------------------ From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 26 Oct 1993 10:34:37 +0100 In comp.os.linux.development, article <13326@dirac.physics.purdue.edu>, bcr@bohr.physics.purdue.edu (Bill C. Riemers) writes: > > CORE = core.{[ab,d-g,j-r,t-z,AB,D-G,J-R,T-Z,0-9]*,[chsCHS]?*} > Ugh. ;-) > > needs to be used... I know I would much prefere to have core as an > extention to going through all these acrobatics in a "rm" command. > True. I haven't seen any objection to naming the corefile of "foo" "foo.core". -- An air traffic robot named Speigal Brought down an American eagle, A perfectly darling Little brown starling, And Jonathon Livingston Seagul. -- G. A. Mason -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 ------------------------------ From: thoene@woto.oche.de (Wolfgang Thoene) Subject: Writing CD-ROM Device-driver Date: Mon, 25 Oct 1993 22:17:29 GMT Hi folks i use an Hitachi CR3500 CD-ROM drive. This drive uses an interface-card that uses no interput (it's an polling device). Because i've an detailed tech. discription of the commands ... of the drive i'd like to write an device drive for the drive. I know need an small smaple device driver that uses polling and not interups i just readed the kernel-driver-handbook from the doc project and think i could do the work. Because i've no ftp access please mail sources . thanks in advance Wolfgang Thoene ============================================================================ Wolfgang Thoene | thoene@woto.oche.de Plauenerstr.29 | Member of Individual Network e.V 50170 Kerpen | Germany ================================+=========================================== -- Wolfgang Thoene | thoene@woto.oche.de Plauenerstr.29 | Member of Individual Network e.V 50170 Kerpen | Germany ================================+=========================================== -- Wolfgang Thoene | thoene@woto.oche.de Plauenerstr.29 | Member of Individual Network e.V 50170 Kerpen | Germany ================================+=========================================== ------------------------------ From: jbettis@cse.unl.edu (Jeremy Bettis) Subject: Re: GCC 2.4.5.... how do I compile the !@#$ thing? Date: 26 Oct 1993 23:33:43 GMT danodom@matt.ksu.ksu.edu (Dan Odom) writes: >amodra@lands.sa.gov.au writes: >>Of course, it's a lot simpler just to get the latest binaries of >>everything :-) >Yes, it is. Where are they? Not any place obvious on TSX-11. All I >can find there are the sources. /pub/linux/packages/GCC isn't obvious enough?? All the binaries and sources there together in that one directory. -- Jeremy Bettis -*- Jerbo Jehoshaphat -*- University of Nebraska INET: jbettis@cse.unl.edu "Those who stand in the middle of the UUCP: jerbo@tddi.UUCP road are often hit by passing cars." Running Linux .99p13 Free Unix for i386/i486/Pentium machines. Ask me how. ------------------------------ From: fee@cxf111.rh.psu.edu (Chuck Fee) Subject: FASYNC Date: 27 Oct 1993 00:33:05 GMT I'm trying to compile isode-8.0 and the compile is havnig problems with FASYNC, which is not defined in any Linux header file but exists under SunOS 4.1.3 Does Linux support asynchronous I/O signals ? (which is what my miniscule knowledge of such things leads me to believe that is what FASYNC means) if not, is there a workaround for this?? --chuck -- Chuck Fee UN-altered REPRODUCTION and DISSEMINATION of this fee@cxf111.rh.psu.edu IMPORTANT Information is ENCOURAGED. ------------------------------ From: jamesh@netcom.com (James Hightower) Subject: NFS bug (and hacky fix...) Date: Wed, 27 Oct 1993 02:42:43 GMT I ran into a problem mounting a filesystem on one Linux machine from another Linux machine. The server side would report "Got a udp packet for no socket!", (using net-2-debugged, net-2 was silent) and of course the mount would never happen. It seems that get_sock (called by udp_rcv) would do: if (ip_addr_match(s->daddr, raddr) == 0) continue; only daddr was our LOOPBACK address, not our IP address! I think this was caused by th line: if (chk_addr(daddr) == IS_MYADDR) daddr = my_addr(); int rt_route (in route.c), as my_addr always returns the loopback address. Removing this linu causes a system hang. Changeing the line if (ip_addr_match(s->daddr, raddr) == 0) continue; to /* Worra Hack! FIXME!!! */ if ((ip_addr_match(s->daddr, raddr) == 0) && (!(chk_addr(s->daddr) == IS_MYADDR && (chk_addr(raddr) == IS_MYADDR)))) continue; in sock.c allows NFS to work. My question is; is it safe to accept every packet with any of our addresses on it? And if so, do we have to do the ip_addr_match here? or do we really need to take the "daddr = my_addr()" reference out of route.c and fix whatever that breaks? Or do I just have some file screwed up somewhere and all this isn't necessary at all? JJH -- "And what about Niomi?" ------------------------------ From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: Slowness in scsi disk access Date: 27 Oct 1993 03:15:34 GMT Piercarlo Grandi (pcg@aber.ac.uk) wrote: : >>> On Mon, 25 Oct 1993 16:50:24 GMT, eric@tantalus.nrl.navy.mil (Eric : >>> Youngdale) said: : Eric> [ ... ] While I was playing with the simulated iozone through my : Eric> model, I noticed that at one point the program really slowed down : Eric> like it was hitting a brick wall. The simulated I/O rates dropped : Eric> from something in excess of 1Mb/sec to something close to : Eric> 32Kb/sec. The cause in this particluar instance was quite simple : Eric> - the first 2/3 of the buffers in the free list were dirty, and : Eric> each time we call getblk we end up traversing all of these to : Eric> locate a clean buffer. : Use a free list. It IS using a free list. Have you looked at the kernel source?? Some stats I collected over the last day. (on 8 megs of ram) 96.7% of getblk() requests find the buffer they were looking for in the cache. Of the remainder. 13.8% use the first buffer on nthe free list. : Eric> [ ... ] It takes something like 50ms to scan 15000 buffer headers : Eric> like I have on my system, so this overhead can eat you alive. : So don't do it. This is trite and stupid. it doesn't normally search all the buffers, thats just the worst case and there IS no way around it. A much-vaunted 'free list' doesn't help if it's empty. : Flushing every 30 sec. or was OK on a PDP-11 with 64 buffers if one was : lucky. With several thousand one should do like SVR[34], and have a : flushing daemon that sweeps cyclically thru the buffers and cleans them : incrementally. As other people have mentioned, this is a good idea. Implementation anyone? :) : Eric> 3) The handling of multiple block sizes is still not quite right. : Multiple block sizes are a stupid idea. They just complicate life and : reduce random access performance. Given that the SCSI drivers can do : scatter/gather and mutiple sector read/writes in one go, clustered : allocation and reading/writing are much better alternatives. To make : life easier for pseudo scatter gather for those controllers that don't : have it, clustered buffer block allocation in memory should be done : too. o Backward compatabilty dictates support for 1K block sizes. o Speed dictates a need for supporting larger block sizes in the future. ============== Some stats I collected over the last day. (on 8 megs of ram) 96.7% of getblk() requests find the buffer they were looking for in the cache. Of the remainder. 15.5% use the first buffer on the free list. 62.4% are satisfied out of the first 40 buffers 90.4% are satisfied out of the first 100 buffers. 96.6% are satisfied out of the first 200 buffers. with an average cache size of 2212 buffers. Draw your own conclusions. :) ------------------------------ From: m147150@urz-mail.urz.uni-heidelberg.de (Markus Nullmeier) Subject: Re: Andrew File System Date: 27 Oct 1993 08:30:48 +0100 >From: Gary Keim > urz.uni-heidelberg.de ^this AFS cell crashed every few weeks (at least until some weeks ago ;-) >That's quite a few nowhere's. AFS is said to be phased out by DFS, part of OSF's DCE 1.?. People have asked about a specification of AFS, but Transarc was unwilling/unable to provide anything but their proprietary source code. Full compatible AFS source code must not exported outside the USA/Canada because of the well- known DES export restrictions. The Newsgroup for AFS is alt.filesystems.afs, there a couple of months ago John F. Carr of MIT summarized a evaluation of AFS with something like "a) AFS filesystems are not Unix filesystems b) the implementation quality of AFS is poor" The last time this thread came up somebody posted that the AFS/NFS translator was barely usable for Linux because of bugs in the translator or AFS. Most users tend to be happy about all the features AFS promises when they start using AFS, but a significant number of people are seriously hacked off after some months of adminstering or using AFS. Markus Nullmeier m0meier@sun0.urz.uni-heidelberg.de ------------------------------ From: al-b@minster.york.ac.uk Subject: 2.88MB support? (was Re: 1.72MB floppies) Date: 26 Oct 1993 13:33:28 GMT In article <1993Oct25.160316.5784@sun0.urz.uni-heidelberg.de> geyer@polyhymnia.iwr.uni-heidelberg.de (Helmut Geyer) writes: >David C. Niemi (niemidc@oasis.gtefsd.com) wrote: >:>In article 93Oct21174240@prao.ens.fr, rideau@ens.fr (Francois-Rene Rideau) writes: >:>> >:>> My 0.99.9 had 1.72MB floppy support (i.e. I could mknod a /dev/fd0H1722), >:>>and used it much (together with the DOS FDFORMAT utility). But I upgraded >:>>to 0.99.13), and I can't have this device anymore. I looked in .../floppy.c, >:>>and no 1.72MB floppy format was found. I was disappointed, but happily found that >:>>Linux could still read (but not format - I must use DOS 8( ) my fdformatted >:>>floppies. >:>> Why is that ? > >I have updated the patch (which did not need much changing) against pl12 and pl13. >If you want it, mail me. I never had any problem (other than media failures >of older disks) using this patch. > >:>> Can I add an entry in floppy.c ? >:>> What values must I give to the gap1 and gap2 fields ? > > Helmut > >[deleted a lot] What about support for 2.88MB drives? Is that in the kernel now, or is it a patch? I am still using a 0.99.9 kernel with the 1.72MB patch, as I still haven't decided on how to upgrade... Andrew. P.S. I haven't been able to check the FAQ, as the recent post of it was corrupt here and I don't have the disk space to FTP it at present :-( ------------------------------ From: albrecht@igpm.rwth-aachen.de () Subject: Intel EE 16, register/progr. docu, driver Date: 27 Oct 1993 09:36:04 GMT Who has documentation (registers/programming) at hand for Intels EthernetExpress 16 card? (Intel EE 16 for Thin/Thick Ethernet = BNC or tranceiver). I've read that there is an alpha release driver avaiable - it is in the SLS package? (if yes, where?) Harald Albrecht albrecht@igpm.rwth-aachen.de Institut fuer Geometrie und Praktische Mathematik RWTH Aachen, Bundesrepublik Deutschland ------------------------------ From: wayne@backbone.uucp (Wayne Schlitt) Subject: Re: Slowness in scsi disk access Date: Wed, 27 Oct 1993 13:44:33 GMT In article <2akp4m$igh@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes: > : Multiple block sizes are a stupid idea. They just complicate life and > : reduce random access performance. Given that the SCSI drivers can do > : scatter/gather and mutiple sector read/writes in one go, clustered > : allocation and reading/writing are much better alternatives. > > o Speed dictates a need for supporting larger block sizes in the > future. No, larger block sizes do not appear to be a good idea. Instead, you should cluster reads and writes. The articles that Piercarlo Grandi quoted gives a nice discussion on _why_ larger block sizes are the wrong way to go... -wayne ------------------------------ ** 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 ******************************