Subject: Linux-Development Digest #807
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Wed, 8 Jun 94 21:13:06 EDT

Linux-Development Digest #807, Volume #1          Wed, 8 Jun 94 21:13:06 EDT

Contents:
  Re: Linux and net status checker? (Dale Shuttleworth)
  Re: Linux game development (Was Re: Why [DOS, W (Alan Cox)
  URGENT: Serious bug in 1.1.17 pty handling (Joerg Pommnitz)
  Re: Linux game developmen (Riku Saikkonen)
  Re: SVNet Meeting/Program, Wednesday, June 15, 1994  7:30pm, Mountain View (FREE) (Adrian Filipi-Martin)
  Device or resource busy (repost) (Richard Whittaker)
  Re: 1.1.17 and no networking won't compile (Jon Hamilton)
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Re: Serial drivers in 1.1.16 (autoconfig for IRQ's) (John Lellis)
  Re: Serial port - 1.1.18 (John Lellis)
  NCR PCI SCSI 53c810 (Evmorfopoulos Dimitris)
  Re: Filesystem semantics protecting meta data ... and users data (Rob Janssen)
  Re: Linux game development (Was Re: Why [DOS, W (Jay "Thierry" Han)

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

From: dale@mipc-03.brunel.ac.uk (Dale Shuttleworth)
Subject: Re: Linux and net status checker?
Reply-To: ee90dcs@brunel.ac.uk
Date: Mon, 6 Jun 1994 20:24:38 GMT

Hi,

I'm not really sure that this is a development question but:

Richard Whittaker (rwhittak@orion.docwhitehorse.doc.ca) wrote:

: I'm running this box on a fulltime SLIP connection, however, the folks that
: Iget the connection from fiddle with the router that I connect to
: occasionally.. What I'm looking for is some method to make sure that the
: link between myself and the router (over the SLIP link) is still viable, and
: exit with a status level if it's not.. This status level would enable the
: system to enact a set of instructions to re-establish the link to the remote
: end. 

Have you considered ping?

                Dale.
--
******************************************************************************
*  Dale Shuttleworth                                                         *
*  Dept of Elec Eng,  Brunel University, Uxbridge, UB8 3PH, UK               *
*  ee90dcs@brunel.ac.uk                                                      *
******************************************************************************

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: Tue, 7 Jun 1994 17:18:08 GMT

In article <2t11lr$g7k@usenet.INS.CWRU.Edu> mdz@po.CWRU.Edu (Michael D. Zoran) writes:
>    I think a unix like system or a time sharing system is simply a bad
>enviroments for games.  Simply put, most of the good games are written in
>assembly, take over the entire machine, and usually completely bypass the
>OS and access the hardware directly to give optimal performence.  This in

I spent six year fighting this crap writing Amiga games. The times you need
to take the machine over are very few and far between. Games like Elvira
don't take over the machine for example.

Remember DOOM was originally written on a Next - most real flight sims are
running under Unix or a unix-like OS.

Take it from me - Svgalib under linux is __fast__ and the mitSHM extension to
X is almost as quick. Granted my game goes slower if I go off and do something
else but at least I can. I regularly play xinvaders while the machine is
ticking over mail and running the http server with no problems


Alan



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

From: jpo@informatik.tu-chemnitz.de (Joerg Pommnitz)
Subject: URGENT: Serious bug in 1.1.17 pty handling
Date: 7 Jun 94 16:50:58 GMT

Hello all !

I think I have to report a serious bug I have found with linux 1.1.17.
Software:
        * Linux 1.1.17 + ide performance patch 2.0
        * libc 4.5.26
        * XFree86 2.1
        * bash 1.14 
        * rxvt 1.90
Hardware:
        * noname i386, 4M RAM, Seagate 120M IDE HD, nearly 4M swap partition

Description:
        The problem occurs when starting X. This is a true stress test given my
        current hardware. xinit is configured to start 3 rxvt's, xclock and twm.
        This usually takes some time, but later the system is quite usable
        for xdvi and ghostscript. With my recent upgrade from 1.1.11 to
        1.1.16 and later to 1.1.17 the terminal emulations are often unusable.
        The following cases were observed:
                * 3 rxvt's with a shell prompt in each of them => no problem.
                * 1 rxvt with one shell prompt, one rxvt with 2 shell prompts
                  and one blank rxvt
                * 2 blank rxvt and one rxvt with 3 shell prompts
        It's possible to kill the unusable terminal emulation. Depending on
        the number of shell prompts, the blank terminals disappear, too. 
        Killing such an rxt results in the Kernel message:
        pty->count = 2 or
        pty->count = 3
        This is a message from linux/drivers/char/pty.c: pty_close. Sorry,
        I'm posting this from memory, so the exact message text may differ 
        a bit, but I'm sure it's exact enough to find the source code position.
        I have not tested 1.1.18 until now, but from reading the diffs 
        the tty code doesn't change, so the bug should still be there. 


        Since the exact error is somewhat nondeterministic, I think it's
        a race condition in the new tty code. Might be, nobody has seen
        this  until now, because on normal machines (not underpowered) the
        causing condition is very unlikely. In this case it might be 
        reproducable under heavy load and with more concurrently starting 
        pty applications.

                                                Hope this helps
                                                   Joerg

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

Subject: Re: Linux game developmen
From: riku.saikkonen@compart.fi (Riku Saikkonen)
Date: Wed,  8 Jun 94 17:43:00 +0200

>    I think a unix like system or a time sharing system is simply a bad
>enviroments for games.  Simply put, most of the good games are written in
>assembly, take over the entire machine, and usually completely bypass the
>OS and access the hardware directly to give optimal performence.  This in

Then again, DOOM! was originally written for NeXTStep... And is being
ported to Linux, from what I've heard (from
comp.sys.ibm-pc.games.announce (I'm not 100% sure of the newsgroup name
right now; moderated anyway))! This was just confirmed by someone from
ID software with a post, I noticed...

(and there are, of course, games like Nethack or MUDs...)

The problem with DOS is its real-modeness. Programs have to constantly
switch in and out of protected mode, just to access DOS calls. And the
extenders add quite some overhead. As an example, POV-Ray is
significantly faster in Linux than in DOS (built with the Intel icb),
no doubt because of the better memory use.

-=- Rjs -=- riku.saikkonen@compart.fi
GCS/O -d+ p c++(+++) l++ u e m++@ s/- n+ h-- f+ !g w+ t(-) r !y(*)
"Yet neither by wolf, nor by Balrog, nor by Dragon, would Morgoth
have achieved his end, but for the treachery of Men." - J.R.R. Tolkien


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

Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development
From: adrian@mo.cs.wm.edu (Adrian Filipi-Martin)
Subject: Re: SVNet Meeting/Program, Wednesday, June 15, 1994  7:30pm, Mountain View (FREE)
Date: Wed, 8 Jun 1994 14:56:45 GMT

In article <jmonroyCr2636.Gvu@netcom.com>, jmonroy@netcom.com (Jesus Monroy Jr) writes:
|>  
|> FUTURE TALKS:
|>     July 20th 1994 - Bill Jolitz on the 386BSD 1.0 release.
|>  

        Is there anyone (other than jmonroy) who can report on what Bill has to
say? Given the deafening roar called the "lack of information about 386bsd 1.0,"
I'm sure a number of people would be interested in he has to say. Living on the
east coast precludes my doing it.

        Adrian
-- 
adrian@cs.wm.edu          ---->>>>| Support you local programmer,
adrian@icase.edu            --->>>| STOP Software Patent Abuses NOW!
Member: The League for        -->>| membership info at prep.ai.mit.edu:/pub/lpf
       Programming Freedom      ->| print "join.ps" for an application

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

Crossposted-To: comp.os.linux.admin
From: rwhittak@orion.docwhitehorse.doc.ca (Richard Whittaker)
Subject: Device or resource busy (repost)
Date: Wed, 8 Jun 94 03:20:48 GMT

Newsreader died on the last post, so here's another kick at the cat (so to
speak).. 

I've just finished compiling the Linux 1.1.18 kernel with no errors (not
even a warning! :-)), copied the kernel into the root filesystem, reran
LILO, and rebooted. Upon restarting the system, I got a whole stream of
"Device or resource busy" errors, as the system tried to access any of the
ports on my 4 port Digiboard. I remembered a while back hearing something
about the serial routines in Linux being a little less "agressive" than they
were before at asserting interrupts, so I dug up an old copy of serial.c,
and copied it over to the /devices/char directory. This method has always
suceeded in solving this problem before, but it would appear that the serial
driver between .99pl12 and 1.1.18 has been changed radically enough that it
will no longer compile on the 1.1.18 kernel.  This is unfortunate, because
my SLIP connection is over one of the ports on my Digiboard.. :-(.. Does
anyone have a more "agressive" version of the serial driver that works with
1.1.18, or do they have any suggestions as to how I can "slap the existing
one around a bit" to make it more aggressive in asserting interrrupts.. 

Any help would be appreciated.

Until I find a solution to this problem, I'm running on my 1.0 backup
kernel with a buggered PLIP driver.. :-(..

Thanks in advance, E-Mail is the preferred method of response...

                                        Cheers,
                                        Rich W.

--
Richard Whittaker: Snailmail: 1102 Pine St, Whitehorse YT Y1A 4E8
  Internet E-Mail: rwhittak@orion.docwhitehorse.doc.ca 
Geographic Coords: 60 Deg., 45', 53" N., 135 Deg., 7', 17" W. 
    Amateur Radio: VY1RW, VY1RW@VY1DX, VY1RW@VY1BBS, 145.010 MHz         

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

From: hamilton@cs.iastate.edu (Jon Hamilton)
Subject: Re: 1.1.17 and no networking won't compile
Date: 8 Jun 94 15:07:23 GMT

jhh@scss3.cl.msu.edu (John Hayes) writes:

>In article Ar5@pe1chl.ampr.org, rob@pe1chl.ampr.org (Rob Janssen) writes:

>There may be more wrong with current releases of the kernel than this.
>In comp.os.linux.help and comp.os.linux.admin there are postings where
>users are complaining that gcc crashes with signal 11, signal 6 and signal 4
>errors when compile jobs are being run. The report is that gcc will compile
>fine when the system has been rebooted fresh but after it has been up for
>a while gcc will crash, typically on longer jobs such as a kernel make.

I've seen gcc crash occasionally in low-memory situations, usually on
signal 11.  This is nothing new, it's always done that for me, as far
back as I can remember.  For me, restarting the compile has always 
worked fine.  I currently have over 4 days of uptime on 1.1.18,
have done lots of compiling, and have had no problems.  If it seems
to be worse over time for you, perhaps you have a daemon with a 
memory leak or something.  

>I also have problems with files not being found during a compile. At first
>I thought that the distributions may have been deficient... but after reading
>the above posts I'm not so sure. My compile problems have been so serious
>that I have taken to finding binary releases for everything that I want as
>I can build almost nothing that will finish making.

Which files aren't being found?  You need a fairly recent libc and gcc
for newer kernels; sounds like your gcc is either out of date or 
improperly installed.  

-- 
+    Jon Hamilton  hamilton@cs.iastate.edu | jdh@iastate.edu    +
+        CS Solaris Support Group, Iowa State University        + 
+         "Being a clueless newbie is one thing, being          +
+           from Mars is another" - dchaos@delphi.com           +

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Tue, 7 Jun 1994 15:50:29 GMT


In article <2t19urINNhr9@usenet.pa.dec.com>,
Burkhard Neidecker-Lutz <neideck@nestvx.enet.dec.com> wrote:
>In article <idletimeCqzHAL.I59@netcom.com> idletime@netcom.com (Totally Lost) writes:
>> <lots of flames about asynchronous write semantics of UNIX file systems
>>  deleted>
>
>Get a clue. Whoever writes sensitive data through the normal file
>system with normal semantics deserves to get corrupted data. If you
>want to commit data into a UNIX file system, you can do that perfectly
>well by either using fsync(2) or by opening the file with O_SYNC
>in the first place.

I've had the clue since 1977 ... stop knee jerking (or whatever else).
My primary point which you failed to address was facility level reliablity
problems caused by normal operational proceedures recovering from
UNIX crashes .... due to poor filesystem designs, which include BSD/SUN/DEC.
After being primarily responsible for production UNIX systems from 1975
todate ... I have a long list of war stories for such (aka experiences).

Read first, then write .... one point of the posting was that ordered
writes correct 95% of the reason programmers are forced to use O_SYNC
to protect database updates. O_SYNC was a stupid solution to the problem
in the first place. Ordered writes with commit operations solves the
entire problem without the huge performance penalty.

>The asynchronous write batching of the normal UNIX file system is 
>a very reasonable default behaviour and you can get as much consistency
>as you like by using the appropriate controls.

Asyncronous write batching WITH ordered writes is fine. With the
"normal UNIX file system" it is NOT "very reasonable default behaviour"
for any production environment for the reason presented in the first
posting - undetectable file corruption at any abort of service.

To say "you can get as much consistency as you like by using the
appropriate controls" is a gross miss-representation since 95% of
the shipped systems do not have the option of mounting filesystems
synchronously and most of the remaining 5% that can, can not due
to the penalty.  You clearly understand the penalty from your comment below:

>Doing all writes synchronously has surprisingly bad performance (you
>can try that for yourself on systems that support mounting whole
>filesystems synchronously, such as Ultrix or DEC OSF/1.

Why is it that you can not understand the gains possible with ordered
writes? I guess it's just because you don't take the time to think ...
or can not ...

>               Burkhard Neidecker-Lutz
>
>Distributed Multimedia Group, CEC Karlsruhe 
>Advanced Technology Group, Digital Equipment Corporation
>neideck@nestvx.enet.dec.com

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

From: lellis@dmccorp.com (John Lellis)
Subject: Re: Serial drivers in 1.1.16 (autoconfig for IRQ's)
Date: 8 Jun 1994 15:22:38 GMT

Jason Sokolosky (sokolosk@socket.cuug.ab.ca) wrote:
: Davor Jadrijevic (davj@ds5000.irb.hr) wrote:
: : I also feel that CONFIG_AUTO_IRQ was better. I obtained setserial,
: : and tried it after CONFIG_AUTO_IRQ. I had problems with uugetty.

: I agree.  I liked the automatic kernel configuration.  I'm having some
: problems with uugetty that I never had before.  It seems to answer the
: phone once, but it can never initialize the line again after that, so
: it never answers after that.  

Rings familiar to me, too.  If I terminate a dial-in session with an "exit"
from the shell, the modem is unable to reinitialize.  This didn't used to
happen with kernel 1.0!  My workaround for the moment is simple - instead
of exiting gracefully, I just hang up the phone.  When uugetty sees the modem
disconnect, it must take a different path, since under those circumstances
the modem will reinitialize properly and you can dial in again successfully.

: Does anyone know what could be the problem???

Good question.  I'd like to see a fix for this one.

--

John Lellis (lellis@dmccorp.com)

--
... Our continuing mission: To seek out knowledge of C, to explore
strange UNIX commands, and to boldly code where no one has man page 4.




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

From: lellis@dmccorp.com (John Lellis)
Subject: Re: Serial port - 1.1.18
Date: 8 Jun 1994 15:25:30 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <2svd4s$6d3@narnia.ccs.neu.edu> dkulp@ccs.neu.edu (J. Daniel Kulp) writes:

: >I just "upgraded" from 1.0.8 to 1.1.18 by getting the 1.1.13 and the 
: >patches from ftp.funet.fi.  Now, when I boot, it says something to the effect
: >of  
: >Serial Driver 4.0 - No serial options
: >/dev/cua0  irq4
: >/dev/cua1  irq3
: >/dev/cua2  irq4

: >or something like that.  I forget the format.  Anyway, the problem is that I
: >only have two serial ports.   Where did the third on come from?  This didn't
: >happen in 1.0.8.   

: It is a known problem, and it is being looked at by Ted.

On my system, /dev/cua0 reports irq4 and /dev/cua1 reports irq7!  I have to
use setserial to force /dev/cua1 back to irq3 before it is usable.

--

John Lellis (lellis@dmccorp.com)

--
... Our continuing mission: To seek out knowledge of C, to explore
strange UNIX commands, and to boldly code where no one has man page 4.




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

From: devmorfo@mtu.edu (Evmorfopoulos Dimitris)
Subject: NCR PCI SCSI 53c810
Date: 8 Jun 1994 18:30:17 GMT


        I have a question for everyone. Is there anybody that knows what happened 
to Drew Eckhardt (drew@kinglear.cs.Colorado.EDU), who was developping the driver
for the NCR PCI SCSI 53c810 ? I tryied contacting him, and the first time I got
now reply, where the rest of the times, my mail jus tbounced back at me. Is 
anybody besides Drew that works on that ?

-- 
         ______      _______
        |  __  \    |  _____|   devmorfo@cs.mtu.edu  (Evmorfopoulos Dimitris)
        | |  \  |   | |___              
        | |   | |   |  ___|     Masters student working hard on        
        | |___| |   | |_____
        |_______| * |_______| * "Sliding Sunday, Week compression algorithm." 

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Reply-To: pe1chl@rabo.nl
Date: Tue, 7 Jun 1994 17:08:55 GMT

In <2t19urINNhr9@usenet.pa.dec.com> neideck@nestvx.enet.dec.com (Burkhard Neidecker-Lutz) writes:

>Doing all writes synchronously has surprisingly bad performance (you
>can try that for yourself on systems that support mounting whole
>filesystems synchronously, such as Ultrix or DEC OSF/1.

Or MSDOS...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: jayhan@cs.washington.edu (Jay "Thierry" Han)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: 08 Jun 1994 11:22:03 GMT

In article <7028@raven.ukc.ac.uk> gjh@ukc.ac.uk (Greg Harewood) writes:

> With no other processes running, Linux is *fast*. You have a flat memory
> model with as much space as you want given virtual memory. You have fast
> efficient drivers for all your hardware. It evens things out to a much
> nicer situation where all machines has as much memory as you want, a maths
> coprocessor, and the only difference between platforms becomes speed of
> execution. And the multitasking environment means you can have a process
> for the user interface and another to render the graphics (for example)
> in as much detail as remaining processor speed will allow.

Ah, but how do you know how much processor power you have?  That's
one of the problems of using UNIX as a real-time OS.  It's also a
pretty open research field to figure out what kind of interface
would be needed between application and OS so that they cooperate in
sharing the processor.

There are problems with UNIX for writing efficient stuff.  For
example, the virtual memory system.  If you have to page in memory
that you thought was there, your timing goes to hell.  That's why
many databases use pinned memory segments that they manage directly.
Also, device drivers are good because they abstract away the
hardware, but they impose an extra buffering layer in some form or
another.  That's why there's so much research on user-level network
interfaces.

I'm not saying that DOS is better than Linux.  I'm merely pointing
out some problems associated with using UNIX variants for
time-critical applications.  There are times when you want complete
control over the hardware (or parts of it), and UNIX gets in the
way.

-=<|  Jay "Thierry" Han  |>=-     e-mail: jayhan@cs.washington.edu
Dept. of Computer Science & Engineering, FR-35. Fax: (206)543-2969
U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224
Personal: 4820 Burke Ave N. Seattle, WA 98103, USA.  (206)547-8559

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


** 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
******************************
