From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 16 Oct 93 08:13:07 EDT Subject: Linux-Development Digest #168 Linux-Development Digest #168, Volume #1 Sat, 16 Oct 93 08:13:07 EDT Contents: Linux-IPC-Performance (Adrian Wallaschek) Re: Questions Flamewar (Warner Losh) Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (A Wizard of Earth C) Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (Robert Moser) Re: RFD: Removal of group "comp.os.linux.development" (Kevin Brown) Re: Can't install Yggdrasil - a workaround found. (Kevin Brown) Re: [Q]Anyone working on Cyrix 486DLC cache coherency probs ? (Christopher Lau) Re: RFD: Removal of group "comp.os.linux.development" (Warner Losh) Re: The %&#$@ speaks again -or- An apology (Chris Nystrom) Re: Linux Slowly Dying Off? + Lets make a game for Linux (Chris Nystrom) ---------------------------------------------------------------------------- From: Adrian.Wallaschek@arbi.informatik.uni-oldenburg.de (Adrian Wallaschek) Subject: Linux-IPC-Performance Date: Sat, 16 Oct 1993 00:00:02 GMT Hi everybody! I'm just curios if somebody else has more experience about the SysV-IPC- implementation for Linux. I found it a bit annoying that an ordinary DECstation with a MIPS-3000 is up to 6.5 times faster on message throughput than my 483/33. (The dhrystone speaks that the machine overall is only 2 time faster!) Now as I'm talking about Linux I think of it as a more optimized and streamlined kernel than most others are! But now this advantage seems to vanish!?! I understand IPC as an indicator for the speed of kernel memory-managment and context-switching. Am I wrong ? Could somebody who knows more about this topic comment this for me, please? Please send replies to Adrian.Wallaschek@Informatik.Uni-Oldenburg.DE Please do not follow up, as I'm not regularly reading news right now, I don't wnat to miss a reply. If you mail, I'll post a summary! BTW. I use the Slackware Distribution. It's not really THE distribution I ever wanted but it shows ambitions to become that! Thanks in advance for any comments, prefect (A.Wallaschek) ------------------------------ Crossposted-To: comp.os.linux.misc From: imp@boulder.parcplace.com (Warner Losh) Subject: Re: Questions Flamewar Date: Fri, 15 Oct 1993 05:32:48 GMT ENOUGH. The volume of flames now excedes the volume of questions in the FAQ. It is time to stop. Everyone involved is the loser. There are no winners. Time to move on. I beg and implore everone to stop this childish banter. Please, take it to email, where it belongs. Or do I need to start posting the newusers messsages from net.announce.newusers here? :-( Warner P.S. Thanks to all those people that have sent me words of encouragement after my why bother post. P.P.S. Please be polite. There is no reason to flame people, even if they ask FAQ's. It is the same problem with a different face on it. -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety. ------------------------------ From: terry@cs.weber.edu (A Wizard of Earth C) Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: 16 Oct 1993 06:28:17 GMT In article pdinda+@cs.cmu.edu (Peter A Dinda) writes: > >The subject sort of is the question. By Mac FS for Linux/386BSD, I mean >a Vnode style foreign file system that can be mounted with the mount >command and is available via standard Unix file access calls. > >I am already aware of such DOS utilities as Macette and MacSEE. Would you want to read all MAC disks, or only the ones compatible with IBM hardware? If the latter, then you are limited to the 800k disks, and the answer is "not yet, but the FS specs should be available from apple.com for their FS". Note that you will either have to extend the VNOPS tabe or forget about resource forks. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: araw@elm.circa.ufl.edu (Robert Moser) Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: 16 Oct 1993 06:44:32 GMT In article <29o4a1$r6u@u.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: [material deleted] >Would you want to read all MAC disks, or only the ones compatible with IBM >hardware? > >If the latter, then you are limited to the 800k disks, and the answer is >"not yet, but the FS specs should be available from apple.com for their FS". You must mean the high density disks (1.44MB). I am a Mac developer (at work, a linuxer at home) and have the AccessPC extension on my mac. Only the high density drive can be used, and will handle high and low density PC format or Mac format. The low density drive (800K) only reads and writes mac format. PC drives can be made to read high density MAC disks, but not low density, because the low density uses a proprietary speed change to increase the disk capacity (remember the original macs, the disks were very noisy, and the different speeds were very obvious as the head moved over the disk surface.). ARAW ------------------------------ Crossposted-To: news.groups From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: RFD: Removal of group "comp.os.linux.development" Date: Sat, 16 Oct 1993 07:08:47 GMT In article <29klfv$ot5@samba.oit.unc.edu> mdw@sunSITE.unc.edu (Matt Welsh) writes: >In article <2Z7aBc2w165w@xivic.bo.open.de>, >> c.o.l.development, or "c.o.l.d" for short, is a newsgroup for >> questions and discussions about Linux kernel and systems-level >> development. Please note that this is a newsgroup about >> development OF Linux, not development FOR Linux. In other words, >>------> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I know I wrote this ("Welcome to c.o.l.*" in news.answers), but I don't >think I believe it. This was the charter of the newsgroup, and it seemed >like a good idea at the time. But I don't see any reason not to cover >Linux-specific user-code development here. Yes, theoretically, there's nothing >specific to Linux. But we all know that people use Linux and develop certain >apps for Linux that we would not otherwise be seeing; there is a certain >fervor asociated with developing applications for Linux specifically. > >I would like to open discussion on "allowing" applications development >and porting discussions on c.o.l.d. But I know that it's sure to cause >another dreaded flamewar... :) I think it would be a good idea. If experience indicates that there's too much traffic to allow easy separation of kernel development postings from application development postings, then I think it would be prudent at that time to discuss forming a new newsgroup, comp.os.linux.kernel. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Can't install Yggdrasil - a workaround found. Date: Sat, 16 Oct 1993 07:24:24 GMT In article freed@europa.orion.adobe.com (Alex Freed) writes: > >Hi gang, > >I couldn't install the Yggdrasil CD-ROM due to read errors on my CDU31A drive. >So I borrowed a TOSHIBA SCSI CD-ROM, but found problems too. > >The scsi driver uses INQURY command to determine device type. >The CD-ROM drive claims to be a DISK (type 0x00) rather than a ROM (type 0x05). >If I later mount it using /dev/sdc (I have 2 "real" scsi disks) it works, but >I still can't install Yggdrasil, because it tries to mount cd-rom as root and >doesn't give me a chance to fool the system. Interesting. Some removable media drives, like my Fujitsu magneto-optical drive, can be configured to look like a fixed disk upon a SCSI inquiry command. Did you check the DIP switches and whatnot on the Toshiba CD-ROM drive to see if this is true of it? Regardless, your patch works for you, which is sufficient. An interesting thing I've noticed about the behavior of the kernel with respect to my MO drive (and this may be generalizable to all removable media drives) is that the kernel doesn't reliably recognize that a disk change has been performed. The only way I can guarantee it gets it right is by removing the media, doing something to access the drive while there's no media in the drive, inserting the new media, and then doing something to access the drive again. Thus: [Remove media] This is your .signature virus on drugs: <> Any questions? ------------------------------ From: clau@acs.ucalgary.ca (Christopher Lau) Subject: Re: [Q]Anyone working on Cyrix 486DLC cache coherency probs ? Date: Sat, 16 Oct 1993 04:28:25 GMT df@eyrie.demon.co.uk (Derek Fawcus) writes: > In article <1993Oct8.044610.1783@falcon.DIALix.oz.au> > root@falcon.DIALix.oz.au (Darren Gilchrist) writes: > > I've seen these questions about the Cyrix chip raised a number of times, > so here's the bumph: > These seem to apply to the Cyrix Cx486DRx^2 clock-doubled part as well.. > There exist a set of configuration registers CCR0, CCR1, NCR1, NCR2, > NCR3 and NCR4 that control how the on-chip cache works. These registers > are accessed through two I/O ports (0x22 and 0x23), the first port 0x22 > is an address index register and 0x23 is a data register. > > The cache control registers are at addresses in the range 0xc0 to 0xcf, > to use them write the index into 0x22 and read/write the value from/to > 0x23. So, you have to do it in that order? Would the follow pseudo-assembly be correct: index .def 0x22 data .def 0x23 out index, 0xc0 out data, 0x13 ; this is the default setting under DOS ; do I need a NOP or something here? out index, 0xc1 out data, 0x00 ; do I need a NOP or something here? out index, 0xc6 out data, 0x00 ; disable non-cacheable region I've written a loadable module for Linux which implements something like the above. It *seems* to work (benchmark scores increase, but nowhere near what I'd expect them to..). Is there anything else I've missed out? > Register Name Index Size (bytes) > ------------- ----- ------------ > > CCR0 0xc0 1 > Configuration Control 0 > CCR1 0xc1 1 > Configuration Control 1 > NCR1 0xc4 - 0xc6 3 > Non-Cachable Region 1 > NCR2 0xc7 - 0xc9 3 > Non-Cachable Region 2 > NCR3 0xca - 0xcc 3 > Non-Cachable Region 3 > NCR4 0xcd - 0xcf 3 > Non-Cachable Region 4 > < stuff about how to define the NCR deleted > > > CCR0 is a set of bits as follows: > > BIT NAME > > 0 NC0 If 1 sets the first 64k of each 1M boundary as > non-cachable. Anyone know what the benefit of this is? I've found that under DOS, if I turn this bit *OFF*, my performance decreases a bit.. any ideas why? > 1 NC1 If 1 sets 640k to 1M as non-cachable NC1 is set by the DOS driver software.. Unix definitely won't benefit from this, but shouldn't caching the system and video ROMs improve DOS performance a bit? (my benchmarks don't show any difference) > > 2 A20M If 1 enables A20M# input (ala '486) - don't alter. > The Cyrix DOS software turns this off > 3 KEN If 1 enables KEN# input - don't alter. Ditto > > 4 FLUSH If 1 enables FLUSH# input - don't alter. This is turned on. It forces cache invalidation when DMA occurs. > > 5 BARB If 1 enables flushing of the internal cache when hold > state is entered. This is turned off- I'm not sure that it shouldn't be turned ON though.. Cyrix recommends turning it off if your system asserts HOLD too much. > > 6 CO Selects cache organisation. 0 = 2 way set associative > 1 = direct-mapped Cyric recommends using the 2-way associative, stating that the direct-mapped degrades system performance.. (if this is true, then why bother with this option??) > > 7 SUSPEND If 1 enables SUSP# input and SUSPA# output - dont alter. Turned off.. > > CCR1 is not really of interest as it controls the use of the RPLSET and > RPLVAL# output lines, these require extra hardware and on a board designed > for the Cyrix chip should probably not be touched. If bit 0 is set then > these lines are enabled. These are all turned off. > > On power up all bits are 0 except 0xc6 which is set to 0x0f thereby > disabling all caching. > My module sets this to 0 to enable caching.. > > Now to the specifics in you article: > > > The second problem is the lack of cache coherency (if it were enabled > > :-)) Because the 386 had no internal cache, there are no cache coherency > > lines such as FLUSH# etc which would be normally become activated after > > (for example) a DMA transfer on a true 486 (Oh no I hear you all say...) > > I would suggest that you enable the BARB option listed above, as this may > flush the cache whenever DMA occurs (assuming that DMA causes the uP to > enter the hold state). You could also set NC1 if and try both values in > CO to see which is best. The documentation for the Cx486DRx^2 states that the HOLD signal usually activates during DRAM refresh and bus mastering.. this would force invalidation at every DRAM refresh- so you'd effectively be without cache, since it's almost always invalid. Apparently the DRx^2 is supposed to handle cache coherency differently than the DLC (they don't say exactly how), but they don't recommend using the DLC on motherboards not designed for it.. you're supposed to get a DRx^2 instead. > > > If I shove the 486DLC detection code (Developed for SysV r4+ by Ti Kan - > > most likely req modification) into boot.S and enable caching (minus > > 640-1M limit?) and patch the enable_dma() code in include/asm/dma.h to > > disable caching during dma transfer will it work :-) Or more to the > > point, is that where it should go ? > > Certainly you'd need to use some detection code, but I'd add it to the > kernel proper (part of boot/head.S) so that if you need to use software > cache flushing you can test a variable. > > Then set some values in the registers ie, adjust the bits I mentioned > above, and change 0xC6 such that memory is cachable. You may wish to > set a non-cahable region if you have a linearly mapped video card. Well, if you're only going to be running the kernel on one machine, you can just hard-code it in as I've done... Does anyone out there have any definitive code for detecting a Cyrix 486 vs an Intel 486?? < some other stuff deleted > > PS: If Cyrix come out with a 80MHz DRu2 (to replace my 40MHz 386) at a > reasonable price then I may buy one and actually use the above. The DRu^2 was the pre-cursor to the DRx^2- the DRu^2 was a daughterboard with a clock doubler, DMA circuitry and a 486DLC. The DRx^2 apparently has all of this built-in.. The DRx^2 is $349 (20/40 MHz) or $399 (25/50 MHz) directly from Cyrix, but you can probably find it for a bit cheaper elsewhere.. So far, from my tests, there are some applications where it beats the Intel 486DX250, but in general it's anywhere between 5-20% slower.. I think the biggest market for this chip is people like me who have an old motherboard with 16 Megs of DIP DRAM.. I could get a new 486DX266 VESA LB motherboard for $300 US, but I'd have to scrap all that 16 Meg and buy 16 Megs worth of SIMMs.. let's see- 16Meg*$50/Meg=$800!! So it's still cheaper to get the Cyrix part. and it will keep my system going for another couple of years anyways.. > DF > -- > Derek Fawcus (G7FVS) df@eyrie.demon.co.uk Regards, c4 -- Christopher Lau | Dammit Jim, I'm a doctor, The University of Calgary | not an engineer! Dept. of Electrical & Computer Engg. | Well, you're an engineer now.. lau@enel.ucalgary.ca -OR- clau@acs.ucalgary.ca -OR- root@fusion.cuc.ab.ca ------------------------------ Crossposted-To: news.groups From: imp@boulder.parcplace.com (Warner Losh) Subject: Re: RFD: Removal of group "comp.os.linux.development" Date: Fri, 15 Oct 1993 17:34:09 GMT In article <29klfv$ot5@samba.oit.unc.edu> mdw@sunSITE.unc.edu (Matt Welsh) writes: >Yes, theoretically, there's nothing specific to Linux. >But we all know that people use Linux and develop certain >apps for Linux that we would not otherwise be seeing; there is a certain >fervor asociated with developing applications for Linux specifically. Hmmm. But there are things that are specific to Linux. The behavior of select comes to mind. >I would like to open discussion on "allowing" applications development >and porting discussions on c.o.l.d. But I know that it's sure to cause >another dreaded flamewar... :) I'm all for it. I'll keep doing it. There is no reason to restrict this in light of the original charter author's statements. Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety. ------------------------------ Crossposted-To: news.groups From: ccn@underg.ucf.org (Chris Nystrom) Subject: Re: The %&#$@ speaks again -or- An apology Date: Sat, 16 Oct 1993 01:31:45 GMT In article <1993Oct13.162636.8794@mulvey.com> rich@mulvey.com writes: [Edited] > The morons who post things like "My smail doesn't work. >What do I do?" have no place in any of these groups, or in society as >a whole, for that matter, until they learn how to not waste other >people's time. This is getting to be too much. I can see it now. A small huddled group of refugees in Siberia. Banished to the coldest wastelands of Siberia for the crime of failing to get smail working, and having the nerve to post to usenet to ask a question. Let us hope that the folks there in Siberia are a little kinder than they are here in comp.os.linux.* -- Underground Computing Foundation Public Access Linux -=- (512) 339-8221 ------------------------------ From: ccn@underg.ucf.org (Chris Nystrom) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: Sat, 16 Oct 1993 01:58:41 GMT In article <1993Oct13.191722.12742@rosevax.rosemount.com> grante@aquarius.rosemount.com (Grant Edwards) writes: >[regarding MS Windows] > >He's right folks. In the real world, lots (and I mean LOTS) of work >gets done using MS Windows. > >Remeber, the market doesn't go to the best solution, it goes to the >first one that's just barely good enough. Maybe, but the computer world is very Dynamic. This year's winner is next years has-been. Rember WordStar? I suspect that Linux has not caught on as much as it has is because folks do not know about it. Everyone where I work has PC's running Windows, and lately they were excited about OS/2. I took my linux disks in and loaded it up on a PC in about an hour. I quickly configured the networking, and then mounted all the disks from our Sequnet via NFS. Suddenly I got several gigs of disk space. I got eight virtual terminals. What used to be an elaborate ftp routine, can now be replaced with an mcopy from an nfs drive to a floppy, since it reads and writes dos disks. It blew them away how quick and easy it was, and I have not even installed X, or dosemu. Hmm, will they be able to telnet to my machine to run WP for dos? Should be interesting. We got a copy of SCO sitting on the shelf... -- Underground Computing Foundation Public Access Linux -=- (512) 339-8221 ------------------------------ ** 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 ******************************