From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 28 Nov 93 12:13:10 EST Subject: Linux-Development Digest #266 Linux-Development Digest #266, Volume #1 Sun, 28 Nov 93 12:13:10 EST Contents: Re: 1542B and DSP3160 bad I/O Performance (Peter Mutsaers) Re: Berkeley Fast Filesystem (Joe Portman) Re: How many BogoMips on a Pentium? (Mike Horwath) Re: Creeping featuritis (post --rant --flame) (Elizabeth Haley) 16550 RCV FIFO's enabled? (Sam Sarmast) Re: 1542B and DSP3160 bad I/O Performance (Drew Eckhardt) Re: Errors when compiling Elm 2.4.23 under Linux? (Phillip Hardy) Re: PCI support, automatic config, Plug-n-Play (Richard Krehbiel) /dev/audio in Sound 2.0 (Larry Hiller) Re: 16550 RCV FIFO's enabled? (Tim Cutts (Zoology)) Re: Errors when compiling Elm 2.4.23 under Linux? (Ruedi Kneubuehler) Re: Creeping featuritis (post --rant --flame) (Brandon S. Allbery) ---------------------------------------------------------------------------- From: muts@compi.hobby.nl (Peter Mutsaers) Subject: Re: 1542B and DSP3160 bad I/O Performance Date: Sat, 27 Nov 1993 08:21:53 GMT >> On Wed, 24 Nov 1993 20:41:55 GMT, eric@tantalus.nrl.navy.mil (Eric >> Youngdale) said: EY> The synchronous negotiation is enabled with a jumper that you EY> set on the Adaptec - from what I recall this cannot be set via EY> software, so the kernel does not have anything to do with this EY> part. If my memory is correct, the 1542C can have synchronous EY> negotiation enabled on a device by device basis, while the 1542B EY> would have it enabled for all devices. This makes me think of a problem I have with synchronous/asynchronous (although a PC hardware newsgroup might have been more appropriate): I can enable synchronous negotiation with the 1542C's built in software. My drive says it supports 10MB/s transfer in synchronous mode (5 in asynchronous). So I try to set synchronous negotiation and set the transfer speed at 10MB/s for the 1542C. But when I do this, I get a memory parity error during booting and the system hangs. Does anyone know if I should be able to do this? -- _______________________________________________________________ Peter Mutsaers, Bunnik (Ut), the Netherlands. ------------------------------ From: baron@hebron.connected.com (Joe Portman) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 22 Nov 93 09:14:43 GMT In article <2cirua$8ob@smurf.sub.org| urlichs@smurf.sub.org (Matthias Urlichs) writes: | |Oh yes, one problem: the partitioning issue. Since *BSD uses their own |partition layout, hiding many file systems in one "real" partition (or |on the whole disk), the current in-kernel way to identify and cache inodes |by their inode and device numbers doesn't work any more. I think the Xenix |file system has the same problem. Yes, but this is trivial to implement, if you know the structure of the "divvy" table for Xenix. I have written my own patches for the Xenix divvy system that simply presents each sub-partition to the system as a block device. You can then use it as if it were a regular partition. I have not done a divvy command, since I am dual booting Xenix, and can run the "real" one. Anyhow the point is, the partitioning scheme was very easy to add to the linux kernel, probably less than 200 lines of code. |This is fixable most easily by using indirection through the superblock. If you mean indirection through the partition table, then I agree. -- ============================= Joe Portman (Westin Hotels & Resorts) NOTE: These opinions are my own and not those of my employer ------------------------------ From: root@jacobs.mn.org (Mike Horwath) Subject: Re: How many BogoMips on a Pentium? Date: 26 Nov 1993 05:19:26 GMT Mark A. Davis (mark@taylor.wyvern.com) wrote: : root@jacobs.mn.org (Mike Horwath) writes: : >I tested a Pentium for a week at my job. : >I didn't write down the bogomips cause it wasn't worthwhile to do this, : >since it is just a timer setup routine for some devices (QIC-80 come to : >mind). : > 486-DX50, 8 megs RAM, 256K cache, WD IDE drives (340, 170) : > Pentium, 8 megs RAM, 512K cache, WD IDE drive (170) : >My conclusion: It was fast, but not worth the extra cash to spend on : > it. The concurrent compile was the best I could do at multiple : It is highly unlikely that you were using a TRUE Pentium machine, with 64 : bit external access to memory (which is also laid out in 64 bits)...... : As I said once before, the Pentium is little improvement if shoved in a : typical clone motherboard of today..... : | Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 | : | Sys.Administrator| Computer Services | mark@taylor.wyvern.com .uucp | I looked at the book, it stated 64 bit memory path, and it required that I use 2 36bit simms to make a bank, which kind of fits the spec for 64 bit wide. Hope this clears up the disbelief. -- Mike Horwath IRC: Drechsau BBS: Drechsau LIFE: lover root@jacobs.mn.org drechsau@jacobs.mn.org Jacob's Ladder 612-588-0201 UUCP, UseNet, Linux files, BBS ------------------------------ Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) From: haley@scws6.harvard.edu (Elizabeth Haley) Date: 28 Nov 93 05:21:34 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >anyway. ---But your user is *still* screwed if someone used Xenix's >multivolume tar and tries to untar it on a Sun. The separate filter at least If someone is still using Xenix, drag them out of their Studebaker, and ... >(presuming GNUware, the start of this discussion) could at least be ported >and could become a de-facto standard. Like, uh, tar-1.11.2??? And again, if you achieve multivolume I/O with a separate filter, how do you get the other programs to respond intelligently when the user tries to untar something without the filter? On the other hand, it WOULD be a great idea to have a multi-volume I/O lib for storage packages, so that it would be consistant. >I was speaking of using "cat" to display files. I think of "cat" as being a >way to interpolate files into a pipeline; "more" and "less", etc. are used to >display files. While I use cat in that manner, I also use it to show small files, such as a menu, or a help screen... I also use it to look at small files of indeterminate format, so I don't have to have less clear my screen, or deal with more. >Let me rephrase: business users need, for performance reasons, things in the >kernel which could be done outside it. An example is disk mirroring: most of >*hardware*. Thankfully, RAID is now catching on in business...) Speaking of which, does RAID need to be supportted in the drivers, and if so, is anyone in the GNU, Linux or *BSD world working on it? >(The point I'm getting at is that you can do quite a few things with *ix that >seem to be commonly believed to require a microkernel architecture. But, with >or without the microkernel, the trade-off is simplicity vs. performance.) I am curious as to how useful a microkernel arch. is to Real-time applications. I would think that being able to talk very directly to a A/D converter would be very useful. >It can be argued. Heck, it HAS been argued; this is one of the primary >targets for mainframes. But commodity hardware is cheaper, and business is >now trying to find ways to optimize *that* for transaction processing in order >to "save money". ---In some ways *this* particular mess looks to me like a >comedy of errors; I don't see "downsizing" as "rightsizing" when the business >in question *needs* the transaction I/O performance of big iron. So the CPUs >are slow; but in most common transaction processing applications the >bottleneck is I/O, and *that*'s what is optimized. I question the need for "big iron" or at least the big iron we have seen. At the heart of many of those giant boxes has been the proverbial walnut sized brain. But I do agree that the current crop of bad euphamisms is cause for laughter. I think that the hardware that is about to hit the market will help the problems quite a bit, but it's going to cause a lot of MIS managers to start hiding all the computing magazines from their bosses, to cover up premature decisions. (I feel sorry for those managers who have just gotten their plans together, only to have the computer industry pop up and say "Oh, sorry, we know you've been waiting for a decade for someone to replace the AT bus, but here's the solution!" All I want is a 1024 bit bus that runs at 1 gigahertz. Pacemaker wearers, please stand back... -- Hacksaw ------------------------------ From: ssarmast@ucdacm (Sam Sarmast) Subject: 16550 RCV FIFO's enabled? Date: 28 Nov 93 04:50:29 GMT Just wondering if anyone knows if the RCV Fifo's on the 16550A are enabled in linux? I'm running pl13 and was tracing through the code (no special reason) and noticed that I don't ever see the rcv buffers of the 16550A enabled. Is this an oversight and was it intentional? By glancing at the code a little it doesn't look like it would be too hard adding the code to enable the rcv fifo's. Any thoughts? Anyone. sam ------------------------------ From: drew@kinglear.cs.colorado.edu (Drew Eckhardt) Subject: Re: 1542B and DSP3160 bad I/O Performance Date: Sun, 28 Nov 1993 06:21:25 GMT In article , Peter Mutsaers wrote: >>> On Wed, 24 Nov 1993 20:41:55 GMT, eric@tantalus.nrl.navy.mil (Eric >>> Youngdale) said: > > EY> The synchronous negotiation is enabled with a jumper that you > EY> set on the Adaptec - from what I recall this cannot be set via > EY> software, so the kernel does not have anything to do with this > EY> part. If my memory is correct, the 1542C can have synchronous > EY> negotiation enabled on a device by device basis, while the 1542B > EY> would have it enabled for all devices. > >This makes me think of a problem I have with synchronous/asynchronous >(although a PC hardware newsgroup might have been more appropriate): >I can enable synchronous negotiation with the 1542C's built in >software. My drive says it supports 10MB/s transfer in synchronous >mode (5 in asynchronous). The 1542C (nee CF) will only transfer 5M/sec across the SCSI bus, so you may or may not gain anything depending on how good the Adaptec asynchronous implementation is. >So I try to set synchronous negotiation and >set the transfer speed at 10MB/s for the 1542C. But when I do this, I >get a memory parity error during booting and the system hangs. As expected. ISA is virtually allways good to 5M/sec, anything above that is pushing it. Double that and you're out of spec. Note that the transfer speed set in the setup program is the Adaptec -> host system DMA speed, and is a totally separate issue from the Adaptec -> target speed. ------------------------------ From: phillip@mserve.kiwi.gen.nz (Phillip Hardy) Subject: Re: Errors when compiling Elm 2.4.23 under Linux? Date: Sun, 28 Nov 1993 04:59:12 GMT Peter Robinson (peter@palace.DIALix.oz.au) wrote: : greets... : having some problems when attempting to compile elm 2.4.23 under linux. : below is a cut-down log of the make process... : (pretend that Undefined Symbol: is here..) : vvvv : ../lib/libutil.a(getarpdate.o): _get_tz_mins referenced from text segment : ../lib/libutil.a(getarpdate.o): _get_tz_name referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_dayname_to_daynum referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_monthname_to_monthnum referenced from text segment : ../lib/libutil.a(parsarpdat.o): _atonum referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_timestr_to_hhmmss referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_timezone_to_offset referenced from text segment : ../lib/libutil.a(parsarpdat.o): _atonum referenced from text segment : ../lib/libutil.a(parsarpdat.o): _atonum referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_monthname_to_monthnum referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_yearstr_to_yearnum referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_timestr_to_hhmmss referenced from text segment : ../lib/libutil.a(parsarpdat.o): _cvt_timezone_to_offset referenced from text segment : ../lib/libutil.a(parsarpdat.o): _make_gmttime referenced from text segment : ../lib/libutil.a(realfrom.o): _cvt_monthname_to_monthnum referenced from text segment : ../lib/libutil.a(realfrom.o): _atonum referenced from text segment : ../lib/libutil.a(realfrom.o): _cvt_timestr_to_hhmmss referenced from text segment : ../lib/libutil.a(realfrom.o): _cvt_timezone_to_offset referenced from text segment : ../lib/libutil.a(realfrom.o): _cvt_yearstr_to_yearnum referenced from text segment : ../lib/libutil.a(realfrom.o): _make_gmttime referenced from text segment : ../lib/libutil.a(tail_of.o): _addr_matches_user referenced from text segment : ../lib/libutil.a(tail_of.o): _addr_matches_user referenced from text segment : make[1]: *** [../bin/elm] Error 1 : make[1]: Leaving directory `/home/peter/elm/src' : make: *** [all] Error 1 Hi peter can you please post a summary of any replys back to the net. as 3 of us here :) are also stumped... and i am shore lots a others on elm users will want to know how to fix it to regards. phillip hardy -- Phillip Hardy ! Std Disclamer my spelling mistakes are my ! phillip@mserve.kiwi.gen.nz ! own and do not belong to my boss (thats me!) ! phillip@kiwi.gen.nz ! -------------------------------------------- ! phillip@status.gen.nz ! Linux and proud - call +649-379-3365 to get it ! ============================================================================! ------------------------------ Crossposted-To: comp.sys.intel From: richk@netcom6.netcom.com (Richard Krehbiel) Subject: Re: PCI support, automatic config, Plug-n-Play Date: Sun, 28 Nov 1993 12:58:03 GMT In article drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes: > In article <93331.154643XXS105@psuvm.psu.edu>, > Sean Sun wrote: > >So how about it. Has any one tried the PCI machines with linux? > > Yes. > > >Does it work properly. > > Yes, although the NCR53c810 SCSI driver isn't finished yet. I read that PCI performs run-time configuration. Wouldn't this mean that things like I/O addresses and interrupts might be different between restarts, if PCI cards are added or removed? Wouldn't this be potential trouble for an OS that was designed for ISA? Which makes me wonder: is the ISA Plug-n-Play spec publicly available? How hard would it be to support? Is PCI automatic config anything like it? -- Richard Krehbiel richk@netcom.com Picture a clever one-liner here... ------------------------------ From: hiller@imager (Larry Hiller) Subject: /dev/audio in Sound 2.0 Date: 28 Nov 1993 14:19:08 GMT I've replaced the 1.0 sound driver with Hannu Savolainen's 2.0 driver in my Slackware 0.99.13 kernel. When cat'ing a long .au file into /dev/audio, after approximately 1 minute it slowly begins to garble. By the end it seems to be playing 1/2 second segments completely out of order, or delayed. It is noticable at the end where it should end in silence; instead there is silence followed by a 1/2 second segment from the song that sounds correct. On the other hand, cat > /dev/audio worked PERFECTLY in 1.0; I never even noticed the DMA clicks until I got 2.0. I have a PA *STUDIO* (A superset of the Spectrum, I believe). I compiled a partial driver, with SB and PAS support only (Digitized Speech and FM support, no MIDI, 65536 buffer). It seems to find the card; it certainly makes noise. However, /dev/audio1 and /dev/dsp1 don't seem to work, so I may have made a mistake or my hardware isn't compatible. Output of /dev/sndstat: Sound Driver:2.0 (Fri Nov 26 01:17:35 GMT 1993 root@darkstar.frop.org) Config options: 0x00000c43 Major number: 14 HW config: Type 3: ProAudioSpectrum at 0x388 irq 5 drq 1 Type 2: SoundBlaster at 0x220 irq 5 drq 1 Type 1: AdLib at 0x388 irq 0 drq 0 PCM devices: 00: Pro Audio Spectrum 01: SoundBlaster 2.0 Synth devices: 00: Yamaha OPL-3 Midi devices: Mixer(s) installed The IRQ and DMA might look funny but that's what's in my CONFIG.SYS and it works. :) I have a Micronics MB, DX/2-66, #9 GXe VLB video, WD IDE drive, 16 MB, USR Sportster Int, Logitech Serial Mouse, and Toshiba CDrom on the Sound Card (for now) ------------------------------ From: tjrc1@mbfs.bio.cam.ac.uk (Tim Cutts (Zoology)) Subject: Re: 16550 RCV FIFO's enabled? Date: Sun, 28 Nov 1993 14:21:07 GMT ssarmast@ucdacm (Sam Sarmast) writes: >Just wondering if anyone knows if the RCV Fifo's on the 16550A are >enabled in linux? >I'm running pl13 and was tracing through the code (no special reason) >and noticed that I don't ever see the rcv buffers of the 16550A enabled. >Is this an oversight and was it intentional? They are enabled on the 16550A but not the 16550. Have a look in serial.c which is where it happens. >By glancing at the code a little it doesn't look like it would >be too hard adding the code to enable the rcv fifo's. -- =============================================================================== Tim Cutts: tjrc1@mbfs.bio.cam.ac.uk | Refs 7.1 the academic reference CRC Mammalian Cell DNA Repair Research Group | database for Windows 3.1 is now Please support the Cancer Research Campaign! | on ftp.cica.indiana.edu ------------------------------ From: pingu@chg.imp.com (Ruedi Kneubuehler) Subject: Re: Errors when compiling Elm 2.4.23 under Linux? Date: Sun, 28 Nov 1993 14:31:14 GMT Peter Robinson (peter@palace.DIALix.oz.au) wrote: > greets... > having some problems when attempting to compile elm 2.4.23 under linux. > below is a cut-down log of the make process... > ../lib/libutil.a(realfrom.o): _cvt_timezone_to_offset referenced from text segment > ../lib/libutil.a(realfrom.o): _cvt_yearstr_to_yearnum referenced from text segment > ../lib/libutil.a(realfrom.o): _make_gmttime referenced from text segment > ../lib/libutil.a(tail_of.o): _addr_matches_user referenced from text segment > ../lib/libutil.a(tail_of.o): _addr_matches_user referenced from text segment i got the same problem yesterday, while compiling elm pl23. after fidling around, i saw that in the lib directory, some files are missing in the makefile. after adding the following files to the list, i got elm compiled well. get_tz.c rfc822tlen.c try this one. -- t2ul ruedi. ------------------------------ Crossposted-To: gnu.misc.discuss From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Creeping featuritis (post --rant --flame) Date: Sun, 28 Nov 1993 16:06:43 GMT In article haley@scws6.harvard.edu (Elizabeth Haley) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >>(presuming GNUware, the start of this discussion) could at least be ported >>and could become a de-facto standard. >Like, uh, tar-1.11.2??? And again, if you achieve multivolume I/O with >a separate filter, how do you get the other programs to respond >intelligently when the user tries to untar something without the >filter? Programs like tar might incorporate a mechanism to run the filter themselves (compare the "z" option to GNU tar for compression). The difference being that the filter is still an outside program; you don't need to duplicate the code for GNU cpio or dd or for some other program, and you can upgrade the filter without having to upgrade cpio, tar, dd, etc. >While I use cat in that manner, I also use it to show small files, >such as a menu, or a help screen... I also use it to look at small >files of indeterminate format, so I don't have to have less clear my >screen, or deal with more. Small files, maybe... but in that case I want it uninterpreted anyway. For indeterminate format files I *do* use paginators... because random binary characters can screw up your terminal (or xterm) rather effectively. >>*hardware*. Thankfully, RAID is now catching on in business...) > >Speaking of which, does RAID need to be supportted in the drivers, and >if so, is anyone in the GNU, Linux or *BSD world working on it? Not so far as I know. The point is to plug in a RAID array in place of an external disk, and let the array's firmware do the work. >I am curious as to how useful a microkernel arch. is to Real-time >applications. I would think that being able to talk very directly to a >A/D converter would be very useful. I have my doubts... "real-time" implies that the task talking to e.g. the A/D converter can do so uninterrupted. Which means you've shut down every other task on the system... and a lot more things are tasks in a microkernel than in a monolithic system. If what it's trying to do is capture data at high speed and write it to disk, it's got a major problem if the disk driver and/or filesystem are separate tasks which are blocked by the higher-priority real- time task. >>comedy of errors; I don't see "downsizing" as "rightsizing" when the business >>in question *needs* the transaction I/O performance of big iron. So the CPUs >>are slow; but in most common transaction processing applications the >>bottleneck is I/O, and *that*'s what is optimized. > >I question the need for "big iron" or at least the big iron we have >seen. At the heart of many of those giant boxes has been the >proverbial walnut sized brain. But I do agree that the current crop of >bad euphamisms is cause for laughter. I think you missed my point: it's not CPU power that mainframes provide, when it comes down to it; it's I/O. Faster buses will help (including both CPU- to-controller buses like PCI and controller-to-device buses like Fast&Wide SCSI-II) but there are also issues like making DMA general enough that any device can access any section of memory on demand or multi-porting main memory between the CPU and the devices. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ ** 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 ******************************