Subject: Linux-Development Digest #808
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:     Thu, 9 Jun 94 02:13:05 EDT

Linux-Development Digest #808, Volume #1          Thu, 9 Jun 94 02:13:05 EDT

Contents:
  Re: Symmetric Multiprocessing for Linux? (Alan Cox)
  Re: Dial On Demand Routing (Alan Cox)
  WINE Status (John McCartin)
  PANASONIC CDROM DRIVERS ???? (CASTEELS JAN)
  A means of networking through Firewalls (Tim Docker)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Kevin Brown)
  Re: Video Blaster (Baruch Cochavy)
  Re: URGENT: Serious bug in 1.1.17 pty handling (Joerg Pommnitz)
  Re: Linux game development (Was Re: Why [DOS, W (Alan Cox)
  Re: Hardware Programing References for a Newbie (Michael Lausch)
  Re: Filesystem semantics protecting meta data ... and users data (Bill Flowers)
  16 & 24 bit X Windows Servers (Nicholas A. DeSimone)
  Random reboots with 1.1.13 - 1.1.18, all OK with 1.1.5 (Dave Platt)

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Symmetric Multiprocessing for Linux?
Date: Tue, 7 Jun 1994 19:42:17 GMT

In article <1994Jun2.005332.480@bigcomm.gun.de> ado@bigcomm.gun.de (Christoph Adomeit) writes:
>tdunbar@vtaix.cc.vt.edu (Thomas Dunbar) writes:
>
>>the problem is the cost is beyond Linux developers' budgets.  ...i
>>venture a guess that if ALR, Compaq, etc. were to donate a SMP box to
>>Linus, there would be a Linux-SMP before long.
>
>You won't need those big companies for that. I think if every Linux User 
>would give 0.10 $ this would be enough:-)
>However, if money is the problem, I think a short ask for this in c.o.l.a. 
>would bring much more than the needed amount easily.

I've been looking into this in detail with respect to making the net code
a MACH multithreaded server as part of the linux-mach stuff. Most things
are OK - some of the fs stuff needs a few more semaphores and spinlocks.
The memory manager needs to do some pretty flash stuff and that I think
is the only sticking point.

Its probably only a two-three month project for someone prepared to trash the
filesystems a few times until they get the spinlocks right and providing they
have all the hardware.

Alan




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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Dial On Demand Routing
Date: Tue, 7 Jun 1994 19:43:38 GMT

In article <2t226g$5ir@ns.oar.net> jchabut@dayton.adroit.com (John Chabut) writes:
>We recognize that standalone routers have this capability, but we were
>hoping to use a LINUX-based system to do the routing, auto-dialing, and
>auto-hangup (while providing other computing capabilities).  Are we 
>dreaming?
>
No - but until Tytso finishes fixing the tty drivers to work with ptys - hint
prod nudge 8) I can't finish debugging DOOD  - (Dial Out On Demand) for Linux

Alan


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

From: jmccartin@melpar.esys.com (John McCartin)
Subject: WINE Status
Date: Wed, 8 Jun 1994 18:42:55 GMT


What is the current development status of WINE?  When is it supposed 
to be out?

Thanks in advance,

John McCartin
E-Systems



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

From: tw48996@vub.ac.be (CASTEELS JAN)
Subject: PANASONIC CDROM DRIVERS ????
Date: 8 Jun 1994 21:49:07 GMT

Hi,

Is there somebody who has drivers for a double-speed CD-ROM drive on
a PCI motherboard


Please mail me!

Email: tw48996@vub.ac.be


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

From: timd@extro.ucc.su.OZ.AU (Tim Docker)
Subject: A means of networking through Firewalls
Date: Tue, 7 Jun 1994 23:18:52 GMT

My Linux box sits on a LAN that is physically connected to the net, but
packets are not routed through the machine that connects the LAN to the
internet SLIP connection. In practice this means that I can perform most
netoperations in two steps - for example, a telnet to the local machine, and
then a telnet to any other host.

This is often inconvenient, and makes some things impossible (like running
Mosaic locally). A tentative idea to get around this problem is to write code
to do the following:

A = My linux box
B = Host on LAN with SLIP connection to the net
C = some other host on the net (that I want to talk to)

