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:     Tue, 5 Apr 94 07:13:06 EDT
Subject:  Linux-Development Digest #604

Linux-Development Digest #604, Volume #1          Tue, 5 Apr 94 07:13:06 EDT

Contents:
  Re: Who, What Is Going On, Where, work on Linux Single Server for Mach? (Louis-D. Dubeau)
  NCSA/PCTCP Telnet and remote X crashes and weirdness ? (Pramod John)
  Purpose of Mach & linux? (Byron Thomas Faber)
  Re: Purpose of Mach & linux? (Ted Deppner)
  profiling _does_ work (after a little fix) (Ivan)
  Re: Amiga FileSystem, Anyone? (Nick Eggleston)
  Re: IDE Performance Package (Mark Lord)
  Re: Magic of .. (Re: Amiga FileSystem, Anyone?) (Kai Henningsen)
  Re: Amiga FileSystem, Anyone? (Kai Henningsen)
  Re: Amiga FileSystem, Anyone? (Jeremy Bettis)
  Re: D_link 620 CT Adapter : HELP (Stephen A Bergmann)
  Re: TCP/IP-Bug in 1.0 Kernel? (Rene COUGNENC)
  Re: /usr/include/utmp.h (Rene COUGNENC)
  parallel port direct manipulation... (Bhusan Gupta)
  Re: IDE Performance Package (Superuser)

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

From: hallu@info.polymtl.ca (Louis-D. Dubeau)
Subject: Re: Who, What Is Going On, Where, work on Linux Single Server for Mach?
Date: Mon, 4 Apr 1994 15:04:22 GMT

Christopher Shaulis (cjs@netcom.com) wrote:
: spj@ukelele.gcr.com (Guru Aleph_Null) writes:

: >I searched through the FAQ, and perhaps because this isn't a frequently asked
: >question, it wasn't there. (Naturally.)

: >Who's working on a Linux server for Mach?  How far has it progressed?  Is there
: >a mailing list? Etc..

: I remember that a mailing list was set up, but I have long forgotten the 
: addresse. Having just finished FTPing the Mach sources/utils for i386s,
: I would also be interested in seeing any work on a Linux server that has
: been done.

The work hasn't progressed much. Some time ago I got the Mach kernel to boot 
with LILO, but file corruption and brain corruption :) made me lose that code.
Now we have to restart (almost) from scratch. I also had less time to put on it
than I initially evaluated. For mailing list and ftp info, look in my sig.

