Subject: Linux-Development Digest #851
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:     Thu, 23 Jun 94 07:13:04 EDT

Linux-Development Digest #851, Volume #1         Thu, 23 Jun 94 07:13:04 EDT

Contents:
  Re: Disk-compression for Linux (Andrew R. Tefft)
  dosemu-0.52 + CIM (Eckard Kopatzki)
  Re: Strange stty/logout problem in 1.1.20 (Jon Green)
  Where has Stephen Tweedie gone?? (Paolo Zeppegno)
  Smail mod/SO_LINGER time? (Lee J. Silverman)
  Re: Has anyone gotten the wretched All-in-one Ethernet adapter to work? (Piotr Kapiszewski)
  BUG: ReRead Partition Table (HIGGINS@DELBOX.ZER.DE)
  Re: ntfs filesystem on di (Andrew Grillet)
  Re: Novell NCP Documentation Available! (was Re: IPX Netware Protocol) (Dave Goldblatt)
  Pathological program (James H. Haynes)
  Re: Runtime compilation and execution (Matthias Urlichs)
  Strange stty/logout problem in 1.1.20 (Kevin Lentin)
  HD problems with 1.1.21 (Gary Schrock)
  Re: linux-1.1.20 breaks dosemu0.52 (Timothy J. Corcoran)
  Re: Strange stty/logout problem in 1.1.20 (John Lellis)
  Re: Disk-compression for Linux (Peter Herweijer)
  Re: Hard disks limited to 16 heads? (Peter Herweijer)

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

From: teffta@cs690-3.erie.ge.com (Andrew R. Tefft)
Subject: Re: Disk-compression for Linux
Date: Wed, 22 Jun 1994 01:44:03 GMT

This topic gets beaten to death but there is one approach I like.
It is kind of a compromise approach between doublespace-style compression
(reputation for being slow or unreliable) and gzexe style (compress
individual files and uncompress each on demand -- slow to uncompress
every time). I don't remember the name of the product (something
like PowerDrive -- I got a demo but it crashed my 690 server),
but the idea was a nightly cron job compressed a configurable set
of files. The first time one of those was accessed, it was transparently
uncompressed and put back *in place* and left uncompressed till
the nightly compression run. 

ls -l showed the uncompressed size, and backups could be done on
the compressed or uncompressed files. The speed hit only happens
on the first file access of each day (or week, or however you configured
it). It used a loadable device driver to provide the transparency.
I wish I could have used it on at least one of my disks of seldom-used
data... oh well.
-- 

Andy Tefft               - new, expanded .sig -     teffta@cs690-3.erie.ge.com

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

From: root@stevie.isar.muc.de (Eckard Kopatzki)
Subject: dosemu-0.52 + CIM
Date: 22 Jun 1994 00:29:59 GMT

Hi all,

has anybody managed to get the CompuServe Information Manager (CIM) up and
running under dosemu-0.52? (I know this question concerns 'enemy's territory'
but I really need CIS for professional purposes (in fact, it was the reason I
started with thinking about dosemu ...)) I'm kicked off at the point where CIM 
tries to connect in most cases (sometimes even if it tries to build up it's
screens).

Any hints would be appreciated!

-- 
Eckard Kopatzki           Internet eko@isar.muc.de
Therese-Giehse-Allee 53     CompuServe 100024,2175
D-81739 Muenchen, Germany     Voice +49-89-6378103

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

From: greenjc@nor2vax.norand.com (Jon Green)
Subject: Re: Strange stty/logout problem in 1.1.20
Date: 22 Jun 1994 14:34:25 GMT
Reply-To: GREENJC@norand.com

>With 1.1.20 suddenly, when I log in and my .login does an stty (it does 2,
>stty crt -ctlecho and stty erase ^?) the stty gets suspended (actually, I
>believe it's the .login being suspended) and I get a shell. If I 'fg' the
>suspended stty I get logged out
>
>The processes are reporting as being suspended on tty output.

Did you "make clean" before compiling the kernel?  I had this happen back on
1.1.17 I think, where the new kernel seemed to break the shell's job control.
csh and tcsh would not work properly, but sh (with no job control) worked
just fine.  This seems to be the standard thing that happens when people don't
"make clean" first.  Maybe it's deliberate, so that we're forced to do a
complete recompile. :)

So, anyone want to offer a technical explanation for this? :)


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

From: paolo@to.sem.it (Paolo Zeppegno)
Subject: Where has Stephen Tweedie gone??
Date: 22 Jun 1994 13:30:48 +0200

