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

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

Contents:
  Re: Hardware PROBLEM HELP! (Steven M. Doyle)
  Re: ext2fs vs. Berkeley FFS (Albert D. Cahalan)
  [fixed] lmail problem with sendmail (Tim Bass (Network Systems Engineer))
  Re: Improving SLIP latency under Linux (Al Longyear)
  Re: umount problem! (Steven Pritchard)
  Re: [fixed] lmail problem with sendmail (Arnt Gulbrandsen)
  Serious Bug In The Networking Code (Ketil Z Malde)
  Re: [email-masked] (Mark Hahn)
  Re: NCR53c810 card and Technoland (Michael J. Ashmore)
  Re: What GUI to write for? (Terry Lambert)
  Re: Adaptec 2940 Support? (Robert R. Richter)
  Re: Telnet & ftp freeze! (System Administrator)
  Re: Text modes? (Stormy Henderson)

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

From: [email-masked] (Steven M. Doyle)
Subject: Re: Hardware PROBLEM HELP!
Date: 8 Oct 1994 02:55:17 -0700

In <[email-masked]> [email-masked] (Axel Winter) writes:

>I really have a problem with my hardware ... If I touch
>any place of the system or a conected part (priter, termial)
>at a place where is steel, i get a eletric shock. Next to that

You might want to make sure that your power outlets are all earth-groudned.
This is commonly not the case in many homes in the US, at least, (mostly
older homes), and could conceivably cause that condition.

-- 
| Steven Doyle, AKA World Creator   | #include <std_disclaimer>              |
| Sysop, NETDimension (818)592-6279 | For information on Artificial Worlds   |
| [email-masked]               | send email to [email-masked] for  |
| [email-masked]        | an information package.                |

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

From: [email-masked] (Albert D. Cahalan)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 09 Oct 1994 18:41:48 GMT

In article <[email-masked]> [email-masked] (Chris Bitmead) writes:
   >I think it's important to keep in perspective that performance 
   >is only one aspect of the equation.  It may be reasonable to 
   >compare ext2fs to FFS on this basis, but FFS dates from about
   >(I think) 4.1 or 4.2 BSD.  I think the issue today is flexibility
   >as much as it is performance.
   >
   >Ext2fs supports a limited set of extended attributes (append, immutable,
   >secure delete, uneraseable, synchronous) and the sources indicate
   >that ACLs will be available in the future.  But these are all 
   >kernel space extensions.  You can't associate some arbitrary piece
   >of data (that stays with the file when copied) with the file without
   >writing it in the data stream somewhere.  By contrast, HPFS allows
   >up to 64K of extended attributes per file.  NTFS goes the full 
   >distance by allowing multiple arbitrary streams per file, although
   >there doesn't seem to be any documentation on how to exploit this
   >in the Win32 API manual.
   >
   >I know this doesn't sound very UNIXy, but how difficult would
   >it be to implement a filesystem with some sort of arbitrary
   >extended attributes like those in NTFS or the more limited ones
   >in HPFS?  

   Not very hard to do, but why clutter up the operating system with more
   features, when directories will do exactly what you want?

You would not be able to distinguish the special directories from other ones.

I think 3 or 4 bits could be spared for extended attributes like this:

0  flat file (default)
1  NEW record file
2  Mac file
3  NT file
4  OS/2 file
5  DOS executable
6  Windows executable
7  etc.

Decide how (and if) the standard calls will open the new file types, then add the
required new calls.

Want to reduce OS clutter?  Take executable formats and library support out of
the kernel.
--

Albert Cahalan
[email-masked]

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

From: [email-masked] (Tim Bass (Network Systems Engineer))
Subject: [fixed] lmail problem with sendmail
Date: 9 Oct 1994 17:01:02 GMT

[ Article crossposted from comp.os.linux.admin ]
[ Author was Tim Bass (Network Systems Engineer) ]
[ Posted on 9 Oct 1994 16:59:55 GMT ]

This really surprises me.....

I pulled down the sendmail + IDA package from tsx-11.mit.edu (forget the
exact name of the file, sorry - can get it if anyone cares) and found
that the lmail binary had trouble writing to the /tmp file.

Looking at the src for lmail.c the code contains the line(s):

if (fputs (line,fp) != strlen (line)) {  ...  }        

in the source.

Doing some detective work yielded that fact that fputs() was always 1 and
never equaled strlen() even though the write was okay.

I changed the line to read:

if (fputs (line,fp) < 0) { ... }

and all was okay.  Is fputs() okay?   