: Christopher
:   ___     _  ___   ____  _  _ ___ _____  ___  ___  __  __     ___  ___  __  __ 
:  / __|_  | |/ __| / __ \| \| | __|_   _|/ __|/ _ \|  \/  |   / __|/ _ \|  \/  |
: | (__| |_| |\__ \/ / _` | .` | _|  | | | (__| (_) | |\/| | _| (__| (_) | |\/| |
:  \___|\___/ |___/\ \__,_|_|\_|___| |_|  \___|\___/|_|  |_|(_)\___|\___/|_|  |_|
: ------------------\____/-------------------------------------------------------


--
|              Louis-Dominique Dubeau <hallu@info.polymtl.ca>
|Computer Engineering, Ecole Polytechnique de Montreal (Montreal, Quebec)
|               ---    Linux single server project   ---
|  mailing list: linuxss@info.polymtl.ca -- requests: linuxss-request 
| alpha code at aiken.info.polymtl.ca in pub/linuxss (use it at your own risk)
|                     -> This sentence is false!!! <-

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

From: jpramod@cehpx3 (Pramod John)
Subject: NCSA/PCTCP Telnet and remote X crashes and weirdness ?
Date: 4 Apr 1994 16:22:05 GMT

Hi,
        I have been having some strange problems since I have upgraded to
v1.0.  Uptil now I have been using pl14 which seemed to be working sortof well.
When I tried to ftp using v1.0 it just locks up pretty quickly.  Now I had 
seen this behaviour seasonally with pl14.  The problems with X are more 
irritating.  Previously I had no problems running X programs remotely. I used
to run them with no problems on PC's running PCTCP and Exceed for Windows (
an X-server for Windows)  Now remote programs crash after a few seconds.  
I also tried it from an HP9000/730.  On the hp, it doesn't crash, but while
typing it stops and then a second or two later it catches up etc.  It does this
with all x-progs I have tried.  

        Let me make sure this is straight.  If the linux box is the server
and the programs are run on its console, everything works without a hitch.
If I am using a remote x-server and sending the display to the console of
the linux box, it works without any wierdness.  If the linux box is the server
and the display is sent to another client, then the wierdness develops. The
X-problems were not there with pl14.  Obviously this could be something 
wrong with the TCP/IP as that is the transport protocol. 

        I tried upgrading to v1.0.4 and still that has not cured these 
problems.  

Any ideas ?

Thanks,


Pramod John


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

From: bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber)
Subject: Purpose of Mach & linux?
Date: 4 Apr 1994 16:08:08 GMT

I read the FAQ from comp.os.mach, but it didn't help.

Can somebody tell me why Mach is so cool?

Byron
-- 
`Playing this disk at loud volume may permanently damage your speakers or
other sound components.'                                -LFO
                                b-faber@uiuc.edu

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

From: tdeppne@eis.calstate.edu (Ted Deppner)
Subject: Re: Purpose of Mach & linux?
Date: 4 Apr 1994 09:33:04 -0700

bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber) writes:
> I read the FAQ from comp.os.mach, but it didn't help.
> 
> Can somebody tell me why Mach is so cool?
> 
> Byron
> -- 
> `Playing this disk at loud volume may permanently damage your speakers or
> other sound components.'                              -LFO
>                               b-faber@uiuc.edu
I know not much.

that said...   the mach style of architecture attempts to recreate a 
'bios' if you will of low level calls for an operating system.  with this 
'bios' of functions and calls, it would be possible to run whatever OS 
you wanted to...or multiple OS(s)   the OS only needs to conform to mach, 
making the OS extreemely hardware independent...   

mach I believe "looks like" your DOS box in some ways...  imagine all the 
applications you use in DOS (or perhaps that you used to use).. mach(DOS) 
attempts to provide the OS(s)(your DOS applications)  with common services, 
allow dynamic loading/unloading, etc, etc..  

not a perfect, or perhaps functional description, but it is I believe the 
basic simplified concept...


--
Ted Deppner
  sactoh0.sac.ca.us!qubix!ted
  eis.calstate.edu!tdeppne

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

From: ivan@djomolungma.Eng.Sun.COM (Ivan)
Subject: profiling _does_ work (after a little fix)
Date: 4 Apr 1994 17:29:34 GMT
Reply-To: ivan@djomolungma.Eng.Sun.COM

After posting comments regarding profiling and how the kernel doesn't 
implement 'profil(2)', I got told about bprof, and some hints about
the fact that profil() is actually implemented in user land.

I tried bprof, but didn't find it useful since it doesn't point out
the slowest part of your program. You have to have a guess first,
then bprof might verify it ... but bprof _did_ come in useful later;

Upon further investigations regrading profil it turned out that 
my libg actually does implement profil(), but incorrectly! It uses
an interval timer to have a signal handler do sampling, except that
the signal handler was implemented incorrectly (or maybe Linux/GNUlibc
mismatch) such that it never calculated the correct interuptees PC (eip).
(The symptom was that my gprof output claimed that the program spend %100
of its time in a function called '_entry' which wasn't even mine, and 0%
in every other function. '_entry' was the wrong PC that the signal handler
was stuffing into the profil buffer.

I used the code in bprof to fix libg's interval signal handler, and
now everything works.

Thanks for all the responses.


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

From: egglesnj@ucunix.san.uc.edu (Nick Eggleston)
Subject: Re: Amiga FileSystem, Anyone?
Date: 4 Apr 1994 14:14:00 -0400

[much deleted}

: Actually, this has gotten me thinking, and I might just sit down and write
: a DOS device driver to allow access to my Linux partition.  If I make it
: RO then that would let me see just exactly how much will break.  I haven't
: really looked at the filesystem code so I don't know how much of it I can
: steal.

The real problem in implementing an extension to DOS to allow arbitrarily
long filenames is the FINDFIRST/FINDNEXT interface. These system calls
return their data in a buffer that lays out the matching files in the
nasty old 8+3 format. What is needed is for someone to come up with
another FIND{FIRST,NEXT} INT21 interface that allows arbitrary file
names to be returned. If this were standardized and included in the 
libraries of the popular C compilers, then new apps would be able
to handle long names.

If anyone is interested in working on this, please let me know.

--Nick Eggleston
Nick.Eggleston@uc.edu

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

From: mlord@bnr.ca (Mark Lord)
Subject: Re: IDE Performance Package
Date: 4 Apr 1994 21:59:45 GMT

>In <Apr1.021456.17921@acs.ucalgary.ca> root@fusion.cuc.ab.ca (Superuser) writes:
>>Unfortunately, unmasking interrupts caused my disks to be seriously trashed.

Hmm.. sounds like you panic'd and reset the computer before
the error recovery had time to work.  The enhancements are
automatically shut off when the pre-existing error recovery
in hd.c finally gives up and resets the controller+drives.
But it performs a largish number of retries before getting that far..
If you wait it out for several minutes, it really ought to recover.
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

Date: 04 Apr 1994 19:05:00 +0100
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Magic of .. (Re: Amiga FileSystem, Anyone?)

cddukes@eos.ncsu.edu wrote on 02.04.94 in <2nilnj$msv@taco.cc.ncsu.edu>:

> As someone that uses an operating system that has no concept of
> directories (multiple volumes, but no directories on those volumes)
> I will tell you that it is not interesting, it is a royal pain in the duff.
> Especially with 8.8 filenames.

VM/CMS? :-)

Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
## CrossPoint v2.93 ##

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

Date: 04 Apr 1994 19:19:00 +0100
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Amiga FileSystem, Anyone?

skip@metronet.com wrote on 04.04.94 in <CnpqF1.14K@metronet.com>:

> Other than the FCB stuff which as far as I know nothing these days uses, I
> don't really remember nuch in the way of the call interfaces that assumes
> 8.3.  A bigger problem is the limitation of (I think, don't have my DOS
> ref handy) 64 bytes for the entire path, and that limitation is hardwired.

Yes and no. The FindFirst/FindNext stuff explicitely says buffers for file  
names need only be 13 bytes long - *this* problem has been known to exist  
for old unix applications as well.

However, more important, there are lots of programs that break even if you  
only use fully what *is* already allowed - for example, dots in directory  
names, or non-alphanumeric characters.

DOS, for example, does - this much is common knowledge - capitalize all  
file names. Less known is that it also *correctly* capitalizes characters  
with the 8th bit set (according to the current code page). *Lots* of  
programs don't like that!

As long as most programs can't even deal with what is available today, I  
see no hope for pushing the frontier.

By the way, the handle based interface was called the "Xenix compatible"  
calls :-)

