From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 25 Oct 93 20:13:16 EDT Subject: Linux-Development Digest #189 Linux-Development Digest #189, Volume #1 Mon, 25 Oct 93 20:13:16 EDT Contents: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Rick Frankel) Re: Bugs in Quota-Patches (SLS 1.03, 0.99pl12) (Marco van Wieringen) Re: /dev not needed? (Matthias Urlichs) Re: Can't install Yggdrasil - a workaround found. (Matthias Urlichs) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Rick Frankel) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Jerry Weiler) Nice ether card for UK (Simon Johnston) Re: IDE/interrupt latency patch (Jim Segrave) [q] status of IN2000 support? (Jerod Tufte) Re: /dev not needed? (Steef S.G. de Bruijn) Conner TapeStor support by ftape? (Erich Schikuta) A free Plan-9, anyone? (Michael K. Johnson) Real-time control from Yggdrasil Linux (Susan Fichera) ---------------------------------------------------------------------------- From: rfrankel@us.oracle.com (Rick Frankel) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: Mon, 25 Oct 1993 17:48:43 GMT DD> In article , DD> rfrankel@us.oracle.com (Rick Frankel) writes: DD>> [edited] DD>> In article koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: DD>> DD>> koenig> whats amout using 'core' as file name extension (isn't used DD>> koenig> yet), so finding *.core sould be more secure and collisions DD>> koenig> with soures wouldn't occur (if your file system supports DD>> koenig> enough characters in file names for imagename.core). DD>> DD>> Seems like a reasonable approach. DD>> DD> I would like to see something like this: DD> core\imagename, that way you could find and remove core files using DD> the command: DD> rm core\\* DD> very unlikely to have filename conflicts. DD> Dave Dunn In (email) conversation, an approach was told to me which I beleive was attributed to coherent computer- progname.core.PID This seems like the best of all, as it guarantees uniqueness and LOTS of corefiles during debugging ;) In any case, the conflict between core. and existing files is still MUCH to dangerous (just try coredumping a program called 'c' in the gcc source tree. [ I don't have it installed, so I can't tell you where core.c lives.) rick -- rfrankel@us.oracle.com richard.frankel@amail.amdahl.com ------------------------------ From: mvw@hacktic.nl (Marco van Wieringen) Subject: Re: Bugs in Quota-Patches (SLS 1.03, 0.99pl12) Date: 25 Oct 1993 18:36:43 +0100 hz225wu@unidui.uni-duisburg.de (Micaela Pantke) writes: >I spent the better part of last weekend debugging the filesystem code as >of SLS 1.03pl12 and found two major *BUGS* in the included quota >patches. (Well it is the same bug twice... but in two seperate >places.) Look for code that reads >#ifdef CONFIG_QUOTA > /* Need inode entry of directory */ > error = _namei(name,NULL,1,&ino); > if (error) > return error; >... >in the file /linux/fs/namei.c (the affected funcions are do_rmdir and >do_unlink. There is a missing iput(dir) before the return. This should >really be something like this: >#ifdef CONFIG_QUOTA > /* Need inode entry of directory */ > error = _namei(name,NULL,1,&ino); > if (error) > { > iput (dir); > return error; > } >... >Without these changes, some directory inodes get stuck in memory >with an ever increasing i_count. You cant umount a filesystem while >there are inodes with an i_count > 0 on it. >Hope this reaches the person who is doing the quota-stuff and that >I'm not wasting my efforts because I was using the SLS-distribution. Yes you have be wasting your time because this was fixed a long time ago. I just checked it on the yggdrasil CDROM in my 1.0 release and it was fixed there already. I once send out alpha-patches to Peter Macdonald which had this bug but I fixed that the day after I send out patches to all the beta testers so I realy don't know what went wrong but it should have been fixed already. People should try the quota-1.1 release and comment on that one because the old stuff had some bugs which are out of it now I hope. By the way I just wrote a simple document on how to use quota. It is still alpha (just as the code :-)) but for the people who want to take a look mail me at v892273@si.hhs.nl and I will send you a copy. By the way is anyone using the code. (Oh by counting the ones who want the code I can figure out how many want it) > Karl Guenter Wuensch > hz225wu@unidui.uni-duisburg.de Marco M. v Wieringen v892273@si.hhs.nl mvw@hacktic.nl ------------------------------ From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: /dev not needed? Date: 25 Oct 1993 12:09:43 +0100 In comp.os.linux.development, article , kevin@frobozz.sccsi.com (Kevin Brown) writes: > > The killer problem is that you have to be able to fsck your root fs, but you > *can't* unless /proc is mounted, and you can't mount /proc without the root > fs being writable, and you *don't* want to write to the root fs until you've > checked it. > This is true, but only because mount wants to write to /etc/mtab, which is not really necessary (you don't need to list /proc in /etc/mtab), and is not really necessary (you could get the stuff in /etc/mtab via a special file or directory in /proc just as easily). > Of course, you *could* have a "/dev/root" device with a special major and > minor number (say, 0 0) which the kernel understands as being the device > file for the root fs. This would have to be a real device file, not a > symlink. Then your scheme would work. :-) > This actually makes sense, because you then could boot from different devices and auto-fsck the root FS without bothering with a correct /etc/fstab. -- The good are better made by ill, As odors crush'd are sweeter still. -- Rogers -- 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: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: Can't install Yggdrasil - a workaround found. Date: 25 Oct 1993 12:16:30 +0100 In comp.os.linux.development, article , eric@tantalus.nrl.navy.mil (Eric Youngdale) writes: > > The scsi standard requires that whenever media is changed that the unit > report an error with a CHECK_CONDITION status and the UNIT_ATTENTION in the > sense data. The host is supposed to interpret this as a media change, and can > then retry the command. Since some hosts have braindead SCSI drivers which don't implement UNIT ATTENTION correctly -- most notably some Macintosh drivers --, some drives allow you to turn it off with an appropriate MODE SELECT command. -- It doesn't matter how sincere it is, nor how heart-felt the spirit. Sentiment will not endear it. What's important is the price. -- Tom Lehrer -- 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: rfrankel@us.oracle.com (Rick Frankel) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: Mon, 25 Oct 1993 18:16:36 GMT DE> The script isn't too hard period - you just have to parse the DE> output of the file command - True but, e.g.: From: bcr@bohr.physics.purdue.edu (Bill C. Riemers) BR> I know I am. The following patch makes the command "make clean" BR> --> I've modified make clean to remove core.* files, instead of core. All make `clean' will have to be modified to rm *.o, etc then execute the `rmcore' script. I don't think naming corefiles is really a bad idea, it's just that it breaks too much stuff that already exists, and requires yet one more patch to each package ported to linux. rick -- rfrankel@us.oracle.com richard.frankel@amail.amdahl.com ------------------------------ From: weiler@chocktaw.cis.ohio-state.edu (Jerry Weiler) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 25 Oct 1993 14:22:01 -0400 In article <1993Oct24.235850.4325.chiark.ijackson@nyx.cs.du.edu> iwj10@cus.cam.ac.uk (Ian Jackson) writes: In article <1993Oct22.004243.2404@cc.usu.edu>, wrote: >I would like to see something like this: > core\imagename, that way you could find and remove core files using >the command: > rm core\\* >very unlikely to have filename conflicts. Ghod! How many people a week would we see asking "I have this file called core\something, how do I remove it ?" "I can't get dbx/gdb/ups/whatever to see my corefiles." etc. This is an appallingly bad idea. Agreed. putting special characters into filenames that have to be escaped because the shell interprets them in a strange manner them is generally a bad idea. I do like the idea of putting the executable's filename into the corefile's filename, but core.filename isn't really the smartest choice. core.c, core.h, and core.5 are all valid files that you don't want an automated script to clobber. They are also possible, but unlikely filenames that a core could be dumped to, maybe destroying source in the process. I think 'core,filename' would be a better choice. No special characters that need to be quoted and automated scripts to remove cores don't get source/man-pages, either. - Jerry ------------------------------ From: skj@oasis.icl.co.uk (Simon Johnston) Subject: Nice ether card for UK Date: 25 Oct 93 15:46:26 GMT Hi, I have just got a nice ether card for Linux from a UK company GCI. The card is a longShine LCS-8634L which has emulation modes for NE1000, NE2000, WD8003 (although documentation admits this isn't so good) and WD3013, this also means 8bit/16bit selection. All configuraqtion is done via a DOS setup program and stored in EEPROM. I have it set up as a 16bit WD8013 and it works fine. The Linux 0.99.12 kernel detects and sets up a WD8013. However auto detection did get the IRQ wrong. In general I consider this a very good buy at #43 (thats 43 UK Pound). The address for GCI is GCi Unit 19 Stafford Park 12 Telford Shropshire TF3 3BJ Tel: 0952-299882 (Ask for Wayne LU) Fax: 0952-292878 Happy netting. MODULE Sig; FROM ICL IMPORT StdDisclaimer; BEGIN (* ------------------------------------------------------------------------. |Simon K. Johnston - Development Engineer |ICL Retail Systems | |------------------------------------------------------|3/4 Willoughby Road| |Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk |Bracknell, Berks | |Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084|United Kingdom | |Internal : 7621 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | `------------------------------------------------------------------------ *) END Sig. ------------------------------ From: jes@grendel.demon.co.uk (Jim Segrave) Subject: Re: IDE/interrupt latency patch Date: 25 Oct 93 09:18:39 GMT In article <1993Oct24.163229.19820@hellgate.utah.edu> bmidgley%sunset.cs.utah.edu@cs.utah.edu (Brad Midgley) writes: > >Quite a while ago, Linus was trying to improve the interrupt latency >problem in the IDE driver. What he discovered is that some braindead >drives required interrupts disabled for long intervals. He changed >the driver to work with even these drives. > >I saw a patch to enable interrupts more often during transfers on the >net digest. I was wondering if someone could point out where the >patch can be found. > >ALSO, I'd like to hear success/horror stories from people who try the >patched system on their hardware. From what I understand, the >"non-compatible" list should be short. Perhaps the kernel could have >an obscure macro to enable the improved latency? (obscure so it would >only be changed by people willing to take the chance that they'll >discover their drive is one of the braindead). > I originated these patches in the 99p9/99p10 days. From an email I sent someone else: here's the patches to hd.c as a text description of what you may need to do (I haven't got a current clean source tree to do diffs against, so if hd.c changed since then, just do this: >From email to someone else, a description of the patches and Linus' original note about these: Disc writes, particularly sync calls, seem to cause overruns more than reads do. If you are feeling brave, you can modify the source of hd.c to enable interrupts during the transfer (further disc interrupts are already disabled in the 8259). Find the occurences of port_read() and port_write() in linux/kernel/blk_drv/hd.c. Add an sti() call before each one, and for those calls which are not immediately followed by an sti(), add a cli() call just after the port_read/port_write. Warning: I've been using these patches for a few months now without incident. However, Linus posted the following comment in re. these patches: > Yes, interrupts are disabled in hd.c a bit too much, but there is > actually a reason for this: anything else seems to result in corruption > on some machines. I was playing around with interrupt latency a year > ago (how time flies), and there were terrible problems for some people > when I enabled interrupts a bit more in the actual transfer routines. > It worked for almost everybody, but the people it broke for got fs > corruption almost constantly, so... The solution for speeds over 9600 > bps is probably still to get a 16550, I'm afraid, although you can try > to enable interrupts in your personal kernel, of course. > > Linus So if you want to try this, *back up your system* and be sure you are running e2fsck on bootup, using bootutils etc. I've been using it since 18 June on several kernels without problems, so I think it's pretty safe. -- Jim Segrave (Segrave Software Services jes@grendel.demon.co.uk) ------------------------------ From: jet5@pyrite.SOM.CWRU.Edu (Jerod Tufte) Subject: [q] status of IN2000 support? Date: 25 Oct 1993 22:14:26 GMT Has any progress been made on the IN2000 scsi support? Swap drives, maybe? It used to work for me, and I now get timeouts and it doesn't recognize my Maxtor drive anymore. I get in2000_queue_command timeouts during bootup. Anyone with information of the status of this driver and/or familiarity with the type of problem I'm having, I'd appreciate a note. Thanks. Jerod -- Jerod Tufte Eat right, excercise regularly, DIE ANYWAY. jet5@po.cwru.edu tufte1@nes.nersc.gov Linux-fun on the bleeding edge. ------------------------------ From: debruijn@cs.utwente.nl (Steef S.G. de Bruijn) Subject: Re: /dev not needed? Date: Sun, 24 Oct 1993 23:58:37 GMT Just a remark here. Isn't it right that the *names* are not built in the kernel? The /dev contents is just a kind of gateway between the `outside world` and the kernel, and the names are symbolic representations of device numbers. Feel free to name your devices as you wish. The programs *and* the kernel will not complain... Steef -- S.G. de Bruijn Twente University of Technoloy, Dept. of Computer Science E-Mail: debruijn@cs.utwente.nl ##### / \ < o o > | C | Stevie "SpikerJack" de Bruijn /--\___/--\ / |o \ / /| |o |\ \ / / | |o | \ \ -- | |o | -- --------- Planning is a difficult thing... Using Linux is not! ------------------------------ From: schiki@calipso.cs.rice.edu (Erich Schikuta) Subject: Conner TapeStor support by ftape? Date: Mon, 25 Oct 1993 20:08:51 GMT Does anybody know about an ftape update, which supports the (el cheapo) Conner TapeStor (C250MQ) drive! Any info would be appreciated. ------------------------------ From: johnsonm@calypso.oit.unc.edu (Michael K. Johnson) Subject: A free Plan-9, anyone? Date: 25 Oct 93 21:13:30 GMT In article <2aagpd$af0@news.u.washington.edu> kenney@stein1.u.washington.edu (Michael Kenney) writes: Once you start adding features and *improvments* you reach a point where you just need to scrap the whole thing and start over. Yes Unix is old but compared to the alternatives it is still "state of the art". If it's a new OS you're after, it's probably better to start with a clean slate - a full redesign. A free Plan-9 anyone :-). For me, on my machines, I prefer Linux, but for those that want a clean micro-kernel based O/S, there is one in development, called VSTa. It is written with multi-processor computers in mind, and so is re-entrant at the lowest levels, and is designed for portability. It is *not* POSIX compliant, although the libraries that come with it achieve fairly close posix compliant, except for permissions, which are done via acl's, if memory serves. It is *not* "complete", last I heard, and it does *not* have the plethora of device drivers which Linux has. It may not even be publically released, and may still be only in the hands of those willing to volunteer to work on it. I don't know. If you like Mach, Plan-9, and/or QNX, and are tired of trying to bludgeon Linux into being one of those three, and then being shot down in the Linux newsgroups, try out VSTa -- you'll probably be happier. Personally, I'm quite happy with a standard monolithic kernel and all that Linux gives me, for now, and it is my opinion that if the people who *really* want a message-passing microkernel (done right this time...) instead of Linux go play with what they want to play with, there will be less friction between them and those who want to develop Linux along more "standard" lines. Please understand that I have nothing against good microkernels -- I just don't think that Linux would still be Linux if we tried to turn it into one, and I don't think that turning it into one would be what most Linux hackers and 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... Unfortunately, I can't find my documentation on VSTa at the moment, and the only thing I can find is nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) offering to pass your name along to the author of VSTa if you want to volunteer. michaelkjohnson ------------------------------ From: sfl@muttley.ucsd.edu (Susan Fichera) Subject: Real-time control from Yggdrasil Linux Date: 25 Oct 1993 21:50:14 GMT Greetings - I am contemplating the purchase of the Yggdrasil CDROM for a 386 machine. I want to use this system to control a drawing machine. In order to have realtime response, I'd like to disable kernel time-keeping mechanisms that would preempt my control process. Has anyone done this under Linux? If so, what is involved, and how far-reaching are the consequences? I'll be happy to summarize. Susan Fichera Systems Programmer UC San Diego Center for Research in Computing and the Arts ------------------------------ ** 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 ******************************