Having been a Linuxer from the 0.12 days, and having spent too much time
reading the mailing lists and newsgroups, I see some people in the Linux
world come, do LOTS of very important stuff and then disappear. One of
the people that really contributed to the linux movement is Stephen Tweedie

While I have nothing to say about the reasons why he doesn't seem to be
with us anymore (maybe a marriage???) there is one thing he promised to
work on that I really would like to see, that is support for a compressed
filesystem. (I know about DOUBLE).

What happened in this year??


(One other project I would like to know more about is the porting of
the Sprite/BSD4.4 log structured filesys "lfs"). Now that 4.4bsd is
available, is anybody working on it? I'm wondering how easy would be
to do some experience porting lfs under userfs to start playing with
it in userland.


        paolo zeppegno

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

From: lee@netspace.cis.brown.edu (Lee J. Silverman)
Subject: Smail mod/SO_LINGER time?
Date: 23 Jun 1994 00:24:40 GMT


        I'm running smail in daemon mode on my machine, and I noticed
that when an SMTP connection to my machine is *closed*, the smail
proccess that was dealing with that connection goes <zombie>, and has
to wait for an alarm signal before it dies.  This resulted in a large
number of zombie proccesses running at the same time.

        I fixed this by adding the following code to src/modes.c, in
the daemon mode() function:

line 795: added:
    struct linger lingerset;            /* Mod be Lee to fix zombies */

lines 863-878: added:
/* Mod by Lee Silverman that *maybe* will fix the Zombie problem */

    lingerset.l_onoff=0;
    lingerset.l_linger=0;

    write_log(LOG_SYS,"SO_LINGER set.\n");

    if (setsockopt(ls, SOL_SOCKET, SO_LINGER, &lingerset, 
                   sizeof(lingerset)) < 0) {
        write_log(LOG_SYS, "SO_LINGER on failed: %s\n", strerrno());
        exitvalue = EX_OSERR;
        return;
      }

/* End of Mod by Lee Silverman */

        To my reckoning, this essentially tells the socket to close
when fclose() is called, even when the socket has data to send.  In
this case, the data would be the line: 
221: Closing Connection 
which doesn't strike me as being terribly important.

        However, it does strike me that I should probably try to leave
the socket open for a few seconds so that that line at least has a
chance to get out onto the net before the socket is closed.  Stevens'
book, "Unix Network Programming" says that linger times are not really
implemented; if the time is nonzero then the socket will linger until
all the data is sent.

        I'm wondering if this is true of Linux.  Are linger times
implemented in Linux?  If so, in what versions of the Kernel?  I'm
running 1.1.19.  If not, how hard would it be to implement them?

        Sorry it took me so long to get to such a straightforward
question!



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

From: kapis-p@cs.Buffalo.EDU (Piotr Kapiszewski)
Subject: Re: Has anyone gotten the wretched All-in-one Ethernet adapter to work?
Date: Wed, 22 Jun 1994 14:36:07 GMT

Ludwig Van. (lruppert@iguana.syr.EDU) wrote:

: I bought an All-in-one ethernet adapter (NE2000 compatable, 10BaseT
: and BNC ports).  The model number was the one ending in AC, 16 bit.
: No matter what the setting is, the autodetect fails to find it, even
: when I hardcode the IRQ and memory address.  I have another card I was
: using, made by the same company, with the model number ending in UC,
: and it worked fantastic.  My question is, does anyone else have this
: model card working in their machine?  If so, how did you trick the
: poor thing into working?  Are there any tips on coercing the stupid
: thing into letting Linux 1.1.15 find it? (I tried earlier Linuxes too,
: but to no avail.)

Perhaps you can use different IRQ/Base configurations.  I dont exactly
recall who made it but I had a board installed which would fall under
the All-in-one description.  I had it set to IRQ 15 and Base 330.  It 
worked for me but then again I cant recall what the weather and atmospheric
conditions were at the time ;-)

-Kapi

-- 
Kapi, State University of New York at Buffalo, Department of Computer Science
INTERNET: kapis-p@cs.buffalo.edu  |  BITNET: kapis-p%cs.buffalo.edu@ubvm.bitnet
http://www.cedar.buffalo.edu/~kapis-p/Home.html  |   Key available via finger.

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

Crossposted-To: comp.os.linux.misc,comp.os.linux.admin,de.comp.os.linux
From: HIGGINS@DELBOX.ZER.DE
Subject: BUG: ReRead Partition Table
Date: Tue, 21 Jun 1994 10:18:00 +0200