1 ) Run a process on B that can make connection on request to a variety of
    hosts like C.

2 ) Modify the system shared libraries on A so that any connection to a host
    not on the local network gets redirected through the process running on B.
        OR
    Some sort of kernel patch that would do the same thing. 

Either way the connection mechanism should be transparent to the client programs
so standard clients could be used (ftp, telnet, Mosaic etc).


I guess my first question is to whether anything already does something
comparable. If not, does this sound feasable? It occurs to me that modification
of the shared libraries may also be a way to make a term connection work without
having to recompile the client programs.

Any comments anyone ?

-- 
===============================================================================
Tim Docker                                                    Powerhouse Museum
timd@extro.ucc.su.oz.au                                       Sydney, Australia
===============================================================================

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Wed, 8 Jun 1994 18:30:07 GMT

In article <2t0k4g$hsl@harbinger.cc.monash.edu.au>,
Kevin Lentin <kevinl@bruce.cs.monash.edu.au> wrote:
[...]
>That would work for people getting the patches but there is still the
>problem that people who don't know better see messages in the col.* groups
>asking questions about and commenting about 1.1.* kernels. Their immediate
>reaction is to post saying 'Where can I get these 1.1 kernels?', 'Should I
>ugrade?', 'What is the latest version?', etc. 

I should have pointed out that source code tar files for 1.1.*
kernels should similarly go in an ALPHA directory.

So, the answer to the person's question about "Where can I get
these 1.1 kernels" would be "somesite.somewhere.someplace:.../ALPHA".
Of course, then you have to answer questions like "why's 1.1.x in
an ALPHA directory?"...

Answers to "What's the latest version?" should always point out that
there are really *two* "latest versions", one of them being the ALPHA
kernel and one of them being the "stable" kernel.

>Maybe a different numbering scheme is needed. How about we turn 1.1.* into
>0.999.0.* :-) [ie 0.99 because it is alpha and 0.* because it is also
>development on top of the 1.0 kernel].

Heh.  That would certainly have an interesting effect.  Nobody would
even touch the ALPHA kernel anymore.  :-)

Oh, and then people would be asking "Should I downgrade?"  :-)

>I don't believe in changing the version numbers. Unfortunately, although
>your solution will certainly help in a few situations, I don't think it
>solves the general problem. The solution to the general problem is to
>include the details in the daily posting and educate the people out there.

Education is always the ultimate solution to problems of understanding...
But I think it's also necessary to reduce the confusion factor as
much as possible.

I would hope that, between the problems resulting from the names
given to some of the Linux newsgroups and the problems resulting
from kernel version numbers, people have figured out that what you
call something is very important with respect to what people think
it is (and thus how people think of it).


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

From: bcochavy@iil.intel.com (Baruch Cochavy)
Subject: Re: Video Blaster
Date: 8 Jun 1994 19:20:42 GMT


:       But there is no specs for it on the net anywhere.  If you find any,
: please e-mail them to me.  The application is not hard to write, but it is
: very hard to find the specs.


Last time I tried, CL were not willing to release it.o

        Good luck!
        Baruch
--
+--------------------------------------------------------------------+
| Baruch Cochavy             phone: +972-4-655807                    |
|   iSWP, INTeL, ISRAEL      bcochavy@iil.intel.com                  |
|                                                                    |
|              ( ----- this place for rent ---- )                    |
|         All views are my own. I speak only for myself.             |
+--------------------------------------------------------------------+

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

From: jpo@informatik.tu-chemnitz.de (Joerg Pommnitz)
Subject: Re: URGENT: Serious bug in 1.1.17 pty handling
Date: 8 Jun 94 16:19:17 GMT

jpo@informatik.tu-chemnitz.de (Joerg Pommnitz) writes:

>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
When I wrote the above article, the complete bugreport was from memory.
In order to give some better hints, I would like to add the following 
outputs:

