Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA14851; Thu, 7 Dec 95 16:34:40 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA23824; Thu, 7 Dec 95 16:33:22 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id QAA28886 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Thu, 7 Dec 1995 16:14:05 -0500 Message-Id: <199512072114.QAA28886@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Date: Thu, 7 Dec 95 16:13:57 EST Subject: Linux-Development-System Digest #93 Linux-Development-System Digest #93, Volume #2 Thu, 7 Dec 95 16:13:57 EST Contents: tpqic02: LAST call for help (a.vignani@crf.it) Re: HELP! Linux 1.3.35 and above, and tulip.c (John Burton) Limiting diskcache/buffers? (Mikael Abrahamsson) Re: Priorities in 1.3.45? (MinnNet Office Account) Re: System does not reboot (MinnNet Office Account) ALPHA offer? (Matthias Kattanek) Help: select() system call unexpected behavior (Fabrice Franceschi) HELP! Stuck between a.out and ELF!! (Jeff Garretson) reboot/halt problems (Randall K Sharpe) Re: Standardized Printing for Linux (Tomas Vanhala) help understanding kernel code (Robert Blair) WD7193 driver ? (PCI-SCSI controller) (Dr. Christian Boettger) Re: HELP! Need restricted shell for Linux!!!!!!!! (Jeff Garretson) Re: Standardized Printing for Linux (Jim Hague) Re: Serial programming (Paul D. Boyle) ---------------------------------------------------------------------------- From: a.vignani@crf.it Subject: tpqic02: LAST call for help Date: 7 Dec 1995 10:07:26 -0500 Reply-To: a.vignani@crf.it Hello. Time goes on, and kernel versions too, but my tape still refuses to work. Setup: Archive VP 150i tape, VP402 adapter card IRQ 5, DMA 1, address 0x300 EISA bus kernel 1.3.45 /proc/interrupts: 0: 16350 timer 1: 132 keyboard 2: 0 + cascade 3: 196 3c503 5: 0 + QIC-02 13: 1 math error 14: 9062 + ide0 /proc/dma: 1: QIC-02 4: cascade /proc/ioports: ... tape is not registered 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : kbd 0070-007f : rtc 0080-009f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : npu 01f0-01f7 : ide0 0278-027f : lp 0280-028f : 3c503 02f8-02ff : serial(set) 0378-037f : lp 03c0-03df : vga+ 03f0-03f5 : floppy 03f6-03f6 : ide0 03f7-03f7 : floppy DIR 03f8-03ff : serial(set) Any attempt to a read/write operation on the tape hangs the system; the console goes forever displaying the message 'Unexpected interrupt, stat = 0x38'. Sorry to repeat this again: it works fine under MS-DOG. And it worked under 1.1.x kernels. NOW: Is there a way to (at least) stop this infinite loop and return control back to the kernel? Alberto ------------------------------ From: john@ns.gats.hampton.va.us (John Burton) Subject: Re: HELP! Linux 1.3.35 and above, and tulip.c Date: 07 Dec 1995 13:55:37 GMT In article <49q32n$evj@cmcl2.NYU.EDU> kalzus@[128.122.230.28] (Lance Kalzus) writes: Has anyone modified the tulip.c carried in the 1.3.35 kernels and above, so that it actually works? I have already tried falling back to the de4x5.c driver. But the one given in the 1.3.35 and later kernel source trees doesn't compile! The bugger never finished re-writing it properly! Okay, I have been able to use both the tulip.c and the de4x5.c driver that came with the 1.3.43 kernel. The tulip.c driver is version 0.05 and I was not able to get either the 0.07a or the 0.10 version of the tulip.c driver (obtained from cesdis.gsfc.nasa.gov) working with kernel 1.3.43. In kernel 1.3.45 *neither* the tulip.c or the de4x5.c driver that came with the kernel would compile, nor would the tulip.c v0.07a or v0.10 drivers. The *included* driver failed to compile due to a multicast_list problem. The other tulip drivers failed to compiled due to conflicting definitions for "init_etherdevice". So my wonderful SMC EtherPower PCI card is stuck with kernel 1.3.43... Just out of curiosity, *which* driver (assuming they compiled) would have the better performance, the de4x5.c, the tulip.c 0.05, 0.07a, or 0.10 ? My machine is being used as a DNS server, web server, and a file server so I need to have the best ethernet performance with the least CPU overhead and fewest bottlenecks... John -- John Burton GATS, Inc. j.c.burton@gats.hampton.va.us 28 Research Drive j.c.burton@larc.nasa.gov Hampton, VA 23666 (804) 865-7491 (voice) (804) 865-1021 (fax) ------------------------------ From: swmike@marvin.df.lth.se (Mikael Abrahamsson) Crossposted-To: comp.os.linux.misc Subject: Limiting diskcache/buffers? Date: 6 Dec 1995 00:12:57 GMT Is there any way to set a max-limit to the amount of disk-buffer that the kernel uses? My "free" output looks like this: total used free shared buffers Mem: 47516 45888 1628 14436 27588 -/+ buffers: 18300 29216 Swap: 101768 19204 82564 (when I got this output I was doing NFS-copying of slackware to local harddrive , which means it's caching a lot of data that wont ever be needed again as I won't be accessing those blocks in a long time) I don't want to have 19 megs swapped out just to have 27meg disk buffers, especially when it swaps out tasks like "netscape" that do take a couple of seconds to swap back in when I want to use it. I'd like to set the disk-cache limit to something like 5-10 megs, which in my knowledge is more than enough, as anything more than that probably isnt used much. I'm using 1.2.13+elf right now, btw. -- ===== Mikael Abrahamsson email: swmike@df.lth.se Student vid Instutitionen f|r Informatik vid Lunds Universitet, Sweden. ------------------------------ From: mno@minn.net (MinnNet Office Account) Subject: Re: Priorities in 1.3.45? Date: 7 Dec 1995 14:58:06 GMT In article <4a5hsa$j2m@questor.org>, sp@questor.org wrote: >In article , >Christopher Neufeld wrote: >> I just realized that the upgrade to v1.3.45 seems to have had an >>interesting side-effect on my pentium box. All processes are now running >>at nice level 15, and I can't renice them to anything else. I rebooted >>with the old 1.3.34 kernel, and the problem went away. Am I the only one >>who had this happen? > >Same here on an 80486, but if I tell "top" to "renice" a process showing >nice level 15, to nice level 20, I show it running at level -4. > Some kernel values have been adjusted so the process "nice" values have moved. I would get the new psproc package off of sunsite, it's in /pub/Linux/system/Misc/ps I think. Once you have it compile it and all those values should move to the right places. - Michael Frankowski ------------------------------ From: mno@minn.net (MinnNet Office Account) Crossposted-To: comp.os.linux.misc,comp.os.linux.hardware Subject: Re: System does not reboot Date: 7 Dec 1995 15:05:58 GMT In article <1995Dec7.021941.7877@3do.com>, dplatt@ntg.com (Dave Platt) wrote: >>>>It seems that the Kernel uses the keyboard controller to pulse the 'reset' >>>>line to reboot - are there PCs that do not reboot when this is done? Or >>>>is it a hardware defect? >> >>>I've seen this behaviour on some hardware platforms under SCO and Interactive. >>>It seems to be a problem related to the specific hardware platform. >> >>I have this problem intermittently on my machine and have attempted to >>fix it (the source is /usr/src/linux/arch/i386/kernel/process.c) with >>help from 'The Indispensable PC Hardware Book', but with little >>success. Something I have noticed recently is that some of the output >>is done using outb() rather than outb_p() which pauses between OUTs. >>Could this be the solution? I keep meaning to recompile the kernel and >>give it a whirl... > >It appears to be somewhat BIOS-related. >My current hunch is that the keyboard reset is throwing the system into >the ROM BIOS, and that the BIOS is getting badly confused due to the >fact that part of its memory is inaccessible. I don't know if the BIOS is confused, or just going belly up. Last time I had his problem I found that it was in 'where' the reset was being done, is it in the Chipset or the keyboard BIOS. The chipset tends to work, while the keyboard BIOS might cause the machine to go belly up and lock. Check in your BIOS for the "Fast reset" option... - Michael Frankowski ------------------------------ From: Matthias Kattanek Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware Subject: ALPHA offer? Date: Wed, 06 Dec 1995 17:37:42 -0800 HI THERE, Somebody released lately an offer about Dec ALPHA machines. Unfortunately my copy is lost and it "timed out" in the news groups. I appreciate any repost or mail it to "mattes@ugraf.com" matt -- EUROPEAN MIKROGRAF CORP. Tel: 408-461-6061 Fax: 408-461-6056 SUPPORT:support@ugraf.com FTP://ftp.ugraf.com HTTP://www.ugraf.com ------------------------------ From: Fabrice Franceschi Crossposted-To: comp.os.linux.development.apps Subject: Help: select() system call unexpected behavior Date: 6 Dec 1995 23:36:12 GMT Hi all I'm facing a problem when using select(). Basically, when I do a select() after a sendto(), the select does not have the expected behavior. Instead of waiting for the end of the timeout, it exits right away claiming there is something to read, which is wrong since nothing is sent to this processus. The exact same code works as expected on SunOS, Solaris, HPUX and Data General Aviion. I have no idea of what can be wrong. I'm running Linux Kernel 1.2.8 and libc.so.4.5.26. The same problem appears under Caldera and Infomagic. Is there anything special I should do under Linux or is this some kind of known problem? Any help would be greatly appreciated. Fabrice Franceschi. ------------------------------ From: Jeff Garretson Subject: HELP! Stuck between a.out and ELF!! Date: Wed, 6 Dec 1995 00:05:11 -0800 Oh ye who are wiser than I, On Nov. 18 I upgraded my system to ELF (following the ELF-HOWTO), and everything went fine, including the reboot soon thereafter. And everything worked well until Friday, Nov. 24. Then my system crashed and refused to reboot, stopping just after "Mounted root filesystem read-only" or some such. After seven days, a case-and-a-half of Pepsi, and countless failed attempts later, I have been able to restore the system almost completely, with the exception of the ELF upgrades to the /lib directory (and corresponding /sbin/ldconfig and /etc/ld.so.cache). ELF upgrades under /usr (a different partition) are intact. I'm almost certain that the culprit is /lib/ld.so version 1.7.3, because everything works fine until I install that, at which point my machine starts complaining about /etc/ld.so.cache having the wrong version. (I know the README says that's normal. There's more to it than that.) Deleting ld.so.cache and then running "ldconfig -v" doesn't help. The weird thing is, it worked fine for six days before the system crashed (I'm not sure to what degree the two problems are related). I'm stuck somewhere in between a.out and ELF -- a.out binaries work, but ELF binaries (fortunately, not many yet) don't. Whenever I try to run an ELF binary, I just get a "command not found" message (even though "which" returns the correct path name). Worst of all, gcc is ELF, and thus doesn't run. Also, some of my non-ELF stuff just breaks at random. Xdm doesn't recognize the "#ifdef COLOR" line it its config file. Man broke with something about a formatting or display program not working. Rebooting fixed man but not xdm. In general, the system seems almost stable, but not quite. Does anyone have any suggestions, hints, words of wisdom? Here's what I'm using... o Linux kernel 1.3.28, compiled with ELF support using gcc 2.5.8 o Most other relevant stuff is from an InfoMagic Slackware distribution that came with my "Using Linux" book, from sometime early this year. o Basic System: P90, 16MB, 1.2GB Western Digital EIDE, Matrox Millennium, SMC ethernet card. Nothing unusual. Here's what I used to upgrade to ELF... o binutils-2.5.2l.17.bin.tar.gz o libc-5.0.9.bin.tar.gz o libg++-2.6.2.5.bin.tar.gz o gcc-2.7.0.bin.tar.gz o ld.so-1.7.3.tar.gz all from ftp://ftp.cc.gatech.edu/pub/Linux around mid November. Thanks in advance... ======== Jeff Garretson jeffgarr@u.washington.edu System Administrator. Help Desk Staff. Masochist. (oh, yeah...and student...) ------------------------------ From: Randall K Sharpe Subject: reboot/halt problems Date: 7 Dec 1995 18:48:50 GMT Hi, I am running linux v 1.2.13 and am using dip to make slip connection to work. I nfs mount a disk on my workstation so that I can share calendar data, mail, etc. However, when I reboot, it appears that it kills all the processes namely dip BEFORE executing rc.K ( and hence umounting the nfs filesystems). Is there a way to turn this around ? Isn't this all in telinit or something ? Is there a source version I might hack up to fix this problem ? If so where (if sunsite give the path please). If it is a standard source package tell me the name and I can probably find it. Thanks -- --- Randy Sharpe email: rsharpe@ncsa.uiuc.edu homepage: http://www.ncsa.uiuc.edu/People/rsharpe Research Programmer National Center for Supercomputing Applications ------------------------------ From: vanhala@cc.helsinki.fi (Tomas Vanhala) Subject: Re: Standardized Printing for Linux Date: 7 Dec 1995 22:10:21 +0200 In <4a4nss$jj5@josie.abo.fi> mandtbac@news.abo.fi (Mats Andtbacka) writes: >Dave Carrigan, in <4a2vl3$fr7@dragon.nofc.forestry.ca>: >>mandtbac@news.abo.fi (Mats Andtbacka) writes: >>>What you need here is a PCL (or whatever) driver for groff. >>>Or, hell, a dvi or TeX driver for groff. That's going the awkward way >>>around, I know, but... >>In fact, there is a dvi driver for groff: >Colour me embarrassed. Time to settle down with the various groff >manpages and try to figure that system out, I suppose... In fact there's even a PCL driver for groff. The following announcement was on gnu.announce for not very long ago: GNU groff version 1.10 is now available for anonymous ftp from prep.ai.mit.edu:/pub/gnu/groff-1.10.tar.gz. New in this release is a postprocessor for the HP LaserJet 4 and compatibles. -- Tomas Vanhala vanhala@kruuna.helsinki.fi Tel. (90) 191 22097 http://www.helsinki.fi/~vanhala/ ------------------------------ From: rebcdf@cdfsga.fnal.gov (Robert Blair) Subject: help understanding kernel code Date: 07 Dec 1995 18:18:25 GMT This may be slightly misposted, but I don't know where else to try (suggestions are welcome). The APM patches don't quite work on my laptop (more direct postings have failed to zero in on any valuable hints on why). I'm willing to try to figure out why, but need a little more information on the GNU assembler/GCC interface to do it. I have looked at the gas man and info pages and they help, but leave a few critical details out. Maybe some kind soul who knows the answer will take a minute or two to clue me in so I can make some progress on this: 1) What does the syntax "%%cs:_variable" mean? For example the APM patches define the far call to the APM 32 bit BIOS functions in the following snipit of code: __asm__ __volatile__( \ .. some obvious assembly language code .. "lcall %%cs:_apm_bios_entry\n\t" \ .. more obvious assembly stuff .. : "ax", "bx", "cx", "dx", "si", "di", "bp", "memory") 2) How would one verify that the above "lcall" is really jumping to the BIOS entry point? The system runs fine, it's just that the results ONLY get updated in /proc/apm (where the results of this call show up) when the system is awakened from a power down. This is very mysterious, and I just wanted to start by "printk"ing the address of the call whenever this call is made in the kernel code. 3) What conditions (processor set up done in the kernel) are required for such a "lcall" to actually succeed? In other words what should the routine invoking this assembly code be doing to assure that the call goes to the right place and the BIOS can do what it needs to correctly assess the power status? Thanks for any advice -- *C~o~()* Cc{*(o~*Q& Bob Blair ( (( ) |~ ~ | Argonne National Lab. |O - | High Energy Physics Div. \ " / 9700 S. Cass Ave. \ **** / Argonne, IL 60439 **^u^** Phone (708)-252-7545 ***** E-Mail: reb@hep.anl.gov *** fnald::rebcdf ------------------------------ Date: 07 Dec 1995 18:29:00 +0100 From: roo@wombat.han.de (Dr. Christian Boettger) Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc Subject: WD7193 driver ? (PCI-SCSI controller) (Mail written on 07 Dec 95 at 18:24) Hello, is anyone out there developing such a driver? To be a bit more specific: this is what my standard Linux 1.2.13 kernel (Slackware / SuSE) says: Dec 6 21:09:24 YoMama kernel: bios32_init : BIOS32 Service Directory structure at 0x000fb300 Dec 6 21:09:24 YoMama kernel: bios32_init : BIOS32 Service Directory entry at 0xfb7a0 Dec 6 21:09:24 YoMama kernel: pcibios_init : PCI BIOS revision 2.10 entry at 0xfb7d0 Dec 6 21:09:24 YoMama kernel: Probing PCI hardware. Dec 6 21:09:24 YoMama kernel: Unknown PCI device. PCI Vendor id=101c. PCI Device id=3296. Dec 6 21:09:24 YoMama kernel: PLEASE MAIL POTTER@CAO-VLSI.IBP.FR your hardware description and /proc/pci. [F. Potter replied that he will include the device info into the kernel 'real soon'] so here I go: it's a Gibabyte PCI Pentium Board (Award Modular BIOS v4.50PG Intel 8243x PCI-ISA BIOS v.2.19 ) and the PCI hardware in question is a WD7193 PCI SCSI Controller (8bit according to the manual) with an on-board BIOS: WD 7193 PCI-SCSI HBA Adapter Version 1.00 BIOS Version 1.04.64 Setup Version 1.01 (c) Western Digital 1995 the WD BIOS Setup Program displays PCI BUS 0 PCI DEVICE 9 SCSI ID 7 and although the WD BIOS Setup program claims the bios version to be 1.04.64, the boot message from the WD BIOS says: Western Digital SCSI BIOS, v1.05 Part Number 75-001043-004 164 on the chip is printed: > WDC 33C296A-ZX 00-01 9514 D 39323S1-1721 under DOS, the BIOS extension of the WD Adapter is reported to be loaded into Segment C800 and it's size is reported to be 17kB. Hope this helps..... and someone will write a driver .... Christian -- Dr. Christian Boettger, Lessingstrasse 14, D-31275 Lehrte, Germany email: home: roo@wombat.han.de work: boettger@HMI.de, cxb@phadfa.ph.adfa.oz.au WWW: http://www.hmi.de/~cbu/cb/cb.html >>>>>>>>>>>>>>>>> PGP public key available as return receipt<<<<<<<<< ------------------------------ From: Jeff Garretson Subject: Re: HELP! Need restricted shell for Linux!!!!!!!! Date: Tue, 5 Dec 1995 23:31:14 -0800 On Tue, 5 Dec 1995, Dion Hollenbeck wrote: > You might have told us what you wanted it restricted to. However, why > not write your own. The beginning project for my UNIX for Systems > Programmers was to write a shell. When you write it, you can just > make a list of commands that you will allow the user, and not execute > any others. It is not too difficult, even to implement pipes and > redirection. Heck, you might be able to adapt "smrsh" (Sendmail Restricted Shell) to suit your needs. Smrsh is distributed among other sendmail stuff, I think (I forget where I first got it). You could just compile it with "-DCMDBIN=\"/etc/restricted-bin\" or some such path, and create the directory /etc/restricted-bin and populate it with links to commands that are allowed. Call the binary something like /bin/restricted-sh-guts. Finally, you would need to write a front-end for it. It could be as simple or complicated as you need, using a menu and/or command line interface. In any case, when the user gives a command, just have it call "/bin/restricted-sh-guts -c $command". I haven't tried this myself, but it shouldn't be too tough. ======== Jeff Garretson jeffgarr@u.washington.edu System Administrator. Help Desk Staff. Masochist. (oh, yeah...and student...) ------------------------------ From: jim@oxfordcc.co.uk (Jim Hague) Subject: Re: Standardized Printing for Linux Date: 7 Dec 1995 10:25:20 -0000 In article , Peter Dalgaard BSA wrote: >BTW, could someone with Windows insight tell us how and when, if ever, >it avoids dumping bitmaps of the picture to the printer? I.e. in what >ways could a generic windows driver for - say - a DeskJet print images >faster than a PostScript one? Oh, I wouldn't want to imply it images faster, only that the image is built up with PCL commands in exactly the same way as it would be with Postscript. So drawing coded with MoveTo(), LineTo() and the rest is passed to the driver, which then can either translate into appropriate PCL/Postscript/whatever or render itself and sling bitmaps around. The only point I wanted to make was that the programmer (generally speaking) writes one piece of code to render the image and uses this code on both printer and screen, and if anybody was contemplating a root and branch revision of Linux/X printing some input on how it happens elsewhere would be valuable. It's not intended to be a critism of the current situation at all. Doesn't mean I would rather be using Windows, though :-) Windows is what I do for work, Linux is for pleasure (and in many cases getting useful work done that can't be done sensibly with Windows - this message comes to you via Linux/Inews/Diald...). -- Jim Hague - jim@oxfordcc.co.uk (work), bears@cix.compulink.co.uk (play) ------------------------------ From: boyle@laue.chem.ncsu.edu (Paul D. Boyle) Subject: Re: Serial programming Date: 7 Dec 1995 20:08:50 GMT David Bashaw (dbashaw) wrote: : I have been trying to do some serila programming in a TCL script. Not very : sucessfully though. I seem to be able to receive data just fine, but : I can not : send data out. I can't figure out how to tell if data is being held due to a : control signal in the wrog state. [snip] : My tcl script just issues an open command on /dev/cua0 which seems to work. : After that I use read commands to get data and puts to write. : Before doing any : reads or writes I use stty on /dev/cua0 for the raw mode. Issuing a flush on : the file after doing a write doesn't help. This sounds to me like you need to check the file permissions on your /dev/cua0 file. You need write persmission to write to the file. Later, Paul ------------------------------ ** 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 ******************************