Subject: Linux-Development Digest #596
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 2 Apr 94 10:13:08 EST

Linux-Development Digest #596, Volume #1          Sat, 2 Apr 94 10:13:08 EST

Contents:
  Re: TCP/IP-Bug in 1.0 Kernel? (Rene COUGNENC)
  1.0.0 zombies-bug? (Steve Tinney)
  Linux on the IBM TP 750[c] & 2.88 MB FD (Stacy D. Coil)
  Re: SLIP Server setup: Routing and interface ??? (Angelyn P. Williams)
  kernel level nfs server (Craig I. Hagan)
  Re: System headers. (Ken Pizzini)
  login on remote machine from kernel? (Alberto S Alonso)
  Re: IDE Performance Package (Byron Thomas Faber)
  Re: IPX compliancy? (Byron A Jeff)
  Re: Amiga FileSystem, Anyone? (Bill Hay)
  Re: IPX compliancy? (Steven Grevemeyer)
  Re: Linux on the IBM TP 750[c] & 2.88 MB FD (Paul Vojta)
  System headers. (Don Garrett)
  Re: mt commands that won't work (Zenon Fortuna)
  Re: TCP/IP-Bug in 1.0 Kernel? ([email-masked])

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

From: [email-masked] (Rene COUGNENC)
Subject: Re: TCP/IP-Bug in 1.0 Kernel?
Date: 31 Mar 1994 15:38:27 GMT
Reply-To: [email-masked] (Rene COUGNENC)

Ce brave Mike Horwath ecrit:

> Rene COUGNENC ([email-masked]) wrote:

> : The problem is not only whith ftp, but whith any program. The network works

> Hmm...
> Our configuration matches almost exactly.  I have a small network at home
(...)
> I wonder where the fundamental differences are that cause problems.
> (thinking hard...)

I am actually testing all kernels from 1.0 to 1.0.5 to try to find which
patch level introduced something making my 386/25 going into these problems.
So far, everything is Ok for 1.0 to 1.0.2. 

I am actually running 1.0.3, it seems OK but I have to wait for at least
1 day of uptime to be sure.

The problem (for me) I tracked in 1.0.5 (and 1.0.4 apparently), is that
after about 12 hours, the system starts getting "input overruns" on
the serial port, and every serial connections work really bad. UUCP or
Zmodem stops whith 'too many errors', and on SLIP or PPP sessions, the
connection seems to hang. Ping is ok but transfering more than 1Kbyte
hangs.

(Of course, the serial port is equiped whith a 16550, hardware flow-control
 works, I ran 1.0 during 10 days whithout any overrun error.)

If, as it seems to be, the 'bug' has been introduced in patch4, I think
we all should stop computers and do something else, there is really nothing
related in this small patch... :-)

--
 linux linux linux linux -[ [email-masked] ]- linux linux linux 

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

From: [email-masked] (Steve Tinney)
Subject: 1.0.0 zombies-bug?
Date: 1 Apr 1994 17:55:35 GMT

After 16 days of uneventful uptime, my Linux 1.0.0 kernel began
to fail to terminate processes properly. Each processed that I
closed, working within XFree 2.0, became a zombie. No other problems
were apparent, and I carried on working for an hour or so until I
was ready to restart. I shut down X, tried to logout, logout didn't
terminate as usual. Flipped to another VT, logged in as root,
all the processes associated with the ID I was trying to log off were
now zombies. Tried to logout root, wouldn't terminate. Flipped to
another VT, logged in as root again and did a 'shutdown -r now'.
That did the trick: no funny messages, no filesystem corruption,
return to normalcy. The only thing that I can think of that may have
triggered this was that I did manage to fill up the root partitition
to 100%.  I deleted the contents of /tmp and /usr/tmp to free
15M or so of space. Sometime thereabouts, the zombies began
rising.

Anyone else seen anything similar?

 Steve

======================================================================
Steve Tinney                                        Babylonian Section
                   University Museum of the University of Pennsylvania
[email-masked]                     Phila, PA. 215-898-4047

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

From: [email-masked] (Stacy D. Coil)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Linux on the IBM TP 750[c] & 2.88 MB FD
Date: 1 Apr 1994 16:43:05 GMT
Reply-To: [email-masked]

A while back, there was a discussion of the TP750 and linux.  A person said  
that linux can on run on the ThinkPad with a floppy driver modification.   
Could that person e-mail me exactly what they modified.

When Linux probes for the floppy it finds an unknown type (6).  I modified
the routine find_base in the floppy driver to fool linux that type 6 is
actually type 4.  However this doesn't seem to work.