Anyway, knowing the problem is 99 percent of the solution and sendmail
is working on linux, delivering to the local users just fine.  

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

From: [email-masked] (Al Longyear)
Subject: Re: Improving SLIP latency under Linux
Date: Sun, 9 Oct 1994 18:15:36 GMT

[email-masked] (Rob Janssen) writes:

>>The best solution is to simply choose the priority when you do the
>>transmission and then send it in that order.

>That only helps when there are as little buffers as possible between the
>point where this decision is made and the line.
>Although the buffers in the modems are a problem, I don't think they are
>the full explanation of 6 second roundtriptimes when an FTP is running.
>Probably some frames get queued up in the kernel "waiting to be sent on
>the serial line".  That is not good...

Rob,

New frames are merged into the list of frames bound for the SLIP/PPP/
PLIP link in order based upon their priority. Each new frame is
inserted into the list in sequence. They are not simply tacked on to
the end of the list.

So, yes, it is a very good solution to implement and use the
IP_TOS. All higher priority frames will be sent before lower priority
frames are sent.

For this to work the best, you need to implement IP_TOS on both sides
of the link. If you are doing an ftp transfer to read a large file,
then it the remote side (the one running ftpd) which is doing the
majority of the transmission. Their frames need to have a background
(7) priority. The wu-ftpd process has had this implemented for some
time. Unfortunately, not all implementations of TCP/IP support this
logic. The BSD 4.3 code did not. I believe that it is in place for
the BSD 4.4 code.

There have been kludges to support the queueing in the PPP or SLIP
drivers.  They look at the port numbers being used and determine a
"priority" based upon the list of known interactive ports. THIS IS A
KLUDGE. It is only because the TCP/IP software did not allow the
application to specify the proper value.

(Morningstar PPP/SLIP and the BSD pppd package are two that I am
familiar with doing this kludge.)

>Peeking in the TCP headers inside the IP routing code (checking for port
>numbers, so that 20 and 25 can get a lower priority than 23 even when the
>TOS is the same) seems to be the best solution...  (although dirty)

Why bother? It is done in all of the daemons and client code now in
place for Linux.

The default priority is TOS_THROUGHPUT (0x08). Most of the sockets
will generate IP frames of this priority. I suppose that you could do
it for those frames. It would imply that the priority was not
specified. However, if the value was specified then I think that you
should leave it alone.

However, as the saying goes, "the proof is in the pudding". Please
feel free to make the changes that you see fit to your copy of the
kernel and try it out. I would be interested in hearing about your
results.

I do ask one favor (or condition if you wish). That is that you use
the current kernel 1.1.52+ and the latest versions of all of the
networking software. (If you use my favorite ftp client, ncftp, then
you need a fairly new one which supports the IP_TOS socket option.)

>In fact I think the "always use a big window because that performs so
>nicely on fast links" may be not optimal.  One could argue that the optimum
>window size for a TCP is such that it can just keep sending (i.e. an
>ACK comes back just when the sending TCP runs out of send window), and
>not much larger than that.  The sending TCP could adapt its send window
>accordingly (staying below the negotiated window size).

That is the slow start algorithm presently in place.

-- 
Al Longyear           [email-masked]

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

From: [email-masked] (Steven Pritchard)
Subject: Re: umount problem!
Date: 4 Oct 1994 00:56:31 -0600

Similar story:  I was trying to umount a DOS floppy after doing a couple 
of writes to it and got this (kernel 1.1.51):

Oct  3 14:49:18 Osiris kernel: Oops: 0000
Oct  3 14:49:18 Osiris kernel: EIP:    0010:00166130
Oct  3 14:49:18 Osiris kernel: EFLAGS: 00010246
Oct  3 14:49:18 Osiris kernel: eax: 00160000   ebx: 00000000   
        ecx: 00000000   edx: 00160000
Oct  3 14:49:18 Osiris kernel: esi: 0030ded4   edi: 0030ded4   
        ebp: 00000000   esp: 0030dea8
Oct  3 14:49:18 Osiris kernel: ds: 0018   es: 0018   fs: 002b   
        gs: 002b   ss: 0018
Oct  3 14:49:18 Osiris kernel: Process umount (pid: 1862, process 
        nr: 20, stackpage=0030d000)
Oct  3 14:49:18 Osiris kernel: Stack: 001b0200 001b0002 00126193 
        0030ded4 00000000 
Oct  3 14:49:18 Osiris kernel: Code: f6 01 02 74 0d 0f b7 46 10 50 
        e8 bd be fb ff 83 c4 04 be d8 