> >What *could* be done, without breaking existing applications, is
> >to implement an alternate set of DOS services that explicitly allow
> >long filenames.  Since existing applications wouldn't even use this

This problem has been successfully(?) tackled by OS/2, which did introduce  
long filenames sometime after 1.0. There, it's done by a flag in the  
header of executables: "this executable can deal with non-8.3-filenames".

Otherwise, those are simply hidden.

This *could* be adopted to work with DOS, I believe.

Kai
--
Internet: kh@ms.maus.de, kai@khms.westfalen.de
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
## CrossPoint v2.93 ##

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

From: jbettis@cse.unl.edu (Jeremy Bettis)
Subject: Re: Amiga FileSystem, Anyone?
Date: 4 Apr 1994 23:10:09 GMT

skip@metronet.com wrote on 04.04.94 in <CnpqF1.14K@metronet.com>:

> Other than the FCB stuff which as far as I know nothing these days uses, I
> don't really remember nuch in the way of the call interfaces that assumes
> 8.3.  A bigger problem is the limitation of (I think, don't have my DOS
> ref handy) 64 bytes for the entire path, and that limitation is hardwired.

Actually it is 144 bytes but that is still far too small.  Notice that
command lines can also only be 144 bytes, that means that you have even less
space when you do a equiv of a system().
--
Jeremy Bettis   -*-   Jerbo Jehoshaphat   -*-   University of Nebraska
INET:   jbettis@cse.unl.edu             "Those who stand in the middle of the
UUCP:   jerbo@tddi.UUCP                  road are often hit by passing cars."
Running Linux .99p14 Free Unix for i386/i486/Pentium machines. Ask me how.

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

