Subject: Linux-Misc Digest #285
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Sat, 18 Jun 94 21:13:05 EDT

Linux-Misc Digest #285, Volume #2                Sat, 18 Jun 94 21:13:05 EDT

Contents:
  Linux and Prosonic 16 sound card (Todd M. Carrozzi)
  Re: Thanks a lot, documenters! (David Lesher)
  FOLLOWUP: RARP under Linux (MATTHEW TIPPETT)
  Re: Need recommendation for SVGA card (anos@elmrd6.ineab.ikea.se)
  Linux on the DEC Alpha (las@light-house.uucp)
  Re: Linux and Prosonic 16 sound card (James Logajan)
  MIPS board/Linux (Systemkennung Linux)
  Re: Linux on the DEC Alpha (Arthur Tateishi)
  Re: future of Unixware (Mark A. Davis)
  Re: future of Unixware (Bruce Evans)
  Minicom users unite! (Jonathan E Brickman)
  Re: Wordperfect for X-Windows (Mark A. Davis)
  HTTP with LINUX PL20 (Bill Heiser)
  <q> Linux/TMS320C30 experience ? (Tim Bass)
  Memory, buffers, etc.. (Bogdan Urma)
  Re: GNU tar-1.11.2 bugs - patch and new binary available (Christian Henry)

----------------------------------------------------------------------------

From: carrozzi@cs.buffalo.edu (Todd M. Carrozzi)
Subject: Linux and Prosonic 16 sound card
Date: Sat, 18 Jun 1994 17:31:22 GMT

     Has anyone gotten Linux to work with the Mediavision Prosonic 16 sound 
card?  The problem seems to be that the Prosonic board requires a device 
driver under dos to set up the irq and dma settings.  This means that at this 
point if I want sound under linux, I must first boot dos, and then do a warm 
boot into linux.  Has anyone found a way to work around this?  Thanks.
                                                        Todd

------------------------------

From: wb8foz@netcom.com (David Lesher)
Subject: Re: Thanks a lot, documenters!
Reply-To: wb8foz@skybridge.scl.cwru.edu (David Lesher)
Date: Sat, 18 Jun 1994 18:16:21 GMT

The BEST way to thank them is to write up something you've done,
so others  can learn from it too.

The second best way is to take to trouble to mail advice to the
next Linux'er with a problem, telling them where to look....