Frank Westheider         Linux Support Group Paderborn
higgins@uni-paderborn.de     higgins@delbox.zer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi Folks !

I just found a bug in the BLKRRPART function.
This function is called from fdisk to reread the partition-table
of the modified device. But creating a extended-partition (not ext2-fs !)
is not recognized from the apropriate function, only the primary- 
partitions are updated. I recognized this with SCSI-Disk, don't know
about IDE-disks, there exist different reread-functions for the various  
disk-types.
So i call the kernel-hackers. Is this known, should it be so or what ?


Ciao
  Higgins

--
You can escape the gates of hell, say DOG and WINDOG,

         USE LINUX   :-)     !
## CrossPoint v3.0 ##

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

From: Andrew.Grillet@purplet.demon.co.uk (Andrew Grillet)
Subject: Re: ntfs filesystem on di
Date: Tue, 21 Jun 1994 07:42:00 +0000

 -=> On 06-08-94  23:19, Bryan Ford posted to All <=-

 BF> From: baford@cs.utah.edu (Bryan Ford)
 BF> Date: 8 Jun 1994 01:17:36 GMT
 BF> Organization: University of Utah Computer Science Department
 BF> Message-ID: <2t367g$9ct@magus.cs.utah.edu>
 BF> Newsgroups: comp.os.linux.development

 >>in order to do this, i will need some informations how NTFS files are stored
 >>on a disk.
 >
 >Because of the B2 (or was it C2 ?...) security, I dont think MS will release
 >any 'internal' info about NTFS... If they did, you could make a boot-disk
 >that could access the NTFS-partions and the security are lost..

 BF> Yikes, if this is true then Microsoft is even dumber than I thought.
 BF> :-) Security based on secret algorithms is not really security at all -
 BF> good security is always based on widely known and easily testable
 BF> algorithms. The only thing that needs to be kept secret is the
 BF> passwords, keys, etc. 
 BF> However, all the same I wouldn't be surprised if Microsoft hasn't (and
 BF> won't) release the disk format for NTFS.
 BF> Maybe it's time out to pull out the disk editor...

        ... All is revealed - MS won't relese the format cos it would
        adversley impact sales of Norton Utilities, which might lead
        to a lawsuit ...


.. Engage brain before operating mouth


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

From: daveg@locus.com (Dave Goldblatt)
Subject: Re: Novell NCP Documentation Available! (was Re: IPX Netware Protocol)
Date: 22 Jun 1994 14:51:59 GMT
Reply-To: daveg@locus.com

On Mon, 20 Jun 1994 23:48:35 GMT, bsa@kf8nh.wariat.org (Brandon S. Allbery) said:

BSA> In article <2u4tr4$3bq@magus.cs.utah.edu>, kruckenb@sal.cs.utah.edu (Pete Kruckenberg) says:

BSA> +---------------
BSA> | By any chance, has anyone tried to implement NCP using the information
BSA> | in Pawel Szczerbina's article in Dr. Dobbs on Novell's NCP
BSA> | ("Undocumented Corner: Novell's Netware Core Protocol", Dr. Dobbs,
BSA> +------------->8

BSA> Yes.  The information is reportedly buggy and incomplete, but I think it's
BSA> being used as a starting point to "black-box" a working NCP layer.

A better bet would be to wait for the book, _Undocumented Netware_, by
Tim Farley (if I recall correctly) which will have everything you need
to know, and more.

And it'll be pretty accurate.  Was scheduled for this summer; I haven't
pestered the author or Andrew Schulman to see if it has changed.

One of the rumors going around was that Novell was _very_ unhappy about
this book.  Kinda like Microsoft and _Undocumented [DOS|Windows]_.

-dg-
--
"And so it went.  Tens of thousands of   |  Dave Goldblatt (daveg@locus.com)
 messages, hundreds of points of view.   |  Locus Computing Corporation
 It was not called the Net of a Million  |  Burlington, MA
 Lies for nothing." - Vernor Vinge       |  (617) 229-4980

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

From: haynes@cats.ucsc.edu (James H. Haynes)
Subject: Pathological program
Date: 23 Jun 1994 06:19:15 GMT


I've got a C program which one of the profs wrote with some intentional
mistakes in it - I guess as a test of the student's knowledge of C.
When I fix enough of the mistakes to get it to compile with warnings only,
and then run it,
    If I run it under gdb I get a segment violation right away
    If I run it "barefoot" (just run it, no gdb) it runs and runs and the
machine (apparently) runs out of swap space and hangs up.
There are no malloc()-s in the program, but it does have a mistake
that lets it run forever.

This is under Slackware 1.2 (Linux 1.0.8, libc.so.4.5.24) and also under
Slackware 1.1.

The nature of the mistake in the program is
     scanf(%f %f v1, v2);
where v1 and v2 are the variables themselves rather than the addresses
of the variables as they should be for scanf.

Seems to me the behavior of running out of swap space and hanging the
system is wrong; is this a bug in the system? the C library?

-- 
haynes@cats.ucsc.edu

"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"


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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Runtime compilation and execution
Date: 22 Jun 1994 19:34:36 +0200

In comp.os.linux.development, article <2u7ruj$ia4@mailer.fsu.edu>,
  hugg@xi.cs.fsu.edu (Steven Hugg) writes:
> 
> Under DPMI I did this with a few selector aliases and by changing the
> rights of the selectors. How is this normally done in Linux?

Open /dev/zero and mmap it someplace with PROT_READ+WRITE+EXEC.

-- 
Oh NO, not YOU again.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
Subject: Strange stty/logout problem in 1.1.20
Date: 22 Jun 1994 02:33:41 GMT

I started running 1.1.20 last night. I had been on 1.1.16 till then, only
using 1.1.19 occasionally while testing the scsi drivers I'm working on.
1.1.19 works fine (except for the scsi I'm fixing).

With 1.1.20 suddenly, when I log in and my .login does an stty (it does 2,
stty crt -ctlecho and stty erase ^?) the stty gets suspended (actually, I
believe it's the .login being suspended) and I get a shell. If I 'fg' the
suspended stty I get logged out.

Similar things happen if I start up 'vim' and pipes just hang dead. If I
kill any of the suspended processes I do not get logged out.

The processes are reporting as being suspended on tty output.

Any ideas?

-- 
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

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

From: piper@logrus.cl.msu.edu (Gary Schrock)
Subject: HD problems with 1.1.21
Date: 23 Jun 1994 07:07:30 GMT

Ok, I patched my kernel version 1.1.20 up to version 1.1.21 and all compiled
well with no problems there that I noted.  When I went to reboot I got a
message right after the partition check:

hd.c: ST-506 interface disk with more than 16 heads detected, probably due to
non-standard sector translation.  Giving up.
(disk 1: cyl=100, sect=32, head=64)

This message was repeated a second time, except the disk line was
(disk 0: cyl=520, sect=32, head=64)    (undoubtably for the other hd)

Linux continued to boot up fine, and seemed to work with no problems, although
I switched back to 1.1.20 which was the last version that worked for me.

System particulars:
486dx33 w/ 8 Megs Ram
Adaptec 1520 SCSI controller
545 Meg Seagate drive (don't remember model number)
105 Meg Quantam LPS-105 drive  (both are SCSI drives)

If more information is needed to help track down this problem, feel free to
drop me a note at schrock@student.msu.edu to let me know what you need.

Gary Schrock
schrock@student.msu.edu


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

From: tjc@beta.lanl.gov (Timothy J. Corcoran)
Subject: Re: linux-1.1.20 breaks dosemu0.52
Date: 21 Jun 1994 15:15:29 GMT

In article <81264.73.772178337@novell1.rz.fht-mannheim.de> 81264@novell1.rz.fht-mannheim.de (RAINER SCHIELE INFORMATIK) writes:
>Hello
>
>Yesterday i compiled dossemu0.52. When i start it, i can not enter more then
>one keystroke. My display locks then up. Using rawkey off, give me the 
>chance to switch to another vt and kill the process. The Problem is mentioned
>in the HOWTO(keybint on), but this must be another mistake. When using 
>linux-1.1.19 dosemu0.52 runs.
>
>Rainer

I also am seeing a strange 'feature' in dosemu0.52, though it is under 1.1.19.
After a clean compile, I try to run in a vt.  It goes as far as saying that no
errors were detected parsing the config file and then just hangs.  Is this 
possibly due to rawkey on?  The funny thing is when I am in X, I can run it in
a window with the vga font from xdos and it works!  The only bad thing is that
I lose my mouse from then on until I kill the windows manager.  Any suggestions?

===============================================================================
Tim Corcoran,
tjc@beta.lanl.gov
e41590@fep1.rl.gov



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

From: lellis@dmccorp.com (John Lellis)
Subject: Re: Strange stty/logout problem in 1.1.20
Date: 22 Jun 1994 15:09:54 GMT

Jonathan Magid (jem@bittyblue.oit.unc.edu) wrote:
: In article <2u87u6$6p5@harbinger.cc.monash.edu.au>,
: Kevin Lentin <kevinl@bruce.cs.monash.edu.au> wrote:
: >
: >With 1.1.20 suddenly, when I log in and my .login does an stty (it does 2,
: >stty crt -ctlecho and stty erase ^?) the stty gets suspended (actually, I
: >believe it's the .login being suspended) and I get a shell. If I 'fg' the
: >suspended stty I get logged out.

: Yeah- 1.1.20 changed some signal handling stuff- all the objects need to be
: recompiled.


:       make clean
:       make zlilo

: Should fix your problems. 

Well, not all.  After a make mrproper; config; dep; zImage, 1.1.20 was
reasonably well-behaved.  But uugetty would only answer the phone once before
it would "hang" in a state in which the phone would ring but not answer.  A
kill -9 brings it back to life again.

This has to be something new to the 1.1.x kernels.  My arrangement works
flawlessly when I boot 1.0.9, but I'd like to take advantage of the SCSI
throughput enhancements which appeared in 1.1.x (e.g., kernel rebuilds take
only 1/3 the time under 1.1.x vs. 1.0.9).  I assume the problem lies in the
serial drivers, since I note that the ID on the serial drivers has changed
to 4.0 from 3.99a.  Or do I have to rebuild getty_ps for the 1.1.x kernels?

--

John Lellis (lellis@dmccorp.com)

--
... Our continuing mission: To seek out knowledge of C, to explore
strange UNIX commands, and to boldly code where no one has man page 4.




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

From: pieterh@sci.kun.nl (Peter Herweijer)
Subject: Re: Disk-compression for Linux
Date: Tue, 21 Jun 1994 14:47:53 GMT

iiitac@uk.ac.swan.pyr (Alan Cox) writes:

 >This is partly true. However the bits of information lost per bit error for
 >a compressed file is much higher than for an uncompressed one.

Who cares?  In both cases you'll have to dig up your backups.
Anyway, modern drives do a good job at error recovery.

 - Peter Herweijer
   pieterh@sci.kun.nl

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

From: pieterh@sci.kun.nl (Peter Herweijer)
Subject: Re: Hard disks limited to 16 heads?
Date: Tue, 21 Jun 1994 14:58:26 GMT

onno@stack.urc.tue.nl (Onno Hovers) writes:

 >Oystein H. Olsen (Biology) (oystein@bimcore.emory.edu) wrote:
 >> I have a 540 Mb hard disk from Dell that is configured for 32 heads,
 >> 524 cylinders, and 63 sectors. The kernel complains about using more

This is not a valid configuration for an IDE drive.  No doubt your
BIOS is doing some translation magic here.

 >> than 16 heads and cannot use the drive. I then reduced the heads to 16
 >> and doubled the cylinders to 1028. [...]
 >> So, back to the initial problem, why does the kernel (hd.c) limit the number
 >> of heads to 16?
 >This is a limitaition of the BIOS.

No way.  _This_ babe is an IDE limitation.  The BIOS will happily
go all the way up to 255 (or was it 256?) heads, hence the 8GB BIOS
capacity limit.  The IDE capacity limit is significantly higher.
It's only when BIOS and IDE are combined that you get the famous
500-odd MB limit.

 >There is a standard called "enhanced IDE" that should solve those
 >problems.

Yes.  No bullshit, no physical and logical geometry hassles, just
Linear Block Addressing (LBA).

 >[...] Anyway, you should try to format your harddisk under the
 >following settings:
 >  cylinders: 1024 
 >  heads:     16
 >  sectors:   63
 >This should get you the maximum of space that's available. Only SCSI
 >harddisks can have more space. 

This is NOT true.  Linux suffers from the BIOS limits, more
specifically, the 1024 cylinder limit, only during booting.  So
as long as you make sure that LILO and the kernel image are on a
partition <1024 cylinders, you can happily use 1048 or even more
cylinders, ignoring all warnings to the contrary.

Having said that, I'm not sure what Linux' limits for IDE geometry
actually are---maybe a kernel wizard can enlighten us.  But I'm
positive that it can go beyond 1024 cylinders.

 - Peter Herweijer
   pieterh@sci.kun.nl

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


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