Subject: Linux-Development Digest #107
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Fri, 2 Sep 94 20:13:08 EDT

Linux-Development Digest #107, Volume #2          Fri, 2 Sep 94 20:13:08 EDT

Contents:
  Re: svgalib can't open /dev/mem w/1.1.47 (Christopher Wiles)
  Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Mitchum DSouza)
  Re: IDE Hard Drives w/ over 1024 cylinders (Lawrence A.  Palmer)
  Re: tcl/tk XF application? (Stewart Allen)
  Mosaic and other TCP/IP problems (Stewart Allen)
  Re: ext2fs floppy/82077 corruption with 1.1.49 (login_menu)
  Re: DEC EtherWorks 3 (Kurt M. Hockenbury)
  Re: SERIAL BUG! getty_ps/Linux 1.09/Rockwell modems (Jeanette Pauline Middelink)
  Mounting Sector-translated IDE drives (Dorwin Shields)
  Re: SOCK_PACKET: Why not reading outgoing packets ? (Peter Howlett)
  Re: PRIORITY make an undelete command (Mark A. Horton KA4YBR)
  Re: Future of linux -- the sequel (Mike Kenney)
  Re: MATROX PCI Graphics board supported ?? (Yasuo Ohgaki)

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

Crossposted-To: comp.os.linux.help
From: [email-masked] (Christopher Wiles)
Subject: Re: svgalib can't open /dev/mem w/1.1.47
Date: Thu, 1 Sep 1994 15:28:20 GMT

[email-masked] (-Michael P. Lindner) writes:

: I was running the SLS 2.0 kernel, and built a 1.1.47 kernel from source
: (why mess around with older kernels :^).  All of a sudden, things which
: svgalib (gs and sasteroids, for example) stopped working with a "can't
: open /dev/mem" message.

<snip>

This should be fixed with svgalib 1.1.4.  Just fired off a message to 
Harm about both the /dev/mem _and_ dlltools 2.1.6 incompatibility.

-- Chris

[email-masked]   [email-masked]   [email-masked]
       "... but I want to use all eight comm ports SIMULTANEOUSLY!"
   PGP 2.6 public key available by finger for the clinically paranoid.

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

From: [email-masked] (Mitchum DSouza)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 2 Sep 1994 09:58:35 GMT

In article <[email-masked]>, [email-masked] (David Barr) writes:
|> In article <[email-masked]>,
|> Robert Sanders <[email-masked]> wrote:
|> >On 1 Sep 1994 10:38:46 -0400, [email-masked] (David Barr) said:
|> >> Sure, but the loader mechansim is significantly different than
|> >> Solaris', so it's not really the same.
|> >
|> >Could you be a bit less concise here?  Solaris uses ld.so to load the
|> >shared libraries; Linux uses ld.so to load the shared libraries.
|> 
|> Right.  However, as I said the loader (ld.so) is significantly
|> different between Linux and Solaris.  When I said loader I mean
|> loader.  What else shall I say?
|> 
|> Okay, I'll spell it out.  In Solaris, the filename of the shared
|> libraries to load are stored at compile-time.  There's also
|> run-time directory search list which is built from ld's -R flag and
|> LD_LIBRARY_PATH, if set.

I had patches to ld/ld.so to implement this for linux, but it is not really
worth the extra binary bloat by recording paths at compile-time. Having a
sensible cache in place is usually enough to satisfy the linking procedure.
The next-generation executable format for linux (ELF) will have this feature
by default (I remember seeing it in the EYC patches) as it is quite easy to
add sections to this format. You wll find it interesting that SunDOS which like
linux uses the standard a.out format does NOT have -R option to the linker and 
does not support path-recording. However Slowaris which uses the ELF format for
executable does have -R.

