Subject: Linux-Development Digest #283
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 9 Oct 94 15:13:06 EDT

Linux-Development Digest #283, Volume #2          Sun, 9 Oct 94 15:13:06 EDT

Contents:
  Re: Telnet & ftp freeze! (Ralph Sims)
  Re: Linux For Mac (Peter N Lewis)
  1.1.50 SIGNAL BUG! EMERGENCY (Davor Jadrijevic)
  Re: What GUI to write for? (Karl Keyte)
  Re: Improving SLIP latency under Linux (Frank Lofaro)
  Re: [email-masked] (Karl Keyte)
  Re: Multiprocessing Pentium Systems (Andrew Anderson)
  Re: Improving SLIP latency under Linux (Christopher Michael Joslyn)
  Re: Korn Shell '93 Now Available from AT&T (Chris Bitmead)
  Re: Flame on the attitude of Linux towards GCC development (Richard L. Goerwitz)
  Re: DOSEMU question (Rob Janssen)
  1.1.52 bug? (Riku Saikkonen)
  Re: Linux killed my floppy drive! (Jeff Kesselman)

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

From: [email-masked] (Ralph Sims)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
Subject: Re: Telnet & ftp freeze!
Date: 7 Oct 1994 01:36:59 GMT

[email-masked] (Colin Beckmann) writes:

>: And what about those of us that DON'T see it?  Basic setup is a
>: dedicated PPP link on a 14.4 dialup, NET-3 stuff, ppd 2.1.2a,
>: etc., with an InfoMagic/TransAmeritech CD-ROM combined install.

>I am NOT seeing th problem,  Have a  14.4 modem using NET-3 pppd 2.2.2a with 
>slackware 1.2 , and kernel 1.1.30.  I have downloaded 20 and 30 megs in a
>single session via ftp and never had a problem.  I regularly rlogin to
>other sites, once again without problem

Well, the only thing I didn't add was 1.1.51 for the kernel.  While
nothing is locking up, there is a lag while telnetting with an FTP
session going on that is annoying.  I've received a patch that I
hope to be able to roll in this weekend and do some serious testing.
Other things that run are Sendmail+IDA as a daemon, xntpd, and
CERN's web server.  The ftp session definitely takes over the system.

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

From: [email-masked] (Peter N Lewis)
Subject: Re: Linux For Mac
Date: Sun, 09 Oct 1994 11:56:11 +0800

>Henry Ware ([email-masked]) wrote:

>> Whats to tell?  The Linux FAQ lists no 68k mac ports, GNU doesn't support 
>> Apple (because of Apple's "look and feel" lawsuits), and I haven't heard 
>> of any (except for the PowerMac port).  

What do the FSF's political goals have to do with it?  GNU software is (by
definiteion) free, and people can and do port it to any platform they feel
like.  Even by discouraging this the FSF flies in the face of it's own
goals.

In any event, I've certainly heard of both a Mac 68k and Mac PPC Linux
port.  I've got no idea on the status of either.  The 68k one seems to be
doing quite well (it was discussed in a recent Lunux Journal article), and
the PPC one will almost certainly happen since future Power Mac's will
most probably be designed with the new PPC hardware standards so that
porting to a Power Mac will be equivalent to porting to most any PowerPC
machine.

I agree with Andi though, it'd be nice to have more frequent updates on
the states of all the Linux ports.  Perhaps a monthly posting listing the
current status and contact points for all Linux ports?
   Peter.
-- 
Peter N Lewis <[email-masked]> - Macintosh TCP fingerpainter
FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or
amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/

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

From: [email-masked] (Davor Jadrijevic)
Subject: 1.1.50 SIGNAL BUG! EMERGENCY
Date: 4 Oct 1994 23:10:50 GMT