-- 
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close...........(v)301 56 LINUX
Unless the host (that isn't close)....kibo# 777............pob 1433
is busy, hung or dead..............vr....................20915-1433

------------------------------

From: 9208033h@levels.unisa.edu.au (MATTHEW TIPPETT)
Subject: FOLLOWUP: RARP under Linux
Date: 18 Jun 94 20:36:21 +0930

Just following up on my post about using RARP under Linux...

To date I have recieved no information on how actually use RARP under Linux
I have received a couple of use BOOTP instead, and a couple of Mail me too
messages.  But nothing telling me how to use it...

A different tack that I am about to explore is could someone supply me with
the email address of Ross Martin, the author of linux/net/rarp.c.

Either that or could he contact me.

Thanx in advance...

Matt

------------------------------

From: anos@elmrd6.ineab.ikea.se
Crossposted-To: comp.sys.ibm.pc.hardware.video
Subject: Re: Need recommendation for SVGA card
Date: 18 Jun 94 18:43:29 +0200

In article <1994Jun16.193205.14016@rosevax.rosemount.com>, grante@reddwarf.rosemount.com (Grant Edwards) writes:
> Mark van Hoeij (hoeij@sci.kun.nl) wrote:
> 
> : >   For good speed at 1024x768x256, I would suggest a 2 mb video card,
> : >S3 based
> 
> : There is absolutely no point in having 2Mb for 1024x768x256 on an S3 card.
> 
> Depends on what you're doing.  The extra memory is used by the server
> as a font cache and for pixmaps, cursors, backing store, etc.  Having
> _some_ extra memory is pretty much required, and having a bunch is
> nice.
> 
> Transfers of bitmaps between different regions of video board RAM is
> _way_ faster than going from main memory to the video board.  If there
> is enough RAM on the video board to store all of the pixmaps and fonts
> you are using, there should be a significant performance increase over
> having them all in main memory.
> 

Does this mean that changing the virtual display from 1600x1200 to 1024x768
would "free" memory to be used as font cache etc, and thus give a performance
boost ? All given that you have 2 MB video dram...
 
> : If you have an S3 with 1Mb on an ISA bus then X runs perfectly. 2 Mb won't
> : give a speedup.
> 
> Yes it should (though I haven't done any tests myself).
> 

Well, I'll give it a try on monday and see if I can notice any difference..

> --
> Grant Edwards                                 |Yow!  Where does it go when
> Rosemount Inc.                                |you flush?
>                                               |
> grante@rosemount.com                          |
-- 
  +-------------------------------------------------------------------------+
  |                     Internet anos@ineab.ikea.se                         |
  |                Phone +46-42-25 73 08, Anders Ostling                    |
  |                   IKEA Northern Europe AB, Sweden                       |
  |                                                                         |
  | + Speaking for myself, my cat, my dog and my birdie...That's all      + |
  +-------------------------------------------------------------------------+

------------------------------

From: las@light-house.uucp
Subject: Linux on the DEC Alpha
Date: Sat, 18 Jun 1994 14:24:40 GMT
Reply-To: whome!light-house!las@planix.com


In an obscure post on c.o.l.d. Linus has in effect announced that Linux
will be soon ported to the DEC Alpha.

Now, that's what I call a summer full of fun!





=============================================================================
Keyboard error: keyboard not detected. Press F1 to continue
=============================================================================

------------------------------

From: jamesl@netcom.com (James Logajan)
Subject: Re: Linux and Prosonic 16 sound card
Date: Sat, 18 Jun 1994 20:20:20 GMT

Todd M. Carrozzi (carrozzi@cs.buffalo.edu) wrote:
:      Has anyone gotten Linux to work with the Mediavision Prosonic 16 sound 
: card?  The problem seems to be that the Prosonic board requires a device 
: driver under dos to set up the irq and dma settings.  This means that at this 
: point if I want sound under linux, I must first boot dos, and then do a warm 
: boot into linux.  Has anyone found a way to work around this?  Thanks.
:                                                       Todd
I have a Logitech SoundMan 16 card, which I guess is nothing but a
relabeled Mediavision Pro Audio Spectrum 16. They, like the Prosonic 16,
use boot time configuration of dma and irq. The latest version of the
sound driver (2.5, although 2.4 may work too) supports the dynamic
configuration of the PAS 16. I got it to work (once I disabled QIC-02
support; conflict in dma/irq). Assuming that the Prosonic 16 uses the same
interface as the PAS 16 (a big assumption, I know) then you could try
rebuilding the kernel and configuring the sound driver for the PAS 16.
Use whatever irq/dma settings you use for dos. Good luck!

------------------------------

From: linux@informatik.uni-koblenz.de (Systemkennung Linux)
Subject: MIPS board/Linux
Date: 18 Jun 1994 20:40:38 GMT

A small note describing a project being started. We wish to see how much
interest exists before we start but the project will go on anyway. Test
equipment has already been ordered and programming staff allocated.

Summary: A MIPS R4x00 based motherboard and a Linux port to fit.

The board:

4 ISA, 2 VLB slots.

Level 2 cache: 0, 512KB or 2048KB.

CPU: Any R4200, 4400 or 4600 up to 200MHz.   

Price: A 133MHz R4600/512KB cache board should come about the same price  
       as a pentium board.
                      
Thanks to Linus (and the Alpha from DEC) the Linux port should be easier
than expected. Obviously this board will only interest R4x00 developers 
and RISC enthusiasts at first. At this price however the project should be
very interesting. As we have already stated, this is just to test the     
waters at the moment. If you would be interested please contact us.  

--Ralf

-- 
Ralf Baechle

Internet: linux@informatik.uni-koblenz.de

------------------------------

From: ruhtra@turing.toronto.edu (Arthur Tateishi)
Subject: Re: Linux on the DEC Alpha
Date: 18 Jun 94 20:56:22 GMT

In article <1994Jun18.142440.92@light-house.uucp>,
 <whome!light-house!las@planix.com> wrote:
>In an obscure post on c.o.l.d. Linus has in effect announced that Linux
>will be soon ported to the DEC Alpha.

Let's not exagerate here!

All he said was DEC is shipping him an AlphaPC and he intends to get
Linux running on it. No promises. No time frame. Just interesting for
other porters since Linus (who is presumably the most familiar with
the kernel) will be encountering and dealing with unportable stuff
from the kernel so porters will hopefully have an easier time of it.
This implication of "soon" has no basis in fact and there will still
be tons of work to do after a functional kernel is completed.

arthur
-- 
Choices don't scare me. However, a lack of choices does.
Arthur Tateishi                           ruhtra@turing.utoronto.ca

------------------------------

Crossposted-To: comp.unix.unixware,comp.os.linux
From: mark@taylor.infi.net (Mark A. Davis)
Subject: Re: future of Unixware
Date: Sat, 18 Jun 1994 21:06:29 GMT

terry@cs.weber.edu (Terry Lambert) writes:

>In article <1994Jun12.145821.18616@ksmith.com> keith@ksmith.com (Keith Smith) writes:
>] 2) Most USERS have no clue as to what they are using.  Give them a menu,
>] and let them do their job.  A customer Service rep is no more productive
>] on an EXPENSIVE PC or X terminal than a $400 Text terminal.