I am trying to get the machine to boot off a two floppy system (a boot disk  
and a root disk).  If anyone has any ideas, please let me know.

Thankyou 

--Stacy
[email-masked]
Ohio Supercomputer Center

When (hopefully) I get linux installed, I will post what I had to do with
some patches to the kernel.

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

From: [email-masked] (Angelyn P. Williams)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: Re: SLIP Server setup: Routing and interface ???
Date: 1 Apr 1994 21:03:57 GMT

I am not alone!!!

I was having this same problem late last night.  Did you
find a solution?  (specifically, ping and traceroute work;
telnet says 'Connection established' but never gives a login prompt)

Eagerly awaiting your reply,
A.

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

From: [email-masked] (Craig I. Hagan)
Subject: kernel level nfs server
Date: 1 Apr 1994 21:40:33 GMT

hi, i was reading the README from the nfs server for linux
that comes with slackware, and i noticed this reference
in it:

"
This is a user-level (no kernel mods) NFS server, unlike Der Mouse's
which does add system calls to improve performance.  This is
an NFS client implementation, which would require changes to both
kernel and system utilities.
"

I was wondering if someone could point me to the other
nfs server, as i need something that has half decent performance
(nothing against linux, but, this is the one stumbling
block i have run into)

-- craig

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

From: [email-masked] (Ken Pizzini)
Subject: Re: System headers.
Date: 1 Apr 1994 23:31:56 GMT

In article <[email-masked]>,
Don Garrett <[email-masked]> wrote:
>  I have libc 4.5.19, and gcc 2.5.8. When I compile with -ansi, there
>are a number of function prototypes that aren't visible to me. (fdopen
>is what started this)
>
>  Checking the system header, stdio.h, I find that fdopen, and a
>number of others are blocked off (in this block):

If you use -ansi, gcc defines __STRICT_ANSI__ under the assumption
that you want to be sure that *any* system with an ANSI compiant
C compiler/library will be able to run your code.  Things like
fdopen are _not_ in the ANSI standard.  fdopen in particular
is a POSIX.1 standard routine which allows you to glue file
descriptors returned by open(), dup(), pipe(), etc. onto functions
which want to use the ANSI stdio functions.

If you want to generally use ANSI C (X3.159-1989) code with the
additional library support of Posix, BSD, etc., just use
gcc without either of the -traditional or -ansi options.

                --Ken Pizzini

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

From: [email-masked] (Alberto S Alonso)
Subject: login on remote machine from kernel?
Date: 1 Apr 94 06:38:45 GMT

I was wondering if there is a way in which the kernel will log into a remote
machine, and stablish a term conection everytime I reboot the machine. I'm
also interested in the kernel watching that this conection is not lost, and in
case it is to reconect again.

I thought of two posibilities:

1.-Writing a script to log into the other machine automatically (which I don't
know how to do). and execute a script in that machine that would make term
run. By using this script from the /etc/rc it would work everytime that
reboots, and then I don't know how to watch the connection. I guess by looking
to /.term/connect ???

2.-Modify the kernel source. In this case I guess it is quite complicated, so
that the kernel handles all this and in that case I don't have to worry about
anything else. But I don't really know that much about the kernel (even though
I'm reading the KHG which helps a lot).

Any ideas are really apreciated.

Thanks in advance

Alberto

-- 
Alberto Alonso                   |The power is something no one will ever
user name: [email-masked]  |know what it really is, but still everyone
Electrical Engineering.          |wants to have it. That is the root of the
                                 |human nature. (Anonymous)

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

From: [email-masked] (Byron Thomas Faber)
Subject: Re: IDE Performance Package
Date: 1 Apr 1994 01:09:21 GMT

[email-masked] (David Monro) writes:

>FYI, my other drive is a "Conner Peripherals 170MB - CP30174E", which also
>has 16 sector multimode capability - with that drive I get no speedup, in
>terms of elapsed time to read data, but it consumes a lot less cpu (like
>22% instead of 60%). Again, your mileage may vary.

I have this same drive and my drive actually slows down as far as reads
are concerned.

However, the system time spent on reading has dropped from around 90%
to around 15% or less.    So it saves alot there.

I'm not sure which is more useful.. I'm trying out the 16-sector mode now.