1. procps -alx:

 F   UID   PID  PPID PRI NI SIZE  RSS WCHAN      STAT TTY   TIME COMMAND
 0     0     1     0   1  0   44    0 pause      SW   con   0:01 (init)
 0     0    25     1   1  0   32   24 read_chan  S    con   0:01 /sbin/selecti
 0     0    29     1   1  0   24   52 interrupt  S    con   0:00 (update)
 0     0    30     1   1  0   24   76 sigsuspen  S    con   0:00 update (bdflu
 0     0    31     1   1  0   48   52 sigsuspen  S    con   0:00 /sbin/crond
 0     0    33     1   1  0   68    0 do_select  SW   con   0:00 (inetd)
 0     0    68     1   7  0   32   88 pause      S    p 5   0:10 /usr/bin/tloa
 0     0    69     1   1  0    6    0 interrupt  SW   p 6   0:00 (syslogk)
 0     0    71     1   1  0  396  428 sigsuspen  S    p 1   0:03 -bash
 0     0    72     1   1  0   37    0 read_chan  SW   p 2   0:00 (getty)
 0     0    73     1   1  0   37    0 read_chan  SW   p 3   0:00 (getty)
 0     0    74     1   1  0   37    0 read_chan  SW   p 4   0:00 (getty)
 0     0    92    71   1  0   48    4 wait4      S    p 1   0:00 (xinit)
 0     0   141    71   2  0  177  312 interrupt  S    p 1   0:04 vi bugreport
 0     0    93    92   1  0 2463  652 do_select  S    con   0:10 (X)
 0     0    94    92   1  0  422    0 do_select  SW   p 1   0:02 (twm)
 0     0    97    94   1  0   85  152 do_select  S    p 1   0:01 xclock -geome
 0     0    98    94   1  0  180  184 do_select  S    p 1   0:00 rxvt -geometr
 0     0    99    94   1  0  156    0 do_select  SW   p 1   0:00 (rxvt)
 0     0   100    94   1  0  196    0 do_select  SW   p 1   0:00 (rxvt)
 0     0   103    98   1  0  389    0 read_chan  SW   con   0:01 (bash)
 0     0   101    99   1  0  389    0 read_chan  SW   pp0   0:01 (bash)
 0     0   102   100   1  0  389    0 read_chan  SW   con   0:01 (bash)
 0     0   142   141  22  0   80  224            R    p 1   0:00 ps -alx

2. proc fs based fuser -v:

/dev/ptyp0:           USER       PID ACCESS COMMAND
                      root        98 f....  rxvt
                      root        99 f....  rxvt
                      root       100 f....  rxvt

/dev/ttyp0:           USER       PID ACCESS COMMAND
                      root       101 f....  bash
                      root       102 f....  bash
                      root       103 f....  bash

3. Kernel messages:
<6>Console: colour EGA+ 100x40, 8 virtual consoles
<6>Serial driver version 4.00 with no serial options enabled
<6>tty00 at 0x03f8 (irq = 4) is a 16450
<6>tty01 at 0x02f8 (irq = 3) is a 16450
<6>Calibrating delay loop.. ok - 6.65 BogoMips
<6>Memory: 3096k/4096k available (440k kernel code, 384k reserved, 176k data)
<6>Floppy drive(s): fd0 is 1.2M, fd1 is 1.44M
<6>Swansea University Computer Society NET3.014
<6>IP Protocols: ICMP, UDP, TCP
<6>Linux version 1.1.18 (root@ico386) #1 Tue Jun 7 01:30:22 MET DST 1994
<6>Partition check:
<6>  hda: ST1144AT (124MB IDE w/8KB Cache, MaxMult=0)
<6>  hda: hda1 hda2 hda3
<6>VFS: Mounted root (ext2 filesystem) readonly.
<6>Adding Swap: 4160k swap-space
<6>master pty_close: count = 3!!
<6>master pty_close: count = 2!!


                                                Hope this helps
                                                    Joerg

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

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

In article <Cr1Cps.E9J@ucdavis.edu> kevin@frobozz.sccsi.com (Kevin Brown) writes:
>There is a slight performance hit for having to switch in and out
>of kernel mode whenever you make a system call.  But a properly
>coded interface will make the most difference with respect to that.
>For instance, libraries can queue up writes to the disk to minimize
>calls to the kernel.  An interface to the video display that allows
>you to make large updates at once will reduce the number of kernel
>calls you have to make to get such things to happen.

The Linux SVGAlib requires _ZERO_ system calls to write to the vga driver
and update stuff. Just needs them to set things up and mmap() the vga
board into your address space.

Alan




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

From: mla@loki.muc.de (Michael Lausch)
Subject: Re: Hardware Programing References for a Newbie
Date: 8 Jun 1994 22:43:04 +0200

In article <2t365t$8mp@tamsun.tamu.edu>,
Preston William Gilchrist <pwg7503@tamsun.tamu.edu> wrote:
>I am a farely experience C programmer but have done little programming that
>has dealt with lower level hardware access(ie. disks, cdroms, sound cards, etc)
>I was wondering if anyone can recommend a good reference source for access to
>these types of hardware items, command codes used, and standards for hardware
>items such as SCSI cards, sound cards, and such.  I would like as much linux
>specific docs as possible but any PC related stuff appreciated.  
>
>Preston Gilchrist
>Please Respond via E-Mail : pwg7503@tamsun.tamu.edu
>
>

I'm interested too.
e-mail mla@loki.muc.de

-- 
Magic is real unless declared integer
Michael Lausch                  e-mail: mla@loki.muc.de
Office: +41 089 93001 427       Home: +41 089 361 00 926

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: waflowers@qnx.com (Bill Flowers)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Wed, 08 Jun 94 16:18:37 GMT

In article <idletimeCqzHAL.I59@netcom.com>,
Totally Lost <idletime@netcom.com> wrote:
>In article <1994Jun6.073403.4235@wavehh.hanse.de>,
>Martin Cracauer <cracauer@wavehh.hanse.de> wrote:
>>SunOS-4.1.3 has a policy to have asynchronous writes for data, but
>>inodes and other superinformation is always written immedeatly. So, a
>>crash could only affect files that a written at that moment. I think
>>Solairs 2 does this, too. Does anybody know?
>>
>>There was a patch for SunOS 4.1.3 to make the BSD-Filesystem writing
>>inodes async, too. That speeds up writing a large number of little
>>files by a factor of 2 to 3. Of course, a crash could really hurt now
>>that superinformation could be damaged.
>
>Both of these policies are stupidly wrong from a security stand point,
>which is a significant case requiring orderly filesystem updates.
>Actually both are wrong form ANY stand point, except to stupid sysadmins
>and shit head systems programmers that don't give a damn about users data.

The first policy does open a security hole, but U**x systems are not
normally known for security.  It does however keep the filesystem
logically safe (but what good is a "clean" filesystem with bad data in
a file?).

The only advantage of the second policy is to run fast.  It is neither
logically safe, nor does it make any guarantees about the data
integrity of users files.  Some people want this; speed at any cost. 
However, it has been my experience (authoring the QNX4 file system)
that the overwhelming majority of users want the very best performance
they can get without compromising the file system integrity or the
contents of the files.

>[examples and personal preferences deleted]
>
>There are only two acceptable strategies:
>
>       1) require that all data be written prior to the referencing
>          meta data. File data blocks first, followed by Nth level
>          indirect blocks, ...., 1st level indirect blocks, inode.