>Actually, a customer service rep who can look up part numbers without
>losing their place on an order entry screen is much more productive
>than one who has to start over because he only has one window to do his
>work in.

>Make the serial terminals multisession, and you may have an argument.

I still prefer Xterminals also, but they are more load on the system.
One *CAN* make serial terminals multisession through the PD "Screens"
app, or several commercial serial multisession products.  SCO ODT even
includes a serial multisession utility (although rather basic).

-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.infi.net           |
  \--------------------------------------------------------------------------/

------------------------------

From: bde@kralizec.zeta.org.au (Bruce Evans)
Crossposted-To: comp.unix.unixware
Subject: Re: future of Unixware
Date: 19 Jun 1994 07:12:17 +1000

In article <2tu0pv$2pf@u.cc.utah.edu>,
Terry Lambert <terry@cs.weber.edu> wrote:
>In article <1994Jun12.014115.789@ksmith.com> keith@ksmith.com (Keith Smith) writes:
>>In article <2tagvo$1qv@kralizec.zeta.org.au>,
>>Bruce Evans <bde@kralizec.zeta.org.au> wrote:
>>>Linux takes 2.8% of 486DX2/66 to run one port at 115kbaud output in raw
>>>mode.  Input takes 6.6%.  The operation is memory-bound and i/o-bound,
>>>so a 486/25 would not be much slower (4.x% for output).
>>
>>Actually this is not really true.  It _is_ much more of a hog, because
>>your logic is faulty.  You are drawing a conclusion from an irrelevant
>>fact (being i/o bound).  The CPU LOADING time is only the time it takes

[This reply is mostly to points raised by keith.  terry agrees with me
for a change :-)]

Actually, I was interpolating from other values and depending only a
little on the _relevant_ fact of being i/o bound.  Output takes 4.0% on
a 486DX/33 under FreeBSD-current.  (I only know the overheads on a
486DX/33 under linux-0.99.14, and linux-1.1.13+ has much better serial
i/o, the the old values aren't interesting.)  Output takes 2.9% on
a 486DX2/66 under FreeBSD-current.  Interpolation gives an overhead of
4.0% * 2.8 / 2.9 * 25 / 33 = 5.1% on a 486DX/25.  Oops.  It may be as
low as 4.9% when the constant i/o speed is adjusted for :-).

I measured the overheads by doing reads and writes in one process and
counting in another process while no other processes are active.