Byron
-- 
`Playing this disk at loud volume may permanently damage your speakers or
other sound components.'                                -LFO
                                [email-masked]

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

From: [email-masked] (Byron A Jeff)
Subject: Re: IPX compliancy?
Date: Sat, 2 Apr 1994 01:25:01 GMT

In article <[email-masked]>,
Alan Cox <[email-masked]> wrote:
>In article <[email-masked]> [email-masked] (Cary Whitney) writes:
>>Where can a person get information about this test IPX layer?
>>
>sunacm.swan.ac.uk:/pub/Linux/Networking/BETA
>
>I hope (Linus permitting) to have a better version in the 1.1 kernel

Might I suggest that instead of helping Novell and their closed-minded
attitutes that maybe is may be good to look at other alternatives:

- Russ Nelson recently posted about a LanManager Server/Client for Linux.
  This package allows Linux to interoperate with LanManager Clients.
  This included the free DOS lanmanager client from Microsoft (of all people)
  and Workgroups for Windows.

- Mike Durkin has a most excellent shareware NFS client for DOS. An
  evaluation copy can be found at polyslo.calpolu.edu:/pub/mdurkin/nfs
  0.24 is the latest revision. 

Novell has no intention of helping us. Let us not bother to help them.

BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332   Internet: [email-masked]

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

From: [email-masked] (Bill Hay)
Subject: Re: Amiga FileSystem, Anyone?
Reply-To: [email-masked]
Date: Fri, 1 Apr 1994 21:23:07 +0000

In article <[email-masked]>
           [email-masked] "Kevin Brown" writes:

> 
> Sigh.  I'd better quit while I'm not too far behind.  :-)
> 
> What I remember when dealing with DOS was that the call interfaces
> expected filenames that followed the 8+3 convention.
> 
> If the system call interfaces don't have any expectations on what
> the filenames are supposed to look like (I don't have access to
> any good references anymore, so I can't look it up), then I completely
> agree with you (though I would then have to wonder exactly why
> applications would break as badly as you seem to imply, notwithstanding
> the fact that they would be optimized around an essentially
> 12-character filename length limit).
> 
> But if the system call interface itself has such a restriction,
> then replacing the services wouldn't do much good: you'd still have
> to adhere, in the interface, to the restriction.

IIRC correctly DOS has two call interfaces for file control.  FCBs and handles 
the FCB system (mostly used by older programs and those which need to create a 
volume label) does indeed have an 8.3 limitation.  The handles (since v2 I 
think) has no inherent limitation being essentially a quick copy of the UNIX 
system.

-- 
Bill Hay

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

From: [email-masked] (Steven Grevemeyer)
Subject: Re: IPX compliancy?
Date: 1 Apr 1994 21:26:00 -0500

[email-masked] (Byron A Jeff) writes:
: 
: Novell has no intention of helping us. Let us not bother to help them.
: 
: BAJ
: ---
: Another random extraction from the mental bit stream of...
: Byron A. Jeff - PhD student operating in parallel!
: Georgia Tech, Atlanta GA 30332   Internet: [email-masked]

Unfortunately, though this is a nice thought -- it is a bit shortsighted.

Novell has a very large position within the desktop network
world.  Regardless of their technical pros/cons which I won't 
debate -- except to say I have a lot of equipment that doesn't
run IPX and it is very painful -- any usage of Linux within
the commercial market place is going to require IPX support.
What is put up with (gateways, Internetwork routers, etc) to
interface a Sun workstation with a Novell network will NOT
be tolerated to connect a Linux box.

-- 
Steven E. Grevemeyer    Phone: (810)574-5106 FAX: -5008
US Army TACOM/Software Enginnering Division (AMSTA-OS)
Vetronics Technology Center Warren, MI 48397-5000
Email: [email-masked] 

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

From: [email-masked] (Paul Vojta)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Re: Linux on the IBM TP 750[c] & 2.88 MB FD
Date: 2 Apr 1994 00:16:33 GMT

In article <[email-masked]>,
Stacy D. Coil <[email-masked]> wrote:
>A while back, there was a discussion of the TP750 and linux.  A person said  
>that linux can on run on the ThinkPad with a floppy driver modification.   
>Could that person e-mail me exactly what they modified.

That person was me.  Actually, I don't own a TP750; I own a desktop
system (with AMI M/B and 2.88 Teac floppy drive).  The modification
works for my desktop system, and I assumed it would work on the TP750.
Unfortunately, people tell me it doesn't.

Instead you might try the earlier solution that was posted.  Namely, run
the BIOS setup program and tell the machine that it has a 1.44 floppy
drive.

I have redirected followups to comp.os.linux.help.

--Paul Vojta, [email-masked]

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

From: [email-masked] (Don Garrett)
Subject: System headers.
Date: 1 Apr 1994 21:46:43 GMT

[ Article crossposted from comp.os.linux.misc ]
[ Author was Don Garrett ]
[ Posted on 1 Apr 1994 21:46:02 GMT ]

  I have libc 4.5.19, and gcc 2.5.8. When I compile with -ansi, there
are a number of function prototypes that aren't visible to me. (fdopen
is what started this)

  Checking the system header, stdio.h, I find that fdopen, and a
number of others are blocked off (in this block):

> #if !defined(__STRICT_ANSI__) || defined(_POSIX_SOURCE)
> extern FILE *fdopen __P((int, __const char *));
> extern int fileno __P((FILE*));
> extern FILE* popen __P((__const char*, __const char*));
> extern int pclose __P((FILE*));
> #endif

  Why is it defined this way? I keep running across other functions
that are in the libs, and seem to work, but effectively not
predefined. This was one of my absolute least favorite aspects of
SunOS. I don't think I should be defining _POSIX_SOURCE by hand.

  Some others like 'getdtablesize' are blocked off behind other #defines
like __USE_BSD. 

  How should I go about getting access to these functions
legitimately? Especially, how can I do it so that my code is portable?
(I HATE #ifdef's done for portability).

  Seems funny, but I almost always find the I have more #ifdef's
related to which headers to include than anything really different
between systems.

--
Don Garrett                                                   Louisiana Tech
[email-masked]                                      University
                  http://info.latech.edu/~dgarrett/

--
Don Garrett                                                   Louisiana Tech
[email-masked]                                      University
                  http://info.latech.edu/~dgarrett/

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

From: [email-masked] (Zenon Fortuna)
Subject: Re: mt commands that won't work
Date: Fri, 1 Apr 1994 12:30:18 GMT

In article <[email-masked]> [email-masked] (Wolfgang Feldmann) writes:
>I wonder if it's supposed to be so that mt commands others than erase,
>reten, rewind or weof won't work. I'm using linux 1.0, the newest 
>ftape and slackware's mt.
>I'm longing for beeing able to back up more than one tar file to a tape.
>
>Wolfgang
>

1. YOU ARE ABLE to backup more than one tar file (as I am doing it all the
   time) because the "mt fsf n" works, so you can position yourself after
   arbitrary file.
   Of course to use just

        # mt fsf 1
                (or similar)
   your /dev/tape must be identical to /dev/nrmt0
   (e.g. a hard- or symbolic link).

2. There is a bug, however, in the "mt(1)", which does not allow mt to write
   to the tape (e.g. "mt eof" or "mt weof" won't work).
   I hope the mt(1) will be corrected in the next release.
   For time being you can correct it for yourself:

   I quote now the posting of Eyal Lebedinsky:
...
The source is part of 'cpio'. I went into /var/adm/packages and did a
'grep ^bin/mt' (simple when you know where to look). The sources (for
the slackware distrib) are on ftp.cdrom.com in the
/pub/linux/slackware_sources directory, organized by disk name and
package.

Now I have the missing man page.

For the original problem, the reason it will not write is because mt
explicitly opens the tape in read only mode. For myself I changed
(around line 220) the O_RDONLY to O_RDWR and did a 'make mt'.
...

   So make yourself a new mt(1), which would work without write restrictions.

        [email-masked]

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

From: [email-masked]
Subject: Re: TCP/IP-Bug in 1.0 Kernel?
Date: Fri, 1 Apr 1994 18:06:42 GMT

In article <[email-masked]>, [email-masked] (Rene COUGNENC) writes:
> Ce brave Rene COUGNENC ecrit:
> 
>> I am actually testing all kernels from 1.0 to 1.0.5 to try to find which
>> patch level introduced something making my 386/25 going into these problems.
>> So far, everything is Ok for 1.0 to 1.0.2. 
> 
>> I am actually running 1.0.3, it seems OK but I have to wait for at least
>> 1 day of uptime to be sure.
> 
> After 11 hours uptime, 1.0.3 started missing most received characters
> on the serial port. 
> 
> So the problem seems to be in patch3, and related to something about
> interrupts...

I've noticed that after about 4 days of uptime, my 1.0.4 system seems 
to get "sluggish", and things seem to be slowing down (the spinning 
globe in Mosaic, window redraws, etc.)  Rebooting cleared the problem, 
but I'd still like to know what's causing it :-(

486dx2/66, 12Megs ram, 1.0.4 kernel.

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

** 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: [email-masked]

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

    Internet: [email-masked]

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