/*
take linux-1.1.50, gcc 2.5.8 compile this program with

$ cc -O6 -s -N bug.c
bug.c: In function 'sig_hup':
bug.c:26: warning: passing arg 2 of 'sigaction' from incompatible pointer type
bug.c: In function 'main':
bug.c:39: warning: passing arg 2 of 'sigaction' from incompatible pointer type
$

get it running

$ a.out

and kill it:

$ killall -HUP a.out
23:59:51 emard:~/src/so
$ Unable to handle kernel paging request at virtual address 6ae58955
current->tss.cr3 = 003d5000, %cr3 = 003d5000
*pde = 00000000
Oops: 0000
EIP:    0010:0011773c
EFLAGS: 00010206
eax: 0000002b   ebx: 00000001   ecx: 00000000   edx: 6ae58955
esi: 0053304c   edi: 00000001   ebp: 0045bfbc   esp: 0045bf98
ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 0018
Process a.out (pid: 510, process nr: 18, stackpage=0045b000)
Stack: 00000000 0003b328 bffffb10 bffffb10 00000001
Code: 64 f6 02 00 66 c7 45 34 23 00 66 c7 45 40 2b 00 66 c7 45 1c

0011703c T _sys_sigaction
0011715c T _sys_sigreturn
001172fc t _setup_frame
0011743c T _do_signal         <----- this??
001177b0 t ___gnu_compiled_c
001177b0 t _get_long
001177b0 t gcc2_compiled.

Best regards, Davor
*/

#include <stdio.h>
#include <sys/time.h> /* FD_SET, timer stuff */
#include <signal.h>

struct sigaction sa;

void sig_hup(int sig)
{
 sigaction(SIGHUP, sig_hup, NULL);
}

int main(int argc, char **argv)
{
 fd_set rmask;
 struct timeval timeout, *event;

 sa.sa_handler = sig_hup;
 sa.sa_mask = 0*( (sigset_t)1 << (SIGHUP-1) );
 sa.sa_flags = (0*SA_ONESHOT) | (0*SA_NOMASK) | 
  (0*SA_INTERRUPT) | (0*SA_NOCLDSTOP);
 sa.sa_restorer = NULL;
     
 sigaction(SIGHUP, sig_hup, NULL);

 FD_ZERO(&rmask);
 FD_SET(0, &rmask);
 FD_SET(1, &rmask);
 select(2, &rmask, NULL, NULL, NULL);
}

--
<[email-masked]>, <[email-masked]>
================ Davor Jadrijevic ====================

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

Date: Tue, 4 Oct 1994 15:40:23 +0100
From: [email-masked] (Karl Keyte)
Reply-To: [email-masked]
Subject: Re: What GUI to write for?

Check out also the OI kit from ParcPlace - builds for OpenLook or Motif. You
can select which toolkit look & feel you want at RUN-TIME!

It's freely available for Linux and a new version is expected sometime
following the stable releases of Linux (1.2), libraries (4.6) and gcc (2.6).
XFree 3.1 is already out.

Karl

=========================================================================
Vitrociset S.p.A.                               Tel   : +(49) 6151 902041
European Space Agency                           Fax   : +(49) 6151 904041
64293 Darmstadt, Germany                        e-Mail: [email-masked]

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

From: [email-masked] (Frank Lofaro)
Subject: Re: Improving SLIP latency under Linux
Date: Fri, 7 Oct 94 16:10:24 GMT

In article <[email-masked]> [email-masked] (David - Morris) writes:
>[email-masked] (Michael Callahan) writes:
>
>
>>I personally don't see how this can be better than TOS queuing,
>>without changing the SLIP or PPP protocols.  With TOS, an interactive
>>packet will always go out before any FTP packets that are waiting.
>
>Well, it is not always possible (and historically rarely possible)
>to tell if a connection really deserved TOS queuing at high
>priorities.  A couple expamples ... a terminal session being used
>to 'download' a large file; a terminal emulator with a programable
>interface (TN3270 w/Chameleon for NETMANAG or PC/3270 from IBM)
>performing batch bulk transactions, file downloads, etc.
>
>Dave Morris
>

How about giving packets below a certain size higher priority?
That would help interactive traffic, and handle cases such as downloads 
though a terminal session properly.

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

Date: Tue, 4 Oct 1994 16:12:35 +0100
From: [email-masked] (Karl Keyte)
Reply-To: [email-masked]
Subject: Re: [email-masked]

