From: Digestifier To: Linux-Activists@senator-bedfellow.mit.edu Reply-To: Linux-Activists@senator-bedfellow.mit.edu Date: Tue, 24 Aug 93 20:13:07 EDT Subject: Linux-Activists Digest #165 Linux-Activists Digest #165, Volume #6 Tue, 24 Aug 93 20:13:07 EDT Contents: /bin/pwd missing in SLS 1.02 (David Wright) Re: SCSI Performance (Yet (Mark Lord) Re: PS/2s are not all microchannel!! Does Linux work on these? (Michael Griffith) IDE Performance! (was Re: SCSI Performance (Yet Again)) (Mark Lord) Thinkpad compatible? (Paul Wood) Re: SCSI Performance (Yet Again) (Brandon S. Allbery) Magic (LSI layout editor) on Linux (Hyeongil Kim) Re: ** xboard 2.1 compiled ? ** (Michael Boesch) 1542B & > 16mb RAM dies (John Will) Re: SCSI Performance (Yet Again) (Brandon S. Allbery) Re: TAMU.99p4 won't see BOCA 14.4 internal (Ian Justman) Re: twm window manager question (Tom LaStrange) Re: TAMU.99p4 won't see BOCA 14.4 internal (Ian Justman) Re: SCSI Performance (Yet Again) (Howlin' Bob) Raw devices (was Re: SCSI Performance (Yet Again)) (Frank Lofaro) SLS1.03 & SLS1.02 (Narinder Jain) Re: How to run XS3 and X386mono(hga) simultaneous (David E. Wexelblat) ---------------------------------------------------------------------------- From: dmw@prism1.prism1.com (David Wright) Subject: /bin/pwd missing in SLS 1.02 Date: 24 Aug 93 19:11:47 GMT It appears that the "pwd" command is missing from SLS 1.02. This may be because "pwd" is a shell built-in in most modern shells, and so it wasn't thought to be needed. But if you run other software (like many Perl scripts, Metaconf, Autoconf, etc), they depend on there being a real "pwd" program available in the path. The two ways I have been using to get around this is to either edit the offending script and change references to "pwd" into "sh -c pwd", or to create a scipt called "pwd" that just contains "pwd". Does anyone know of a real C program for Linux to do this, so you don't have to pull in all of bash just to get it to print out the current directory name to stdout? Seems like it would be simple to write, and pretty small (the SCO version is only 4k, so I would expect the Linux version to be that size or even smaller). Dave -- ____________________________________________________________________________ | /\ / | Prism Computer Applications | David Wright | | -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM | | /____\ | Lakewood, OH 44107 USA | 216-228-1400 | ------------------------------ From: mlord@bnr.ca (Mark Lord) Subject: Re: SCSI Performance (Yet Date: Tue, 24 Aug 93 20:23:28 GMT >GIVE THAT MAN A CIGAR! I was watching from the sidelines, wondering when >someone was going to figure this out. :-) I've done similar test with >MS-DOS, and caching will actually hurt you with monster sequential files. Depending on the caching algorithms.. under MS-DOS, a top-of-the-line cache program (HYPERDISK) will still be faster in this case, as it has an option to merge multiple writes to the same sector(s). Thus, it would eliminate MANY MANY updates to the FAT, at the risk of losing data in a power crash under certain circumstances. -- mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482 ------------------------------ From: grif@ucrengr.ucr.edu (Michael Griffith) Subject: Re: PS/2s are not all microchannel!! Does Linux work on these? Date: 24 Aug 93 21:08:01 GMT In article bj@hatch.socal.com (Sohar Inc.) writes: [deleted] > >I installed the latest release of Linux SLS on my PS/2 M40. >Rather, I tried. After detecting nearly everything correctly >(right down to the soundcard) it tried to read my floppy disk >(which it identified correctly), but then it barfed trying to >read sector 2, the driver recalibrated, then it tried 4, and >0, reporting a 'floppy I/O' error each time. > Are you sure you have a good floppy? Sounds like bad media to me. -- Michael A. Griffith grif@cs.ucr.edu ------------------------------ From: mlord@bnr.ca (Mark Lord) Subject: IDE Performance! (was Re: SCSI Performance (Yet Again)) Date: Tue, 24 Aug 93 20:51:59 GMT In article bill@goshawk.lanl.gov writes: >In article ws@xivic.bo.open.de (Wolfgang Schelongowski) writes: > How about > date;dd if=/dev/sda of=/dev/null bs=131072 count=512;date ... > That took 69 seconds => 950 KByte/sec for raw I/O. Under BSDI, > the numbers are 36 seconds on /dev/rsd0a => 1820 KByte/sec. ... >wazoo!). Killing all extraneous processes, I get 61s => 1100 Kb/sec - =============================================================================== Try these numbers for a comparism: Motherboard: Micronics 486/33Mhz ISA with 64KB mem cache and 12MB 80ns ram. Interface: Cheapie all-in-one 16-bit ISA IDE+2S+1P+G. Linux: 0.99pl12+ with latest goodies & libs, EXT2, no SCSI /usr/bin/iozone Version 1.14(?) compiled with -O6 -m486 -DUSE_FSYNC Drives: (0): WD4200 "Piranha" (IDE, 202MB, 13ms, 3600rpm?, 64KB cache/buffer) Test#1: iozone with 20MB file write: 40sec, 515KB/sec = 0.502MB/sec read: 40sec, 524KB/sec = 0.512MB/sec Test#2: time dd if=/dev/hda of=/dev/null bs=1024k count=100 read: 104sec(real), 984KB/sec = 0.960MB/sec (1): Micropolis M2112A (IDE, 1001MB, 10ms, 5400rpm, 256KB cache/buffer) Test#1: iozone with 20MB file write: 21sec, 992KB/sec = 0.968MB/sec read: 23sec, 902KB/sec = 0.880MB/sec Test#2: time dd if=/dev/hda of=/dev/null bs=1024k count=100 read: 70sec(real), 1462KB/sec = 1.428MB/sec Notes: 1. "KB" = 1024 bytes; "MB" = (1024 * 1024) bytes. 2. Therefore "MB/sec" = ("KB/sec" / 1024). 3. Spindle speed (rpm) is a major contributing factor in most systems. 4. The M2112A literature claims up to 5.6MB/sec at the interface. 5. The "new" M2210A/S drive (970MB) is different from the M2112A/S. -- mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482 ------------------------------ From: pcwood@astro.ocis.temple.edu (Paul Wood) Subject: Thinkpad compatible? Date: 24 Aug 93 19:05:01 GMT Hello, Does anyone know if linux is compatible with the 10Base2 Type II ethernet card which may be ordered with the IBM ThinkPad? -- -=( Paul Wood )=- -=( pcwood@astro.ocis.temple.edu )=- -( If you can't hear me, it's because I'm in parentheses )- ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: SCSI Performance (Yet Again) Date: Tue, 24 Aug 1993 22:07:27 GMT In article <110135@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >>/dev/hda is still buffered... Linux doesn't have raw disk devices. I haven't >>yet figured out why there's so much resistance to adding them. > >I don't see any resistance. Just because Linus hasn't done it doesn't >mean he won't let them in. Everyone's busy. Would you write them? >It shouldn't be too hard. There are usually quite a few comments about how they aren't worth doing or worth using when I bring them up... and I do know of a use. Database managers. We've discussed ports of commercial software in this group before; you aren't likely to see a serious commercial DBMS until raw devices are supported. The reason being that buffer management which is optimized for one method of access is often lousy for others (e.g. sequential vs. random) --- the *ix buffer management method strikes a good balance between them for most files, but leaves something to be desired for large databases, so most commercial DBMSes have a means of running on a raw device *and implementing their own buffer management*. The result is a considerable speed improvement, unless raw devices are broken (I've seen that! --- a kernel patch to Plexus's SVR2 increased database access speed about 5-fold). Or missing, in which case you take a double speed hit because the OS and the DBMS are both doing buffering... the OS doing so sub-optimally. (Yes, I know the commercial DBMSes can run with the databases in ordinary disk files. But for *serious* use they use raw devices.) I keep threatening to implement raw devices --- eventually I will find the time to do so. ++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 ------------------------------ From: hkim@oahu.cs.ucla.edu (Hyeongil Kim) Subject: Magic (LSI layout editor) on Linux Date: Tue, 24 Aug 93 22:15:15 GMT Hi. Is there anyone successfully running Magic on Linux? Or are there any ftp sites with Magic for Linux? Thanks in advance. Hyeongil Kim CS dept. UCLA ------------------------------ From: root@exodus.abg.sub.org (Michael Boesch) Subject: Re: ** xboard 2.1 compiled ? ** Date: Mon, 23 Aug 1993 08:09:15 GMT andreas@knobel.gun.de (Andreas Klemm) writes: >laurentj@gnlab032.grenoble.hp.com (Laurent_Julliard) writes: >>Hi ! >> Did anybody already try to compile xboard version 2.1 pl11 ? gcc doesn't >> want to compile the parser.c file because of a "parse" ;-) error. >> Any clue appreciated. >I removed some lines from the lex source ... Finally I got it compiled. >Unfortunately xboard hangs when trying to make some moves on the board. >Any help would be welcome ... The LEX-File in xboard needs a _real_ LEX, that means it isn't working with FLEX. I've used the LEX on a SUN to generate parse.c from parse.l, took it home on my linux machine and compiled xboard without any problems and it works fine. Bye Mike -- Michael Boesch root@exodus.abg.sub.org "God not only plays dice, He sometimes throws the dice where they cannot be seen." (S. Hawking) ------------------------------ From: john.will@satalink.com (John Will) Subject: 1542B & > 16mb RAM dies Date: 24 Aug 93 16:59:00 GMT I'd like to hear from anyone running the released 99pl12 kernel with the memory allocation patch and the Adaptec 1542B and over 16mb of RAM. I have been unable to achieve reliable operation with that configuration, even though I've beat the machine to death. I can run any other program, and usually Windows 3.1 will find any bad memory for me. :-) The problem is that Linux will just die with a SCSI host timed out error, and then there is no recovery. I'm thinking this may be related to the double buffering required for greater than 16mb, since I can compile the kernel for a 16mb limitation, and all is well, no other changes. I've tried with 20mb and 32mb, neither works for very long. I've swapped ALL the memory around, and I'm running with known good memory in the machine... Any insights would be appreciated. ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: SCSI Performance (Yet Again) Date: Tue, 24 Aug 1993 22:21:55 GMT In article <1993Aug24.220727.8357@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >In article <110135@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >>mean he won't let them in. Everyone's busy. Would you write them? >>It shouldn't be too hard. > >I keep threatening to implement raw devices --- eventually I will find the >time to do so. I should add: it *is* somewhat difficult. You see, one of the other performance increases in raw devices is that they do I/O directly from the user's buffer --- thereby saving a copy to kernel space and possible sleep on available memory. On *my* system this won't cause a problem; I only have 12MB. But on a 32MB ISA machine the driver had better check the physical address of the user's buffer and do a copy if it's over 16MB, or things will go BOOM! Not to mention the 64K boundary problem... I think SCO copies the data anyway to avoid this. (Hm. Maybe it's not useful after all --- on this braindamaged architecture, at least. Grrr.) ++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 ------------------------------ From: ianj@netcom.com (Ian Justman) Subject: Re: TAMU.99p4 won't see BOCA 14.4 internal Date: Tue, 24 Aug 1993 22:27:05 GMT Brandon S. Allbery (bsa@kf8nh.wariat.org) wrote: : In article <1993Aug8.035049.13316@citrus.SAC.CA.US> ianj@citrus.SAC.CA.US ( Ian Justman ) writes: : >You do not really need to worry about the printer port's interrupt since Linux : >never uses it anyway. All SoundBlaster-supporting software uses IRQ7, though : The current Linux parallel driver knows how to use the interrupt, but it has : to be enabled. You need to get the lpirq package to enable it, or write your : own program to use the LPSETIRQ ioctl. Hmmmm. You've piqued my curiosity. I don't suppose one could use the parallel interrupt AND a soundcard simultaneously... ------------------------------ From: toml@blade.Boulder.ParcPlace.COM (Tom LaStrange) Subject: Re: twm window manager question Reply-To: toml@boulder.ParcPlace.COM Date: Tue, 24 Aug 1993 21:01:33 GMT In article <1993Aug21.152334.25413@mnemosyne.cs.du.edu>, zevans@nyx.cs.du.edu (Zack Evans) writes: |> In article , |> Robert Nation wrote: |> |> >I'm not really the expert, but here's a whack at answering your |> >questions: |> |> >vtwm? I think I may have heard of this, don't know anything about it. |> |> Does everything tvtwm does only better. No 3d appearence on that either, but |> if I wanted that I'd intall windows (only kidding Rob :) ) Does everything fvwm |> does as well. The biggest difference between tvtwm and most of the other virtual window managers is in how they implement the virtual desktop. tvtwm will be able to pan around the desktop much faster although you typically won't notice any speed difference unless you have a lot of windows on your screen. tvtwm also introduces a few problems because of the way it implements the virtual desktop. -- Tom LaStrange toml@boulder.ParcPlace.COM ------------------------------ From: ianj@netcom.com (Ian Justman) Subject: Re: TAMU.99p4 won't see BOCA 14.4 internal Date: Tue, 24 Aug 1993 22:37:12 GMT Brandon S. Allbery (bsa@kf8nh.wariat.org) wrote: : In article <1993Aug8.035049.13316@citrus.SAC.CA.US> ianj@citrus.SAC.CA.US ( Ian Justman ) writes: : >You do not really need to worry about the printer port's interrupt since Linux : >never uses it anyway. All SoundBlaster-supporting software uses IRQ7, though : The current Linux parallel driver knows how to use the interrupt, but it has : to be enabled. You need to get the lpirq package to enable it, or write your : own program to use the LPSETIRQ ioctl. Oops... I goofed earlier. I should have mentioned that I already have other IRQs being used, see below: IRQ2: Everex EV-811 QIC-02 tape drive controller (intercepted in software as IRQ9) IRQ3: Reserved for COM2 (/dev/cua1), a modem IRQ4: Reserved for COM1 (/dev/cua0), my Logitech mouse IRQ5: Mitsumi CD-ROM drive, an LU-002S which works just fine under version 0.3 of the Mitsumi driver; haven't found an audio CD player program yet, so HELP!!!! 8-bit card, BTW. IRQ6: Reserved for diskette IRQ7: The duelin' IRQs; in this corner, the noisy, the earful, SOUNDBLASTER! In this corner, a guy who's up to his ears in paper, LPT1!!!!! All kidding aside, it would be nice to get my 'Blaster and my printer to work on the same interrupt. However, if anyone knows whether a 16-bit card can be had for my Mitsumi, I'm prettu much stuck. Thanks for your attention. ------------------------------ From: gt8134b@prism.gatech.EDU (Howlin' Bob) Subject: Re: SCSI Performance (Yet Again) Date: 24 Aug 93 23:32:47 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >I should add: it *is* somewhat difficult. You see, one of the other >performance increases in raw devices is that they do I/O directly from the >user's buffer --- thereby saving a copy to kernel space and possible sleep on >available memory. This gets ugly if you request reads or writes that cross page boundaries. As we all know, the PC doesn't have virtual DMA... >On *my* system this won't cause a problem; I only have 12MB. But on a 32MB >ISA machine the driver had better check the physical address of the user's >buffer and do a copy if it's over 16MB, or things will go BOOM! Not to >mention the 64K boundary problem... I think SCO copies the data anyway to >avoid this. (Hm. Maybe it's not useful after all --- on this braindamaged >architecture, at least. Grrr.) I would tend to agree, unless these programs will be cooperative. There could be a kernel call to implement some sort of contiguous low-16MB memory allocation, so that the application gets part of its address space remapped to a physically contiguous range of pages which lie below the dreaded 16MB DMA cutoff. Using this space as a buffer would make kernel copyins and copyouts unnecessary. I'm sure we're all retching by now, but there *is* a way to do it. I think it's not worth it; copying from kernel space is probably cheaper. And to tell you the truth, I don't think we'll ever see a large DBMS for Linux ever, raw devices or not. DB people want numbers to call for quick and reliable service. Can we give them one for Linux? -- Robert Sanders Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b Internet: gt8134b@prism.gatech.edu ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Raw devices (was Re: SCSI Performance (Yet Again)) Date: Tue, 24 Aug 93 23:06:54 GMT In article <110135@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: > >>/dev/hda is still buffered... Linux doesn't have raw disk devices. I haven't >>yet figured out why there's so much resistance to adding them. > >I don't see any resistance. Just because Linus hasn't done it doesn't >mean he won't let them in. Everyone's busy. Would you write them? >It shouldn't be too hard. ^^^^^^^^^^^^^^^^^^^^^^^^^ Care to say that again??? ;) Try passing ll_rw_blk() a buffer not gotten by getblk(). I don't think you'll get too far (I tried everything). I might try it again, this time using something other than ll_rw_blk(). No promises tho! > >Not that they're all that useful anyway: speed tests and mkfs/fsck are >about the only uses I can think of, but I'll be happy to hear of >others. > >-- >Robert Sanders >Georgia Institute of Technology, Atlanta Georgia, 30332 >uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b >Internet: gt8134b@prism.gatech.edu ------------------------------ From: jainn@robadome.com (Narinder Jain) Subject: SLS1.03 & SLS1.02 Date: 24 Aug 1993 18:55:42 -0500 Reply-To: jainn@robadome.com Is there an easy way to find out the difference between the 2 version. I would rather not download all the files. Any help in this matter will be appriciated. Thanks NJ ------------------------------ From: dwex@mtgzfs3.att.com (David E. Wexelblat) Subject: Re: How to run XS3 and X386mono(hga) simultaneous Date: 24 Aug 93 17:36:21 GMT In article fset@guug.de (Fachschaft E-Technik TUM) writes: > dwex@mtgzfs3.att.com (David E. Wexelblat) writes: > > >In article <1993Aug23.115316.19644@diomedes.robots.ox.ac.uk> jon@robots.ox.ac.uk (Jon Tombs) writes: > >> In article fset@guug.de (Fachschaft E-Technik TUM) writes: > >> >I want to run two X-Servers (XS3 and X386mono( on a hercules card)) > >> >simultaneously. However, when i start the second Server, it starts up fine, > >> >but clears the screen of the other X Server. It doesn't matter, whether > >> >i start XS3 or X386mono first. Has anyone an idea how to solve this problem? > >> > >> I didn't believe you could even have the two cards in the same machine. > >> The s3 provides full hercules compatability - and by doing so uses the same > >> io addresses as the hercules. You are getting a lot of IO address clash, > >> I'm not aware of anyway to tell the S3 to disable the hercules io ports. > >> > >> Jon. > >> > >> > > >This is where the magic bit in the MiscOutReg comes into play, Jon. All > >SVGA cards that I know of provide full Herc backwards compatibility. And > >CGA, too. If the MiscOutReg is set to color mode, then the mono ports > >are disabled, and you can use a herc along with the SVGA. Similarly, if > >you set the MiscOutReg to mono mode, the SVGA can coexist with a CGA > >card. This is how the two-headed mono server works (the SVGA mono > >mode is actually 16-color mode, with only one bit-plane turned on). > > >But the bottom line is that what he wants to do is impossible. Or at > >least a rediculous amount of work. The problem is that IBM, in its > >infinite wisdom, has the bit order backwards between the packed-pixel > >and bit-plane modes. An X server can't support two bit orders. So the > >only way to get things to work would be to swap all the bits around for > >one screen on the other. No, thanks. Not today. > > You don't understand my problem fully. I don't want to run one X-Server > with my Hercules and my S3, but actually two X-Servers, one for the Hercules > and one for the S3. > > But i think, i know the source of the problem, but that doesn't help me much > in the way of a solution. The culprit, i think is XS3, which is derived from > Xfree1.2, which isn't able to handle virtual Terminal support. > > > ------------------------------------------------------------------------------ > Clemens Huebner fset@guug.de > Giessuebl 4 (crh@guug.de) > 8088 Eching a.A > Germany Linux -- the free 32-bit OS > ++4981431480 > ------------------------------------------------------------------------------ No. There is no way you can run two server simultaneously on different VTs and have them both function at the same time. When you switch VTs, the server on the other VT is deactivated. The only way this can ever work is if both screens are controlled by the same server. Which will never happen, for reasons described above. -- David Wexelblat (908) 957-5871 Fax: (908) 957-5305 AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ 07748 XFree86 requests should be addressed to "Shining, flying, purple wolfhound, show me where you are." Yes, "Yours Is No Disgrace" ------------------------------ ** 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-Activists-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux) via: Internet: Linux-Activists@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 tupac-amaru.informatik.rwth-aachen.de pub/msdos/replace The current version of Linux is 0.99pl9 released on April 23, 1993 End of Linux-Activists Digest ******************************