Which appears to come from _floppy_release (if I understand this 
properly).  Here's the ouput from 'nm /usr/src/linux/tools/zSystem|egrep 
"1661"':

001661dc t _floppy_open
0016610c t _floppy_release

Everything seemed to get written to the floppy properly, so I guess it is 
no big deal.  Curious to know if this can be prevented in the future though.

For future information:  just where should this sort of thing be reported?

Steve
-- 
[email-masked]  | Southern Illinois Linux Users Group
(618)549-8579             | Meetings the 1st and 3rd Mondays of every month.
Steven Pritchard          | http://nyx10.cs.du.edu:8001/~spritcha/home.html

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

From: [email-masked] (Arnt Gulbrandsen)
Subject: Re: [fixed] lmail problem with sendmail
Date: 9 Oct 1994 17:52:35 GMT

In article <[email-masked]>,
Tim Bass (Network Systems Engineer) <[email-masked]> wrote:
>Looking at the src for lmail.c the code contains the line(s):
>
>if (fputs (line,fp) != strlen (line)) {  ...  }        
>
>in the source.
>
>Doing some detective work yielded that fact that fputs() was always 1 and
>never equaled strlen() even though the write was okay.

This bug was reported a long time ago, a year perhaps.  Perhaps you
could upload a fixed version?

The problem is really that the successful return value of fputs() and
puts() isn't specified.  The man pages I have say it should return
EOF and -1 (EOF is, I hope, -1) on error, but don't say anything
about success.

--Arnt

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

From: [email-masked] (Ketil Z Malde)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: Serious Bug In The Networking Code
Date: 9 Oct 1994 18:33:07 GMT
Reply-To: [email-masked]

There appears to be a serious bug in some of the networking code
supplied with linux/slackware, that causes the computer to get
'network unreachable' after approximately 3 minutes of perfect
functioning.  I have no idea what the problem might be, and if
somebody tell me where to look, I can try to figure out what versions
my drivers etc. are.  Here are the configurations I ve gotten this
problem with:

AMD DX2/66, 8Mb, VLB CL5428 1Mb with either
* Etherlink II, kernel 1.1.50 and 1.1.49
* SMC Ultra Combo, kernel 1.1.33, 1.1.49, 1.1.50
        -tried both coax and TP
* SMC Ultra something else, also with various kernels

AMD 386/40, 12Mb,
* SMC Ultra Combo, kernel 1.1.33

The 386 works perfectly well with the network with both cards when
using older software (Some old SLS distrib. I believe)

I would very much like to know what is wrong, and how to fix it.

There is also a 'bug' in df, causing a float exception when it cannot
access a non-existent NFS-mount.

Thanks for any help,
--

 « Ketil Malde                        In real life:  [email-masked] »
 « Nuke The Whales!  Pave The Earth!  And Honk If You Love Unicorns! »

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

From: [email-masked] (Mark Hahn)
Subject: Re: [email-masked]
Date: 4 Oct 1994 07:06:25 GMT

> 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 :-(

some sendmails have a -f switch for forging From: lines,
and you can always do it by hand by telnetting to their smtp port.

regards, mark hahn.
--
operator may differ from spokesperson.          [email-masked]

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

From: [email-masked] (Michael J. Ashmore)
Subject: Re: NCR53c810 card and Technoland
Date: 9 Oct 1994 18:25:19 GMT
Reply-To: [email-masked] (Michael J. Ashmore)

In a previous article, [email-masked] (Stavros J Haidos) says:

>  In the scsi-howto it states that you can get a NCR56c810 card that will work
>on the pci bus. When I called up the number given for Technoland they told me
>that the card will only work on one type of pci mother board and that it will
>not work on a 90 mhz 586 mother board. Is this true? Is there any way I can
>get a board like this to work on a P90 and under linux? Please help. Thanks!
>
>--
>               -Steve
>
Well, I'm running a Zenon P90, and I have a NCR53c810-based PCI card
working just fine ... it seems to be a generic card; the only dox Zenon
gave me was a techsheet (1 page, front only) identifying the chip and
giving some basic info on termination :(
Though the sheet is called "Quick Reference guide for PCI-SC200" -- there
doesn't seem to be a brand attached.

Incidentally, I'm trying to set up Linux here, using the Slackware release,
but can't seem to get any of the updated kernels to compile completely --
using 1.1.50, config, dep, and clean all compile nicely, but zlilo just
hangs -- or at least I'm *assuming* it's hung; it stayed on "main.c" for
over 15 minutes... not normal on a Pentium :/
Without an updated lilo, I can't boot from my SCSI drive -- major
annoyance.

-Mashmore

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

From: [email-masked] (Terry Lambert)
Crossposted-To: comp.windows.x.intrinsics,gnu.misc.discuss
Subject: Re: What GUI to write for?
Date: 9 Oct 1994 22:35:11 GMT

In article <[email-masked]> [email-masked] (Torgeir Veimo) writes:
] |> 5) There's the window manager.  Nobody but OSF has one of these.
] 
] I can't quite agree on this, since I use fvwm every day. It has motif style
] decorations, and to my knowledge does it also understand the motif api
] decoration and menu function hints. And if there is something wrong, you
] could allways hack the code....