Ordered updates.  Done properly they can all be asynchronous (ordered
asynch).  However drivers cannot be allowed to apply any strategy;
strategy must be applied at a higher level which "knows" about
transactions and the file system structure.  If multiple transactions
are occurring simultaneously, useful benefits can be obtained by
applying global strategies across the multiple transactions (e.g.
elevator seeking) while still maintaining the correct order of updates
within each transaction.  This is part of what is going into the QNX4
file system now.

>          If a file is open for writing, and written other than at
>          EOF, the disk inode is updated with a a dirty flag, which
>          is cleared when the file is closed or specifically "sync'ed".
>          
>          All filesystem file data and meta data will be clean at any
>          interruption of service, with the detectable exception that
>          a file/database may be internally inconsistant.
>
>       2) any other write policy requires a filesystem to be reload
>          from backup media if service is interrupted while mounted.
>
>Item one can be extended to require updates to existing filedata be done with
>new data blocks, and new meta data, which only is reflected to the
>disk inode when the file is closed or a commit operation performed.
>When done properly with locking operations this makes a system database
>safe as well.

Depending on what you are attempting to accomplish, and how much
control you have over all the pieces (i.e. can you rewrite fsck? or
completely redesign the metadata structure?) shadowing may or may not
be of benefit.

>This policy is neither difficult to implement, nor a significant performance
>hit ... and in fact when done with better algorithms than UFS can be
>3-10X faster.