From: sab20@ccc.amdahl.com (Stephen A Bergmann)
Subject: Re: D_link 620 CT Adapter : HELP
Reply-To: sab20@JUTS.ccc.amdahl.com (Stephen A Bergmann)
Date: Tue, 5 Apr 1994 00:04:53 GMT

In article <2nluk8$466@nef.ens.fr> vilotte@jadeite.ens.fr writes:
>Hi,
>
>
>I got a real problem right now and desperatly need some help. I got
>Linux installed (Slackware 1.1.1) on my laptop a IPC5 DX2/50. It
>works fine. The problem is that I bought a D_link 620 CT parallel
>adapter with a RJ45 and a Thin Lan connections. I realized too late
>that this Adapter is not apparently supported under Linux (only
>the D_link 600).
>
>I however tried as if it was a D_Link 600 : I modified the kernel
>answering yes to net and D_Link 600 questions and reboot the laptop.
>The D_link adapter is not recognized at the requested address, even
>when I modify the D_link.c driver (Slow down option).
>
>The result is that ifconfig failed since the eth0 interface is
>not recognized. I just have the lo interface working.
  

!!!!!!In your rc.inet1 or if you are doing this manually the correct device
for the ifconfig command for the DE-600 is dl0 not eth0.../bin/ifconfig dl0 ${IPADDR} or /sbin/ifconfig dl0 ${IPADDR} depending on where your ifconfig is....Try substituting dl0 for eth0 and that should
help....later, Steve Bergmann......................

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: TCP/IP-Bug in 1.0 Kernel?
Date: 4 Apr 1994 12:31:18 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Linus Torvalds ecrit:

> Ok, here is a as-yet-untested fix: no guarantees, but I think I found
> it.  Please keep me posted if this fixes/fails to fix it.  Thanks,

>               Linus

> ----------
> --- v1.0.5/linux/net/inet/sock.c      Mon Mar 21 20:42:12 1994

Ok, I try it immediately and see what happens !

So far, 1.0.2 has been running for:
renux:/ $ uname -a
Linux renux 1.0.2 #3 Wed Mar 30 04:31:49 MET DST 1994 i386
renux:/home/rene $ uptime
  2:27pm  up 3 days, 15:01,  6 users,  load average: 0.78, 0.51, 0.31

Transfering megabytes at 14400 whith absolutely no overrun problem, so
the problem really starts whith patch3. Ok, I patch 1.0.5, and install it !

> ----------

--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: /usr/include/utmp.h
Date: 4 Apr 1994 13:31:57 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Jon Green ecrit:

> I found (I think) a small bug in /usr/include/utmp.h from the 4.5.25 header
> files.  With the file containing this line:
>       char    ut_host[UT_NAMESIZE];   /* hostname for remote login... */
> a recompiled version of login wrote strange things to the utmp file.
> After changing it to:
>         char    ut_host[UT_HOSTSIZE];   /* hostname for remote login... */

> things worked fine.  Did I fix a bug, or create another one? :)


Probably you fixed an error... What is UT_HOSTSIZE  length ? 
(I did not get 4.5.25 yet, can't test everything at the same time :-) )

The current 4.5.21 header I have here defines:

        char    ut_user[UT_NAMESIZE];   /* username, not null-term */
        char    ut_host[16];    /* hostname for remote login... */

I just hope that UT_HOSTSIZE is 16. If your login writes a goot utmp, it
probably is; all this stuff seems normal; Murphy is always around your
keyboard when you write code :-)

        HLu wanted to clean this hard-coded value;
        He replaced it by UT_HOSTSIZE;
        And the Murphy's laws applied and he wrote a typo :-)