>>to respond to the interrupt, fetch the available chars, and store them,
>>and reset the interrupt.  The overall interrupt SERVICE time for the
>>486/66 (real time servicing the '550) will be significantly better due
>>to the faster memory / cache.  The I/O cycle time will be the same.  The
>>AVAILABLE cycles between interrupts will be over double on the 66.

No.  Each i/o instruction takes an enormous number of cycles away from
the cycles that are available between interrupts.  Consider outputting
16 bytes to a 16550A's fifo.  Each outb takes about 1.25 usec = 82
cycles at 66MHz.  16 * 82 = 1312.  The rest of the interrupt service
routine should take about 200 cycles + cache misses + a few more
multiples of 82 for i/o to the device.  On a 486DX/25, each outb
takes only about 31 cycles and the non-i/o part of the the interrupt
service routines takes the same 200 cycles + cache misses.  Cache
misses are hard to quantify, but are probably much less for the DX/25.

>>We are measuring CPU loading here, not thruput.  Under IX your CPU is
>>doing other things while waiting for the I/O.  A 486/66 can do a hell of
>>a lot more other things waiting for the interrupt, than a 486/25, over
>>twice as much in fact.  There is _NO_ memory binding with a reasonable

This is an argument against intelligent serial cards for 486DX2/66's.
DX2/66's may have enough cycles left over after handling a dumb card,
while DX25's may not have enough cycles left over to take advantage
of the throughput provided by a smart card.

>>>Output is much easier than input!  I doubt that any 486 can handle 16
>>>fully bidirectional 115Kbaud if it has to handle interesting protocols
>>>such as ppp or zmodem.  It would take about 20% of the system just to
>>>handle 368640 bytes of i/o if the i/o has to go through the 16-bit ISA
>>>(8 MHz) i/o ports.
>>
>>Sorry,  Those 16550 ports are NOT 16 bit.  They are 8-bit.  They also
>>run over the I/O channel which is about twice as slow as a memory mapped
>>access on an intelligent card, which _IS_ 16 bit.  Also the intelligent
>>cards generally do _not_ use interrupts.  This dramatically reduces the
>>overhead on your system, since you cut the per byte bus transfer time in
>>1/4th or better, just for starters.
>
>The assumption here is a smart card; where the bus mastering DMA transfers
>*will* be 16 bit (ISA) or 32 bit (EISA/VESA) or even 64 bit (PCI).  The

I assumed a silly interface and to emphasize the problems that the ISA
bus has with high throughputs.  To handle 360K/sec the interface and
has to start looking more like a block device for the CPU to keep up,
and even for disks the 16-bit ISA interface has a high overhead.

>>>Downloadable protocol handlers and busmastering DMA would help avoid
>>>these limits.  Do I get that for $1095?  I'd prefer extra 486 CPU's
>>>and dumb i/o ports.

Add some smileys to this.

>>You get flow control and cannonical (LD 0) processing with most of the
>>smart cards.  You generally get stuff like thru-print, and support for
>>VP/ix and merge too.
>
>Cannonical processing does nothing for me on anything but a non-raw
>terminal interface.  Modern usage of that many prots is generally for
>SL/IP, PPP, Zmodem, and other binary protocols, which by definition turn
>cannonical processing off.

I think the applications that require 96 ports are a different market.
No 486 can handle 96 simultaneous Zmodems at today's modem speeds.
However, for 96 POS terminals, the average throughput should be much
lower (how much?), and a smart card should be useful for guaranteeing
no data loss under transient high loads.
-- 
Bruce Evans  bde@kralizec.zeta.org.au

------------------------------

From: brickman@world.std.com (Jonathan E Brickman)
Subject: Minicom users unite!
Date: Sat, 18 Jun 1994 21:53:27 GMT

Any minicom users out there on Linux?  I'd be very glad to hear from you -- 
I've got some questions...
||Jonathan E. Brickman
brickman@world.std.com


------------------------------

From: mark@taylor.infi.net (Mark A. Davis)
Subject: Re: Wordperfect for X-Windows
Date: Sat, 18 Jun 1994 21:13:30 GMT

micha@mubo.saar.de (Michael Bongartz) writes:

>On Thu, 16 Jun 1994 02:29:37 GMT in comp.os.linux.misc, Mark A. Davis (mark@taylor.infi.net) wrote:
>: robp@unixg.ubc.ca (Robert Bruce Prior) writes:

>: >When I start the demo from the stock demo shell script, I get the error
>: >(in it's own box, titled "Error (1)"), "Could not create a new process --"
>: >with an "OK" box at the bottom.  Clicking on OK returns me to WP with no 
>: >problems, and the program runs *great* after that, but I am still left 
>: >wondering what it is trying to do that it can't... And if it could be a 
>: >problem with my system?

>: Not strange.  I had that error before, and I found out what it was, I
>: think.  The problem is I just can't remember!  Damn!

>Is there a little chance to remember? ;-)

Not likely :) :) :)  Unfourtunately, my brain has had one too many
core dumps.