|> In Linux, there is no distinction between run-time directory search
|> lists and compile-time directory search lists, except via LD_LIBRARY_PATH.
|> Linux uses SunOS 4.x's style library cache, plus an ldconfig which
|> does a symbolic link for you to the latest version of the shared library.
|> If you have programs compiled to use a previous version of the libarary,
|> you're stuck when you upgrade.  (witness all the stuff about seyon
|> regularly breaking with each C library upgrade)

No Seyon had a bug in it. It is true to say linux is better at trapping bugs.
Our libraries are generally much more pedantic and you can not even get away 
with misdemanour let alone murder (which you can with SunOS/Slowaris). The
aforementioned systems will generally let you dereference willy-nilly, close
file descriptors multiple times, free up non malloc(ated) space etc, etc...

|> If Linux did things in more of a Solaris style, then older programs

No we don't want to follow the path of evil :-)

|> would continue working (as long as the old shared libarary was kept
|> around).  If you needed newer functionality or wanted to get rid

Hang on, I still have libc.so.2.2. I still keep around old binaries/libraries,
and they work just fine.

|> of the old library, simply recompile.  (or you could even try your
|> luck and symlink the old library to the new if it was partially
|> incompatible)

The most significant difference with linux ld.so and Slowaris/SunDOS ld.so is
that ours does not really do dynamic linking. In linux's version we just find
the libraries, mmap `em and then perform some fixups. On the contrary the other
two systems do not have their shared libraries at fixed addresses, and thus
ld.so does "true dynamic linking" using dlopen(), dlsym() for each symbol in
the binary.

Mitch

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

From: [email-masked] (Lawrence A.  Palmer)
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
Date: Fri, 2 Sep 1994 18:06:10 GMT

In article <[email-masked]> [email-masked]  
(Matthew Feldt) writes:
> I recently purchased a Western Digital 540mg hard drive on which I  
installed
> Linux on to a partition of.
> 
> Since I partitioned up the disk DOS doesn't care about the number of  
cylinders
> but while installing Linux I kept getting the following warning:
>   "The nuber of cylinders for this disk is set to 1048.
>    This is larger than 1024 and may cause problems with some software."

The only problem with Linux and > 1024 sectors I've seen is that LILO
can't deal with partitions that start at a cylinder greater than 1023
(Actually a DOS restriction, I imagine).  It doesn't matter how big
the partitions are, but it needs the first sector of each partition <
cyl 1023 to write the boot information.  So put your small partitions
first and you should be OK.

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

From: [email-masked] (Stewart Allen)
Subject: Re: tcl/tk XF application?
Date: 1 Sep 1994 18:18:09 GMT

Simon Johnston ([email-masked]) wrote:
: Has anyone had any joy finding/using the XF interface builder for tcl/tk
: under Linux. If so could you let me know where it can be found and how to 
: install.

 harbor.ecn.purdue.edu

 -- -  Stewart Allen * [email-masked] * 617.562.5826 * FAX 617.562.0038  - -- 
         M.I.S. Manager * Open Environment Corporation * 617.562.0900          
                       25 Travis St * Boston, Ma * 02134                       
 -- - -- - -- - -- "That's my story and I'm stickin' to it"  -- - -- - -- - -- 

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

From: [email-masked] (Stewart Allen)
Subject: Mosaic and other TCP/IP problems
Date: 1 Sep 1994 19:32:01 GMT

 I seem to be encountering difficulties with Linux's TCP/IP implementation.
 In Mosaic (running on Linux 1.0.9, 1.0.0, 1.1.0, 1.1.38, etc) I have the
 problem that image transfers > 5K break at 5632 Bytes always. They blitz
 up to this point then begin crawling at about 1K every 3 seconds. We have
 a T1 to the internet and the problem only occurs when moving from a fast
 transport (10BT Ethernet @ 10Mbits) to a slower medium (T1 or SLIP). When
 accessing the httpd server over straight ethernet, the problem does not
 show up. My network cohorts claim that 5632 bytes = 1 machine page + 
 minimum TCP packet + TCP header and that there may be a problem with the
 VJ conjestion control algorithms. Is this true or is the algorithm not
 even implemented?

 One other beef... the close() socket protocol is not implemented correctly.
 Instead of negotiating the close of a socket, Linux just waits 60 secs.
 and then closes the socket (/usr/src/linux/net/inet/tcp.h). For RPC servers
 that spawn when called, this is ok; the residual process just hangs
 around for an extra 60 seconds before going away. This can be seen on an
 httpd server that is under heavy load. Every access to the httpd server
 leaves a residual process for 60 secs. after completing the request. For
 RPC servers that are necessarily single-threaded, however, Linux's hack is
 not acceptable. The server must wait 1 minute before completing each
 request and accepting the next. Is there a fix for this in the works?

 -- -  Stewart Allen * [email-masked] * 617.562.5826 * FAX 617.562.0038  - -- 
         M.I.S. Manager * Open Environment Corporation * 617.562.0900          
                       25 Travis St * Boston, Ma * 02134                       
 -- - -- - -- - -- "That's my story and I'm stickin' to it"  -- - -- - -- - -- 

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

From: [email-masked] (login_menu)
Subject: Re: ext2fs floppy/82077 corruption with 1.1.49
Date: 2 Sep 1994 05:04:44 GMT
Reply-To: [email-masked]

In article [email-masked], [email-masked] (Gary Paul Gortmaker) writes:
>        This may shed some more light on the floppy corruption reported
>earlier. This only seems to happen with the more advanced floppy controller
>(reported as a "post-1991 82077") and _not_ the standard 8272A based
>controllers. (The 82077 can be found on the more expensive SCSI cards
>such as the aha-154X, buslogic cards, AMI-FastDisk, etc.)
>
>This is guaranteed to demonstrate the problem on 82077 based systems.
>I have verified it on two systems with 82077 chips on cards from
>different manufacturers. I know it did so on 47 and 48, as well as 1.1.49, 
>but can't vouch for how far it goes back. I sent this to the KERNEL
>channel, but I think the mail-server ate it.  :-(
>
>1) mke2fs a floppy
>2) mount it and copy a big (~500k) file to it (or several files)
>3) unmount it but _don't_ eject it
>4) run "e2fsck -vrf /dev/fd0" --- it will come up clean (reading the cache)
>5) eject it and immediately stick it back in (set disk change flag)
>6) Repeat step 4 -- you will get most of the blocks in the above file(s)
>   being marked as "not in use".

There is definitely something funny going on as of 1.1.49, you're right.
An even simpler test:

Stick an expendable formatted floppy in drive A:
dd if=/dev/zero count=2 of=/dev/fd0
mke2fs /dev/fd0
dd if=/dev/fd0 count=2 | od -a

You'll see that mke2fs did not actually write anything to the disk.  Syncs,
etc. do not help; I think the problem is in the block caching in the kernel.
However, if you just "cp" or "dd" a file to a floppy device it works (probably
tar works too).  The failure is not total; sometimes the above can be made to
work (e.g. playing around with the write protect tab).  The problem seems not
to be at the very lowest levels of the floppy driver, but at some intermediate
level.

>Also, a notebook that now claims to have an 8272A (but printed the message
>"floppy: FIFO enabled" with the 1.1.3X kernels) also exhibits this
>corruption. The same notebook could not even use the floppy for
>kernels 1.1.42 --> 45 (the ones that used the faster 720k step rate)

The above FDC version numbers are quite odd.  Is it possible to look
at the FDC's markings and see who's right, or ask the manufacturer?

3 msec is standard for 3.5" (and newer 5.25") floppy drives.  The 4msec
is to allow a bit more latitude for slightly out of spec drives.  The
older kernels (up to 1.1.40) used 6 msec, and on 82077s in double density
this actually came to 12 msec (very slow and noisy).

>I could not get the same sequence to produce the corruption with a
>standard 8272A based FDC.
>
>Perhaps we should have a way in which the 82077 can be used as a
>bog standard 8272A (like it was in kernels < 1.1.23) until all the 
>enhanced FIFO features of the 82077 are sorted out.
...
Unfortunately, the 82077 cannot be made to behave *exactly* like an
8272A.  Closer than it is now, yes.  It might be worth having a handy
#define to cause the FIFO not to be turned on.  However, it *WAS*
working earlier on quite a few systems; more debugging is needed on
both of these problems.

==============================================================
David C. Niemi                                [email-masked]
Which is better -- the black or the white of the printed page?
==============================================================

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

From: [email-masked] (Kurt M. Hockenbury)
Subject: Re: DEC EtherWorks 3
Date: Thu, 1 Sep 1994 01:52:19 GMT

Alan Cox ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Kurt M. Hockenbury) writes:
: >Actually, someone from dec has a driver for freebsd for this card.  (I've
: >included the post at the end of this message.)  Perhaps someone in the linux 
: >community could use it to develop a linux driver...
:
: Whats wrong with the current depca driver, this seems to cover the same
: cards (DEPCA, DE100, DE200 Turbo, DE201 Turbo, DE202 Turbo, DE210, DE422).
: The DE203,4,5 are apparently a different custom ASIC.

There's nothing wrong with the current depca driver (it's working fine
in several machines here).  However, it doesn't support the Etherworks III
cards, of which we have a few kicking about. :-)  The freebsd driver I posted 
about aparently *does* support the DE203,4,5.   

It's not much of an issue here, since we're moving towards 3c509s for 
new machines, but I just thought someone interested in writing an 
Etherworks III driver for linux might want to know about the existing
freebsd work.
        -Kurt

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

From: [email-masked] (Jeanette Pauline Middelink)
Subject: Re: SERIAL BUG! getty_ps/Linux 1.09/Rockwell modems
Date: 2 Sep 1994 08:30:08 GMT

: >Since the patch, i used getty_ps on the 2 lines of our UUCP backbone.
: >This site gets over 3400 calls a month, and is running for almost 6
: >months now... I would say 'my problem is solved :)'
: >
: Which version of the kernel are you running?
1.0.9 of the backbone (the one which get the calls) and 1.1.49 (or
whatever the highest maybe) on my own machine.

: The behavior of getty_ps when dialing-out/exiting/reinitting the modem changed
: (I believe) with the advent of the new serial drivers in 1.1.13?-18.  After
: a uucico or cu exits, uugetty does not get triggered to re-init the modem
: reliably.  For me, it does answer the phone and all that, but if a prior
: dial-out turned off ATS0=1, well, it's all over.
Ai, I try to avoid settings like that ATS0=1, because if the system
goes down for maintainance (backups -hihi) users who call don't get
an empty line. Also, when I callin occasionaly to check on the systems
and it answer I know at least getty is running.

: Something must be different when DTR toggles, but I can't even speculate
: what.
Your modem will reset itself, and the ATS0 setting will be defaulted.

OH! I placed the getty_ps patch in the Incoming dir of sunsite.unc.edu
    i assume it will be placed in the same dir as getty_ps-2.0.7e
    --> it is a patch against 2.0.7E!!!
        so it will be FSSTND and so on... do not assume your setup
        will work if you still have getty configs in /etc/default.

Groetjes,
  Pauline
+------------------------------+---------------------------------------+
| Jeanette Pauline Middelink   | email  : [email-masked]       |
| Roelof van Schevenstraat 37  | fidonet: Pauline Middelin (2:243/666) |
| 7521 SC, Enschede, (Holland) | voice  : 053-309741                   |
+------------------------------+---------------------------------------+

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

From: [email-masked] (Dorwin Shields)
Subject: Mounting Sector-translated IDE drives
Date: 2 Sep 1994 14:55:31 GMT

   I was wondering if any of the later kernels will mount  sector translated
drives--I'm running Linux 1.1.44 and it will recognize the geometry-I'm
running with multiple mode on but it still gives me an error if I try to 
mount the drive--When I load I run the Ontrack overlay--so it sets the
translation--then boot from a Linux floppy--I get the correct translated
drive parameters.
   Is this a problem with the msdos filesystem?
Dorwin

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

From: [email-masked] (Peter Howlett)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
Subject: Re: SOCK_PACKET: Why not reading outgoing packets ?
Date: 2 Sep 1994 14:35:46 GMT

Alan Cox ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Morten Jammer) writes:
: >Why can the socket typ SOCK_PACKET only read outgoing packets
: >when the interface is in promiscious mode ?

: It can definitelyt read all incoming packets on all the cards I use
: (barring etherexpress) otherwise tcpdump wouldnt work. Outgoing packet
: viewing is very recent but now works.

: Alan

Is it possible for me to get more information on how to use this
type of socket? (Can it be used to implement user level routing
protocols or packet filters?)

====================================================================
Peter Howlett                   Atlantic Systems Group
E-Mail: [email-masked]     Fredericton, N.B. Canada

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

From: [email-masked] (Mark A. Horton KA4YBR)
Subject: Re: PRIORITY make an undelete command
Date: Thu, 1 Sep 1994 01:37:39 GMT

John Henders ([email-masked]) wrote:
: In <[email-masked]> [email-masked] (Rob Janssen) writes:

: >Did you never erase a file later on the day that you first created it?
: >Or foul it up during some edit session, making you wish that you could
: >get back a version like it was 3 or 4 edit-sessions ago?

:       Isn't that what rcs is for?

                BRAVO!
        
        Yes, John... too bad most of the people screaming for an undelete function
have never worked in a real software development environment that used rcs or sccs
or some other package for revision control.   And before the flames start about 
uncessary complexity and being "too difficult to deal with," I say bull!  If set
up properly, a revision control system is almost invisible to the end user (the
programmer in this case!)  One should learn and explore the tools at hand before
screaming for others "just like they're used to".... One has to wonder if these same
people still use edlin under DOS or have taken the bold steps necessary to master
the newer "edit" editor!

        - Mark
--
"Linux!     Guerrilla UNIX Development     Venimus, Vidimus, Dolavimus."
============================================================
Mark A. Horton       ka4ybr             [email-masked]
P.O. Box 747 Decatur GA US 30031-0747         [email-masked]
+1.404.371.0291                     33 45 31 N / 084 16 59 W

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

From: [email-masked] (Mike Kenney)
Subject: Re: Future of linux -- the sequel
Date: 2 Sep 1994 05:36:18 GMT

In article <[email-masked]>,
Larry Pyeatt <[email-masked]> wrote:
>
>Compare the price/performance of processors and Intel comes out to
>make the worst processors in existence.  PowerPC chips provide twice

I have to disagree here.  The price/performance of a Pentium PC is
quite good (especially if you're running Linux :-).  I've done a lot
of shopping around in the workstation market and have run quite a
few benchmarks on various systems ... the Pentium scores quite well.
IMHO it's a much better deal than any of the low-end (< $20k) workstations
out there right now.  It's still a bit of a dog when it comes to fp
performance but you don't see serious MFLOPs in the workstation world
until you spend > $40k.

One of the most important benefits is vendor independence, I can buy
spare/replacement parts from anyone ... no need to purchase a
maintenance contract.  This was the big selling point for us, at one
time our research group was paying $35k/year in maintenance on 4
minicomputers.

-- 
Mike Kenney
[email-masked]

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

From: [email-masked] (Yasuo Ohgaki)
Subject: Re: MATROX PCI Graphics board supported ??
Date: Fri, 2 Sep 1994 13:40:15 GMT

Take a look at Xinside's ftp.

ftp.xinside.com

They have xserver for Linux, too. 
Pretty impressive spec.

BTW, it's NOT FREE

-- 
Yasuo Ohgaki
[email-masked]     
[email-masked]   
Tel/FAX (303)751-4193          Data (303)751-4263

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

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