--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: bgupta@maia.caltech.edu (Bhusan Gupta)
Subject: parallel port direct manipulation...
Date: 5 Apr 94 01:59:37 GMT

Hi,

I am wondering if someone can give a pointer on directly controlling a
parallel port. By directly controlling the port, I mean the ability to
change the individual bits/control lines. I have looked at the kernel
sources for the parallel port (lp.c). I was wondering what was
available in the user space (i.e. not kernel space). I have also
looked at plip.c for more info.

If there is some fragment of code that may help me out, I'd appreciate
it.

The goal of this exercise is to port some DOS based s/w to linux. It
requires control of the parallel port. You can guess why... 

Please no flames about this last part. I am doing nothing illegal,
just trying to prove that Linux is a viable environment for CAD work.
In fact, I think that it's more than a viable environment, it's an
awesome one.

Bhusan Gupta

--
Bhusan Gupta        |                          | Voice: +1.818.395.2162 
   Caltech          |    bgupta@caltech.edu    | FAX:   +1.818.568.8670
                        
                    If I'm not me, who am I?      (total recall)

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

From: root@fusion.cuc.ab.ca (Superuser)
Subject: Re: IDE Performance Package
Date: Tue, 5 Apr 1994 03:59:06 GMT

mlord@bnr.ca (Mark Lord) writes:
> >In <Apr1.021456.17921@acs.ucalgary.ca> root@fusion.cuc.ab.ca (Superuser) writes:
> >>Unfortunately, unmasking interrupts caused my disks to be seriously trashed.
> 
> Hmm.. sounds like you panic'd and reset the computer before
> the error recovery had time to work.  The enhancements are
> automatically shut off when the pre-existing error recovery
> in hd.c finally gives up and resets the controller+drives.
> But it performs a largish number of retries before getting that far..
> If you wait it out for several minutes, it really ought to recover.

No, that's not what happened- I installed the patch with interrupts
unmasked as default, recompiled and installed the kernel.  Then I
rebooted- I did a few speed tests and read some news, then shutdown
normally.  No errors occured during this test run (which lasted about
10-15 minutes before reboot), although swapon complained that it
couldn't find the swap signature in my swap partition (more on this later).

When I rebooted e2fsck now reported *MASSIVE* file system corruption.
(I don't use bootutils- I force a check of the file systems on the
root partition at every boot).  Even after e2fsck fixed all it could
and reported the file system structure sound, many files were still
bad- they had various bits changed in them, eg: in a source file a
statement like "int x" could have been changed to "i%t x" or something
similar.  I replaced and recompiled all the applications that I found
to be corrupted, but I'm sure that there are still files that I don't
normally use which remain corrupted.

Since I have been using the original patch (with interrupts masked)
since you released it last year without incident, I attribute the
damage to the UNmasking of interrupts.  As further evidence linking
the unmasked interrupts to disk corruption, I've since recompiled with
the new patches but this time with the interrupts masked off.  No file
system corruption has occured in over a week of fairly heavy use.

As to the problem with the swap partition- swapon said it couldn't
find its signature, so I tried mkswap on it.  mkswap was successful,
but swapon still couldn't do anything with the swap partition, so I
gave up on it.  When I switched back to my backup kernel (with masked
interrupts), swapon worked fine again.  It's also working fine with
the new patches now that interrupts are also masked.

> -- 
> mlord@bnr.ca  Mark Lord       BNR Ottawa,Canada       613-763-7482

c4
-- 
Christopher Lau- "Mr. Unix"    |     /       Fusion: Playing With Fire!
StarBright Research            |    / /      H + H -> He + 24 MeV
            --                 |   /_/_/_    "Bring back Trudeau!"
root,lauc@fusion.cuc.ab.ca     |____________ "This space for rent"

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


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