Yes, there are ways to implement safe, fast file systems.  It is
unfortunate that there aren't more of them available.
-- 
---
W.A. (Bill) Flowers     waflowers@qnx.com   QNX Software Systems, Ltd.
phone: (613) 591-0931 (voice)               175 Terrence Matthews
       (613) 591-3579 (fax)                 Kanata, Ontario, Canada K2M 1W8

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

From: nad@pegasus.XImage.com (Nicholas A. DeSimone)
Subject: 16 & 24 bit X Windows Servers
Reply-To: nad@ximage.com
Date: Wed, 8 Jun 1994 20:21:22 GMT


I have taken it upon myself to port some of our software to Linux.  This
of course has come with some criticism, but I'm going to do it to spite
everyone here and SCO which gets most of our business.  However, I need
at least a 16 bit X Windows server to make it work.  And, obviously, a
24 bit server for the 24 version of our system.  If anyone has any
information please let me know.

Please E-mail as well, if possible.  Our news feed is retired very
quickly here.

Thanks,
Nick

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

From: dplatt@ntg.com (Dave Platt)
Subject: Random reboots with 1.1.13 - 1.1.18, all OK with 1.1.5
Date: Wed, 8 Jun 1994 22:17:58 GMT

I've had problems with recent patchlevels of the 1.1 kernel.  Older
kernels work fine, but do not (alas) have the support for external
filesystems that I'd like to play with.

Hardware environment:

        386SX-16, 6 megs
        One IDE disk (not used for Linux)
        BusLogic BT542B SCSI controller (DMA 5, IRQ 11, port 330h)
        One Maxtor LXT-213S disk with several Linux partitions (ext2 and swap).
        3c503 (EtherLink II) 8-bit Ether card (IRQ 5, port 310h)
        Internal modem as COM2:
        SoundBlaster 16 card (IRQ 10, DMA 1 and 6, port 310h)
           with 563 CD-ROM drive (port 230h).  SBCD driver, no sound driver.
        PS/2 auxiliary-port mouse

I've been able to run quite successfully with 1.1.5, using either the
aha1542 SCSI driver or the alpha-test version of the BusLogic driver.
The system boots, recognizes all of the hardware correctly, and runs
stably for as long as I care to keep it going.

With 1.1.13 or later releases (I've tried .17 and .18 as well) things go
badly awry, either immediately during boot or at some later time.
Symptoms noted:

[1] The system comes up far enough to recognize the SCSI host adapter,
    recognizes the hard disk, appears to finish the SCSI detect process,
    and then reboots the machine (before reporting on the presence of
    the floppy drives, I believe, or saying anything about TCP/IP).
    About half of the time, it reboots cleanly (memory check, BusLogic
    BIOS initialization, LILO, and booting of Linux).  Somes it comes up
    far enough to have this whole sequence repeat.  Frequently, it gets
    into LILO and then loops with a LI010101010101... display.

[2] If I've build a kernel using the BusLogic driver which is now part
    of the kernel distribution, the driver complains (during the
    device-detect phase) about receiving an interrupt with no mail.
    The Adaptec driver makes no such complaint (but does suffer from
    these other problems).

[3] If the machine doesn't reboot itself in [1], it will often do so
    fairly spontaneously during use.  The reboot seems to tend to occur
    during times of I/O activity.  It usually requires manual fsck
    intervention to correct filesystem problems.

I have tried removing both the EtherLink II card and the SoundBlaster 16
card from my system.  The problems still occur under 1.1.13 and later
but do not occur under 1.1.5.

Has anybody else seen similar problems in their environments, know of a
probable reason, or have an idea as to a fix?
-- 
Dave Platt    dplatt@3do.com
      USNAIL: The 3DO Company, Systems Software group
              600 Galveston Drive
              Redwood City, CA  94063

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


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