>I've the same stupid problem here :-(

The few times it happened, it still did not hurt anything; if that is any
reassurance....

-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.infi.net           |
  \--------------------------------------------------------------------------/

------------------------------

From: bill@bhhome.ci.net (Bill Heiser)
Subject: HTTP with LINUX PL20
Date: 18 Jun 1994 22:35:03 GMT

I built a patch-level 20 kernel today, and after booting it up, found
I could not run MOSAIC or LYNX!  Actually I can _run_ them, but when they
try to reach any remote hosts, indicate that the remote document can not
be accessed.

I am able to do all other network things though, such as ftp, telnet,
archie, gopher, etc.

I am running SLIP.

I guess something obscure must have broken in pl20 (what would cause
http not to work?)

Bill

-- 
Bill Heiser:    bill@bhhome.ci.net,  heiser@world.std.com

------------------------------

From: bass@cais.cais.com (Tim Bass)
Subject: <q> Linux/TMS320C30 experience ?
Date: 18 Jun 1994 20:33:00 GMT

I am interested in doing some nice DSP projects using my Linux/P5
system as the development/interface platform to the TMC320C30.

Anyone have any experience with such a configuration of know of
any C code ftp sites, or test fixtures available?



------------------------------

From: bogdan@crl.com (Bogdan Urma)
Subject: Memory, buffers, etc..
Date: 18 Jun 1994 16:27:09 -0700



------------------------------

From: henryc@reality.UUCP (Christian Henry)
Subject: Re: GNU tar-1.11.2 bugs - patch and new binary available
Date: 18 Jun 1994 17:33:06 -0400
Reply-To: henryc@io.org

In article <2tumtp$1om@knobel.knirsch.de>,
Andreas Klemm <andreas@knobel.knirsch.de> wrote:

>I tried the patch and noticed, that it fixes many things that caused me to 
>dislike tar's with version > 1.10.
>
>Your patch also fixes the bug, that permissions weren't changed when 
>extracting an archive in the case that files and directories are already 
>present ... Permission were only extracted, when creating _new files_.
>
>But I think one important security related thing isn't fixed yet. 
>I noticed, that extracted files with unknown user id's get the number 
>as UID only then if you extract them as root.
>
>If you are a normal user, then again the files get the ownership of the
>one who is extracting the files. This is not ok. As normal user you
>shouldn't be allowed to extract files you don't own.

Why not?  What's the problem with this?

>I think standard behaviour is - correct me if I'm wrong - that only
>root is allowed to extract files with UID != your_own_uid.

That _can't_ be standard TAR behaviour; if it were, it wouldn't be around
today.  If that behaviour were true, how would a normal user unTAR a file
that he/she found on an ftp site?  The odds that the person who created the
TAR file has the same UID as the user who later unTARs that same file are
_not_ all that great.  :-)

-- 
 |  Christian Henry   //   North York, Ontario   |  e-mail:  henryc@io.org  |
 |     ``...And I raise my head and stare into the eyes of a stranger''     |

------------------------------


** 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-Misc-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: Linux-Misc@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-Misc Digest
******************************