In article [email-masked], [email-masked] (Rob Janssen) writes:
>But unfortunately you can't specify the address yourself.  It blindly
>takes the address it finds in the From: line.  This loses badly when your
>address has changed, or the translation of the From: address which happens
>in the mail routers has changed.
>
>I have experienced already two times that the only way to unsubscribe was
>to write a message to the operator :-(

The change in mail routing is exactly the problem I have.  I cannot unsubscribe.
I have also tried mailing root, postmaster and operator, but to no avail. I think
the system needs to be made a little more inteligent in its handling of addresses.

How do I even SEE the addresses it THINKS it has for me?

Karl

=========================================================================
Vitrociset S.p.A.                               Tel   : +(49) 6151 902041
European Space Agency                           Fax   : +(49) 6151 904041
64293 Darmstadt, Germany                        e-Mail: [email-masked]

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

From: [email-masked] (Andrew Anderson)
Subject: Re: Multiprocessing Pentium Systems
Date: 4 Oct 1994 23:21:36 GMT

Just curious:  Does anyone have an MP system that they can try running
Linux on?  Does it croak, or just not take advantage of the 2nd CPU?

Also, I've been looking at the MP Pentiums, and I was wondering if I 
purchased a system with just 1 CPU and added a second later when Linux 
gets some kind of MP support if that would work.

--
|===========================================================================|
|  Andrew Anderson                              [email-masked]          |
|  Novell Network System Administrator          "Making the impossible      |
|  Linux System Administrator                    possible -- daily!"        |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

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

From: [email-masked] (Christopher Michael Joslyn)
Subject: Re: Improving SLIP latency under Linux
Date: Tue, 4 Oct 1994 23:18:38 GMT

In article <[email-masked]>,
Michael Callahan <[email-masked]> wrote:
>In article <[email-masked]>,
>Christopher Michael Joslyn <[email-masked]> wrote:
>>In article <[email-masked]>,
>>Nick Kralevich <[email-masked]> wrote:
>>>
  >>>Is there any way to improve/derease the latency associated with
>>>SLIP under linux?  Specifically, when I am ftping a large file,
>>>I frequently get ping times of 6+ seconds.  This murders interactive
>>>traffic.  I've tried setting my MTU to 256, but it doesn't make
>>>any difference.
>>
>>The main problem is that an ftp packet is much larger than, say, a telnet or
>>ping packet.  Because the ftp packet is large, the packets must be broken up
>>into sizes that can be sent over the line (this is your MTU at work), thus
>>the ftp packet takes longer to send.  Additionaly, an ftp connection typically
>>is doing things in a batch where it is constantly pushing these large packets
>>onto the queue.  Factor all things in and what you get is a long queue filled
>>mostly with ftp packets and a few, notably smaller, interactive packets.
>
>If you use recent client programs and a recent kernel, Linux PPP and
>SLIP will send interactive packets before FTP ones.  Recent clients
>will set the IP TOS (type-of-service) field to favor interactive
>traffic, and recent kernels know to send packets with "minimize
>latency" TOS before anything else.  They even know how to do this
>for packets they are routing.

IMHO, this sounds like a very simple way of doing things, however, I have
the following problems with TOS:
    (a) Any user can build a copy of ftp that resets the packet TOS back to
        interactive, putting the network right back where to it started.
    (b) TOS only has two levels--interactive, and non-interactive.  However,
        most network applications really should be considered at more levels
        than two.  For example, I would order them as: telnet/r* should be
        first, NFS should be second, HTTP should be third, ..., and ftp
        should be last as long as it doesn't cause a timeout.
    (c) Users must upgrade all their, possibly customized, client applications
        for this to work.
    (d) Extensive kernel modification was needed.
    (e) The prioritization is static.  I believe that different networks
        have different needs and may want to control their network traffic
        more than others.

In all actuality, I wish I would have know about the TOS modifications before
I started this patch Lars and I've been working on.  I must have the older
clients which don't support TOS.  I'd really like to take a look at the
performance differences.  Has a package been created where I could grab one
file and have all the latest client applications (e.g., which Slackware
(version ?) file(s) do I need)?

>So, if you set up a link with a small MTU, you should get OK performance.

What do you consider small?  I have a MTU of <=1006 which isn't too bad
considering I can usually get 1.6 kb/s using ftp.

>>>Theres was a thread a couple of months ago that said the problem
>>>was in the kernel.  However, there was never a solution posted.
>
>I don't remember the thread, but it is possible that it was before
>the kernel did TOS queuing properly.  I think that would have been 
>many months ago, though.

Yeah, I missed it too.  What version of the kernel (and client apps) started
using TOS properly?

>>Not really.  It is a network problem.  Lars Fenneberg ([email-masked])
>>and I are currently working on a package that would balance the load on a
>>SLIP or PPP dial-up network connection.  Unfortunantly, we are just getting
>>started and will be a little bit before it is complete.  The implementation
>>at this time simple slices the bandwidth into equal sections so each
>>connection has an equal bandwidth.  What we are planning on adding is
>>unequal sharing.  Interactive connections would probably have more of the
>>bandwidth since they usually transmit in bursts.  The ftp connection would
>>then be slowed during these bursts and then be back up to speed when nothing
>>else is communicating.  Of course, this kind of unequal sharing will be
>>tunable at runtime.
>
>I personally don't see how this can be better than TOS queuing,
>without changing the SLIP or PPP protocols.  With TOS, an interactive
>packet will always go out before any FTP packets that are waiting.
>If the interactive traffic wants more bandwidth than is available,
>there will be user-visible delays, no matter what your priority
>scheme.  If it doesn't want more bandwidth than there is, it will 
>get as much as it asks for, in preference to the bulk traffic.

From a simple, single user, standard installation stand-point, I agree,
there wouldn't be much difference.  However, I'd like to have a way of
dynamically changing the packet weights depending on the network traffic.

>Actually, I guess there is one thing you could do.  You could set
>things up so that if an interactive packet gets queued while a bulk
>packet is in the middle of transmission, you immediately interrupt
>the bulk packet (by sending an end-of-frame character and relying
>on the remote end to discard the incomplete frame) and start the
>interactive one instead.  Ugly, and I don't recommend it for SLIP
>(which has no link error detection).  It would improve latency
>somewhat.

<shutter>  Sounds like a nightmare of an operation.  I have a hard
time thinking of what could generate a packet so big that you would
need to actually cut if off mid-transfer.

>On the other hand, it's fine for people to implement whatever they
>want.  Whatever floats your boat.

No, I really appreciate the comments.  I helps us all, especially me.
Thanks.

 - Chris

-- 
----  Purgamentum Init, Exit Purgamentum  ------------------------------------
Christopher M. Joslyn  | Visual Numerics, Inc.   |   "A la fin de l'envoi,
+1 (303) 581-3269      | 6230 Lookout Road       |      je touche!"
[email-masked] | Boulder, CO 80301       |  My opinions are mine!

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

From: [email-masked] (Chris Bitmead)
Subject: Re: Korn Shell '93 Now Available from AT&T
Date: 4 Oct 94 15:24:37

In article <[email-masked]> [email-masked] (Andrew J. Piziali) writes:

>In article <[email-masked]>, James E. McNalley
><[email-masked]> asked:
>   
>    What does ksh do that BASH can't do?
>
>How about coprocess communication (print/read -p ...), the "select"
statement,

Recent versions of bash have "select"

>builtin arithmetic, 

bash has builtin arithmetic

>a command line editor which will drop you into vi/emacs,

bash has this.

>and parameter attributes (typeset -LZ ...), to name a few?

Don't know about this.

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

Crossposted-To: comp.os.linux.help,comp.os.linux.misc
From: [email-masked] (Richard L. Goerwitz)
Subject: Re: Flame on the attitude of Linux towards GCC development
Reply-To: [email-masked]
Date: Fri, 7 Oct 1994 20:24:30 GMT

[email-masked] (Xiaojun Zhu) writes:
>
>Think about the scenario, when linus announced his first release of
>linux and no body wanted to try that out? You know the answer,
>don't you?

I think if everyone beta tested every piece of software to come out,
no one would every get any work done.  We all select the stuff that
is most important to us, and try to help out as best we can.  I'm
currently working hard to help get kinks out of DOSEMU, which I think
is a worthwhile project.  It takes a lot of time, and I have to weed
through a lot of debugging output and ftp patches every couple of days
(plus the ones the authors want me to try out).

I simply could not do this for every piece of software.

-- 

   -Richard L. Goerwitz              [email-masked]
   [email-masked]          rutgers!oddjob!ellis!goer

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

From: [email-masked] (Rob Janssen)
Subject: Re: DOSEMU question
Reply-To: [email-masked]
Date: Tue, 4 Oct 1994 22:30:32 GMT

In <[email-masked]> [email-masked] (Douglas Rankin) writes:

> I have a question. I have been able to get dosemu0.53 running with a
>diskiamge for c: I was wondering how I configure it in order for it
>to boot my dos drives which is /dev/sda. My linux is on /dev/sdb1.
>Any help would be appreciated. You can reply here or email me at the
>following:

>       [email-masked] or
>       [email-masked]

>thanks for any help!!!!

Your best bet is to move the diskimage to a:, boot from that, and then
lredir the /dev/sda disk to c:

Booting from diskimage in a: is simple:

bootA               # Startup drive valid values:  bootA  bootC

#    Use the following option to boot from the specified file, and then
#    once booted, have bootoff execute in autoexec.bat. Thanks Ted :-).
#    Notice it follows a typical floppy spec. To create this file use
#    dd if=/dev/fd0 of=/var/lib/dosemu/bdisk bs=16k
#
bootdisk { heads 2 sectors 9 tracks 80 threeinch file /var/lib/dosemu/bdisk }

You can still have both floppies available:

floppy { device /dev/fd0 threeinch }  
floppy { device /dev/fd1 fiveinch }  

Then, in the config.sys on the image, put something like:

files=30                                                                        
buffers=5                                                                       
lastdrive=h                                                                     
stacks=0,0                                                                      
dos=high,umb                                                                    
device=a:\setver.exe                                                            
devicehigh=a:\emufs.sys /dos                                                    
devicehigh=c:\dosemu\ems.sys                                                    
shell=c:\command.com /e:512 /p                 

In the autoexec.bat on the image, put something like:

@echo off                                                                       
prompt $p$g                                                                     
c:                                                                              
path c:\dosemu;c:\bin;c:\dos
set comspec=c:\command.com                                                      
set dircmd=/o/l                                                                 
set lib=c:\lib                                                                  
set tz=MET0                                                                     
lh c:\dos\doskey.com >NUL                                                       
lredir d: LINUX\FS\cdrom R >NUL                                                 
lredir e: LINUX\FS\ R >NUL                                                      
lredir                                                                          
c:\dosemu\bootoff.bat                                                           

Finally, you have the file \dosemu\bootoff.bat on the DOS disk:

bootoff

This does the trick.  C: is now a redirected drive, and A: and B: are
the floppies again.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

Subject: 1.1.52 bug?
From: [email-masked] (Riku Saikkonen)
Date: Sun,  9 Oct 94 17:16:00 +0200

Hmm... Linux crashes on me, seemingly randomly. Nothing works
after the crash, not virtual console switching, not Ctrl-Alt-Del.
'Unable to handle kernel paging request' and the normal register dump
appears in the log, for two or three processes. The EIP is in a totally
different location each time...

So, it seems that it's the 1.1.52 kernel which is having some problems.
I noticed some modification of memory.c in the .52 patch; perhaps that's
the culprit?

Anyone else seen the same problems?

I can't be really sure if this is a kernel bug, because I just did a
quite heavy upgrade of the machine (switched to a VLB motherboard +
display adapter + IDE host adapter). That's why I'm asking...

Hmm, now I compiled 1.1.50, and it seems to work. Except for one crash
in X, but that is probably something else (no kernel panic or anything
in the log). So I think it is a bug in 1.1.52...

-=- Rjs -=- [email-masked] - IRC: Rjs
"From cavern pale the moist moon eyes / the white mists that from earth
arise / to hide the morrow's sun and drip / all the grey day from each
twig's tip." - J. R. R. Tolkien

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Jeff Kesselman)
Subject: Re: Linux killed my floppy drive!
Date: Tue, 4 Oct 1994 05:33:47 GMT

In article <[email-masked]>, Ahmed Naas <[email-masked]> wrote:
>
>
>So, did Linux kill my drive or is this one of those rare coincidences?
>
>-- 

Well, I've nevre heard of software killing a floppy drive, and I boot 
from my floppy and have created multiple boot floppies without trouble.

Sounds like coincidence to me, but I could be wrong.

Jeff Kesselman

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

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