Can you set the config information in the correct Motif compliant config
files and have it behave like mwm would?  Nope.

Also, there's a problem with it killing clients when you click the heck out
of the mouse (nettrek, etc.).

All in all, I use it because I have a thing against licensing Motif, but
I knew mwm, and fvwm's no mwm.  8-).

                                        Terry Lambert
                                        [email-masked]
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

From: [email-masked] (Robert R. Richter)
Subject: Re: Adaptec 2940 Support?
Date: Sun, 9 Oct 1994 11:43:35 GMT

Michael_Nelson ([email-masked]) wrote:
: I've got my roommate convinced to switch over to Linux from Unixware.  He's
: running a Mylex P5/66 EISA/PCI motherboard and is using an Adaptec AHA-2940
: PCI/SCSI card.  I can't find any evidence that the 2940 is yet supported by
: Linux, though.  Is anyone working on a driver or kernel patch to support
: this host adapter?

Hi Michael !!

I have a 2940, too !! :-)

And no device-driver :-( !!

If you get any response, please mail to me !!

THANX,
Robert.

--
      DRAXX-Online-Systems        |  DRAXX (Robert R. Richter)
 ------------------------------   |  E-Mail 1   :   [email-masked]
   +49 9562 7986  (RING-DOWN)     |  E-Mail 2   :   [email-masked]
 ==============================   |  CompuServe :   [email-masked]

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

From: [email-masked] (System Administrator)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
Subject: Re: Telnet & ftp freeze!
Date: 7 Oct 1994 21:14:06 GMT

Peter H. Lemieux ([email-masked]) wrote:
: In article <[email-masked]>, [email-masked] (Ralph Sims) says:
: >
: >Other things that run are Sendmail+IDA as a daemon, xntpd, and
: >CERN's web server.  The ftp session definitely takes over the system.
: >

: Remember that FTP is running two simultaneous sessions with the other host, 
: a data channel and a control channel.  With only a standard two-wire modem,
: the line must be repeatedly turned around from TX to RX and back again.
: (Four wire, dedicated-line modems are pricey.)  Services like news and
: the web have little upstream traffic, mostly downstream, since they
: have no control channel.

Pardon, but I don't think this is correct.  Most 2 wire modems multiplex
the bandwidth and *do* allow simultaneous bi-directional data flow.  You
may be thinking of some data protocols that require packets to be
acknowledged by the receiving end before sending additonal ones, but this
has nothing really to do with what is flowing on the line itself.  I
haven't seen real 'line-turn around' modems since dealing with some
ancient Burroughs stuff nearly 20 years ago.  And even then the more
common 300 bps 2 wire modems *most* people were using were bi-directional,
using 4 tones, 1 pair to code 1's and 0's going one way, and the other
pair for data going the other.  

George Nemeyer        ([email-masked])
System Administrator
Tigerden.com

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

From: [email-masked] (Stormy Henderson)
Subject: Re: Text modes?
Date: 9 Oct 1994 21:39:22 GMT
Reply-To: [email-masked]

Matt Hudson wrote:

   I don't know if anybody is willing to do work on this or not... or if 
   enough people are even interested. 

I found a kernel patch that adds four new text modes to any vga card, I've 
installed it and it works perfectly for me.  With my new font size, I can
delete X cause I don't need it anymore.  (c:

The added sizes are 80x30, 80x36 (the one I'm using), 80x40, 80x44

I'm going to ftp the patch to sunsite incoming as textmodes.gz if anyone is
interested in trying it.

Be happy...

- Stormy the happinator     "The Moving Finger writes; and, having writ
                             Moves on: nor all your Piety nor Wit
  Reply to:                  Shall lure it back to cancel half a line, 
  [email-masked]    Nor all your Tears wash out a Word of it."

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

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