Subject: Linux-Development Digest #898
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:     Fri, 8 Jul 94 08:13:04 EDT

Linux-Development Digest #898, Volume #1          Fri, 8 Jul 94 08:13:04 EDT

Contents:
  Re: dosemu and lost selection (Dolf Smits)
  Re: 14'400 baud /dev/cua ?  (Juha Laiho)
  Re: Dedicated SCSI swap drive? (Tim Smith)
  Xconfig question. (Brett Carter)
  Re: Help: Modules in Linux kernel (Sam Oscar Lantinga)
  Re: Linux Performance Enhance ? (Matthias Urlichs)
  Re: VAX port, is there one? will there be one? (Wilhelm B. Kloke)
  Re: Linux seems to perform terribly for large directories (Tim Smith)
  Kernel Patches (Ernie Elu)
  RE: Amiga OFS/FFS support (Bernd Markiefka)
  Re: Drivers for Adaptec AIC-7770 SCSI? (Harald Milz)
  Re: Help rm !! (Tim Smith)
  Re: Dedicated SCSI swap drive? (Adrian Savage)
  Re: 14'400 baud /dev/cua ? (Bill C. Riemers)
  Re: 14'400 baud /dev/cua ? (Bill C. Riemers)

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

From: dolf@interduct.tudelft.nl (Dolf Smits)
Subject: Re: dosemu and lost selection
Date: Thu, 7 Jul 1994 07:38:31 GMT

Dennis Mahle (dmahle@falcon.depaul.edu) wrote:
: I have just upgraded to 1.1.13 kernel and dosemu-0.52.  This is my
: first attempt at dosemu, so I can't comment about earlier versions.
: My Problem: When I boot linux, selection (vt cut/paste) works fine 
: until I run dosemu.  After a normal dosemu exit, via emuexit, I get
: no response from the mouse on a vt.  (Mouse works fine in X, though).

: If anyone has a workaround please share... I love dosemu and have 
: spoiled myself w/ selection.  

: Thanks,
: Dennis  aka dmahle@falcon.depaul.edu

I had problems with the mouse as well.
I solved the problem by writing a C -program that kills selection just
before dosemu is started. After exiting dosemu selection is started again.

If you are interested I can send you the code

Greetings, Dolf

--
Smits@interduct.tudelft.nl            Dolf Smits

Interduct
Delft University Clean Technology Institute
Rotterdamseweg 145
2628 AL  DELFT                        tel. (+31) 15 78 72 39
The Netherlands                       fax. (+31) 15 78 72 39


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

From: jlaiho@ichaos.nullnet.fi (Juha Laiho)
Subject: Re: 14'400 baud /dev/cua ? 
Date: Thu, 7 Jul 1994 07:16:40 GMT

bcr@physics.purdue.edu said:
Earlier Bill C. Riemers (bcr@k9.via.term.none) wrote:
>   : Anyways, if I check my serial's settings I see:
>   : > setserial -a /dev/mode
>   : /dev/modem, Line 0, UART: 16450, Port: 0x03f8, IRQ: 4
>   :   Baud_base: 115200, close_delay: 50, divisor: 0
>   :   Flags: spd_hi skip_test

>I have no intention of replacing a $240 internal modem without a good
>hope of purformance increase.  One of the pecular things I noticed is
>that AT commands seem to be over-ridden by stty commands.  Forexample
>I used:
>
>at%m0%c0dt 494-....
   ^^^^^^modem/manufacturer-specific commands, could you explain them?
>at%m0dt 494-6459
>CARRIER 14400
         ^^^^^this is the modem-modem connections speed. Both ways.
>
>PROTOCOL: LAP-M
           ^^^^^you're using v.42 error-correction
>
>COMPRESSION: NONE
              ^^^^this says you are using no compression
>
>CONNECT 57600
         ^^^^^and the serial port speed of your modem is this, propably
              because the serial port speed of your terminal program was
              set to 38400 AND you are using speed_hi in your rc.serial

>So even though I've turned off all compression, it still connects at
>57600.  This is true irregardless of what serial program I use...

How about using lower speed at your terminal program? The modem senses
your terminal program speed, when it sees 'at', and will adapt to it
(as, I suppose, the modem manual will tell you?). If you don't want to
run at 57600, don't use the spd_hi in your rc.serial. Try setting your
terminal program speed to 19200, and things should work better. Then,
enable your modem compression.

>What I would really like to do is:
>
>at%m2 but likewise this doesn't work either...  It used to work with
 ^^^^^again, modem/manufacturer-specific command
>Linux 0.99pl11 but somewhere along pl13 or pl14 it broke.
:-) Modem command that ceases to work when your OS version changes? Now,
come on..
-- 
Wolf  a.k.a.  Juha Laiho     Helsinki, Finland
(Geek Code 1.0.1) GCS d? p c++ l++ u(-) e+ m+ s+/- n- h(*) f(?) !g w+ t- r y+
"...cancel my subscription to the resurrection!" (Jim Morrison)

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

From: tzs@u.washington.edu (Tim Smith)
Subject: Re: Dedicated SCSI swap drive?
Date: 8 Jul 1994 09:49:53 GMT

Scott A. Laird <lair@midway.uchicago.edu> wrote:
>and tmp space on a seperate, slower drive will help performance.  I
>doubt that any of the <100 Mb SCSI drives out there can top 1 Mb/sec,
>and I suspect that most of them (can you say ST-296N?) are more like
>200-300k/sec, tops.  With both tmp and swap space, I suspect that most

The old Quantum ProDrive 80 was speced at 2 megabytes/second asychronous
and 4.0 megabytes/second synchronous.  I've seen them go faster (I once
caught one doing 5 megabytes/second asynchronous).  I doubt that newer
drives are slower.

However, isn't it seek time that is more important here, rather than
data transfer rate?

--Tim Smith

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

From: carterb@topaz.cqu.edu.au (Brett Carter)
Subject: Xconfig question.
Date: 8 Jul 94 19:45:42 +1000

Hi. 

I'm looking for someone to help with a problem I have. I'm developing a
distribution (basically cut down slackware) for external students at 
our university, and am trying to save them as much trouble as possible.
As this is the case, I'm trying to set up an Xconfig file that will run
on basically any machine. We've decided that XF86_VGA16 will do for a 
driver, but as for the monitor settings, I'm not game try much for fear
of frying my monitor and would really hate to get calls from angry, 
monitorless students.:)

Can anyone tell me if there are settings that are safe and workable for
most monitors?? Just 640x480.

Also, if you could mail replys back to
carterb@jasper.cqu.edu.au
Would be much obliged.

Thanks in advance.... 

-- 
**************************************************************************
  Brett Carter                          | carterb@topaz.cqu.edu.au
(* White Wolf *)                        | "I've decided to leave my body 
Bachelor of Computing (Honours)         |  to science.... Fiction."
Central Queensland University           |
**************************************************************************

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

From: slouken@cs.ucdavis.edu (Sam Oscar Lantinga)
Subject: Re: Help: Modules in Linux kernel
Date: Thu, 7 Jul 1994 18:36:00 GMT

: Fixed major numbers aren't necessary any more anyway, except for the
: disk you're booting from, and the console.


        What about device files?  Don't you need fixed major numbers
so that the device files correspond to the devices you expect them to?

-Sam


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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Linux Performance Enhance ?
Date: 8 Jul 1994 11:03:43 +0200

In comp.os.linux.development, article <CsK7s3.7Ky@pe1chl.ampr.org>,
  pe1chl@rabo.nl writes:
> 
> Also, it seems like the balance between program pages resident in memory
> and pages used for disk buffers is not always optimal: when the memory
> is tight it will not swapout infrequently used pages to make room for more
> disk buffers.
> 
Just look at the code in mm/swap.c:

static int try_to_free_page(int priority)
{
        int i=6;

        while (i--) {
                if (priority != GFP_NOBUFFER && shrink_buffers(i))
                        return 1;
                if (shm_swap(i))
                        return 1;
                if (swap_out(i))
                        return 1;
        }
        return 0;
}

This means, essentially, that the system will always try to shrink the
buffer space before attempting to grab a page from a program. Grr.

Try this replacement instead:

static int try_to_free_page(int priority)
{
    int i=5;
    static int what = 0;
                 
    switch(what) {
      case 0:
        goto what_0;
      case 1:
        goto what_1;
      case 2:
        goto what_2;
    }                                                         

  what_0:                                               
    if (priority != GFP_NOBUFFER && shrink_buffers(i)) {                        
        what = 1;
        return 1;
    }                                                         
  what_1:             
    if (shm_swap(i)) {   
        what = 2;
        return 1;
    }                     
  what_2:             
    if (swap_out(i)) {  
        what = 0;
        return 1;
    }               
    if(i-- > 0)       
        goto what_0;    

    return 0;                                                               
}                                                                               

The goto-ish code may be ugly, but jumping into a loop, or duplicating
code, is even uglier.
In my experience, this change is a noticeable improvement in memory usage.

-- 
Imports are ports very far inland.
-- 
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: wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke)
Subject: Re: VAX port, is there one? will there be one?
Date: 7 Jul 1994 11:05:06 +0200

In article <2vg9p1INNcdk@fstgds15.tu-graz.ac.at>,
Klaus ZLOEBL <zloebl@piis10.joanneum.ac.at> wrote:
>Well having some VAXstations 3100, i am interested in an operatingsystem
>for them (not VMS or ULTRIX)
Look into Netbsd development. I heard that there some Swedish people
are working on that. If you want to wait, just look into the arch directory
of netbsd distribution.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

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

From: tzs@u.washington.edu (Tim Smith)
Subject: Re: Linux seems to perform terribly for large directories
Date: 8 Jul 1994 10:23:21 GMT

David Kastrup <dak@rama.informatik.rwth-aachen.de> wrote:
>>Try it on a DOS system for a change :-)
>
>Try it on a MacIntosh. Why try to imitate worst case behaviour? Mac
>file system speed is really impressive.

Figuring out where to place all those icons is slow, however.  I'm running
A/UX on my Mac.  Doing "ls > /dev/null" in my /spool/news/alt/fan/rush-limbaugh
directory, which has about 4000 files, takes about 4 seconds, and doing
"ls -lu > /dev/null" takes about 13 (these would be about 30% faster if
I stopped a background program I'm always running that is equivalent
to "while(1);" as far as system load is concerned).

Opening that same directory from the Mac OS on top of A/UX takes about
five and a half minutes the first time, and about two minutes on
subsequent attempts.  It would probably be a little faster if I was
not going through A/UX, since the Mac OS file system calls are all
being translated to Unix calls, but still, it's clear that there
is a lot of overhead on the Mac OS side of things.

My Unix file systems are all Berkeley file systems, rather than
System V file systems.

I've also got a directory with 1903 items that I've got copies of on
both one of my Unix filesystems, and on a Mac filesystem.  Opening
that from the Mac OS under A/UX takes 130 seconds off the Unix filesystem,
and 50 seconds off the Mac filesystem.

It thus seems that the Mac filesystem is indeed faster than the Unix
filesystem, like you suggest, but the overhead of the GUI makes it
slower for actually getting the information to the user.

--Tim Smith

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

From: ernie@tinny.apana.org.au (Ernie Elu)
Subject: Kernel Patches
Date: 8 Jul 1994 20:19:20 +1000

Once upon a time there used to be regular posts about what the latest kernel
patches actually fixed/did. I am a regular kernel "punter" so grabbing the
latest patch is fun. Is there a mail list or something I can find out what
has been changed ?


- Ernie.

-- 
_______________________________________________________________________________

    Australian Public Access Network Association  - ernie@tinny.apana.org.au
_______________________________________________________________________________

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

From: mark@oink.rhein.de (Bernd Markiefka)
Subject: RE: Amiga OFS/FFS support
Date: Fri, 8 Jul 1994 12:09:09 UNDEFINED

Well, Im almost 100% sure that there is support for the Amiga FFS. I've found a
package nearly a year ago or so at fgb1.fgb.mw.tu-muenchen.de (129.187.200.1)
somewhere in the alpha or beta subdirectories. Sorry, I don't remember exactly
where it was and I've not the time to look it up, but there should be other 
servers where it exists.

Bernd Markiefka
mark@oink.rhein.de

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

From: hm@seneca.ix.de (Harald Milz)
Subject: Re: Drivers for Adaptec AIC-7770 SCSI?
Date: Fri, 8 Jul 1994 06:20:45 GMT
Reply-To: hm@seneca.ix.de

Chaisiri Wongkham (chaisiri@kku1) wrote:
: > Can anyone tell me that the development of drivers for Adaptec

: > AIC-7770 family is finish or not? Thanks

-> SCSI-HOWTO
-> Projects-FAQ

-- 
Harald Milz                             office: hm@ix.de
iX Multiuser Multitasking Magazine      home:   hm@seneca.ix.de
Opinions are mine, not my employer's -- the answer is Forty-two


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

From: tzs@u.washington.edu (Tim Smith)
Subject: Re: Help rm !!
Date: 8 Jul 1994 10:58:09 GMT

Vincent Dogterom <vd@nieuwle.knoware.nl> wrote:
>A fellow student of mine, wants to write a undelete for his 
>graduation-project, does anyone of you'all out there have any information 
>about this (how's it's done, is there already a undelete for linux etc.)
>i spoke to a few unix-spec. but they all say is quite impossible.

I managed an undelete on a VAX 11/780 once by killing power before the
system had flushed the buffer cache, but I don't recommend this
method!  (It was the third time in about a week that I had accidently
deleted /etc/passwd, and people were getting really annoyed with me,
so it seemed time for desparate measures...).

Anyway, a key question here is what exactly do you mean by undelete?
For example, if you merely want something so that if someone accidently
does

        $ rm really_important_file

they can then do

        $ undelete really_important_file

and get it back.  Many people have done this.  A typical way is to
make an alias or shell function or shell script or whatever is best
for your shell that replaces rm.  Off the top of my head, here's a
very simple example.  Put this in your bin as rm, and make sure
your bin is ahead of /bin (or wherever you keep rm) in your path:

        HERE=`pwd`
        for i
        do
                echo $HERE/$i | cpio -pdmul $HOME/.deleted > /dev/null 2>&1
                /bin/rm $i
        done

Undelete would be something like this:

        HERE=`pwd`
        for i
        do
                mv $HOME/.deleted/$HERE/$i $i
        done

Periodically go through your .deleted directory and clean out things
you really do want to delete.

If you want an undelete that is handled by the system, it's not too
hard on most Unix-like systems.  There are plenty of approaches you
can take (e.g., change unlink to rename files to a magic location,
add some sort of support for a "hidden" file and have unlink simply
hide the file, and many others).  Most poeple don't find these worth
the trouble--a simple shell script like I gave above is enough for
most people.  Generally, most Unix programs don't delete files, so
almost all accidental deletions take place via a user initiated rm
command.

Another variation is to delete the file, but keep some information
around for free i-nodes and free blocks (or whatever your filesystem
uses if it's not based on inodes) that tells where they came from,
so a special program can poke around in the free i-node and block
lists and reconstruct a deleted file, as long as the blocks or
i-node have not been reused.  With this sort of approach, hacking
the filesystem to delay reusing blocks and i-nodes for as long as
possible might be a good idea--you'll have to balance performance
against saving data for as long as possible.

--Tim Smith

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

From: Adrian_Savage.sbd-e@rx.xerox.com (Adrian Savage)
Subject: Re: Dedicated SCSI swap drive?
Date: Fri, 8 Jul 1994 09:18:50 GMT

Naresh Sharma (nash@dutllu4.gmd.de) wrote:
>> Hans-Christoph Rohland (hrohlan@gwdg.de) wrote:

>> : I am using a 16MB swap on a Quantum 240 connected via Adaptec 1542 since
>> : January and never had any problems with Kernels 0.99.15, 1.0.0 and 1.1.3...
>> : Actually I never heard about such probs before. I would like to know if
>> : there are more people experiencing failures of swap with scsi.

>> The bug is not seen in the 1542 code, and 1542 does not exercise it.
>> Adapter cards of other makes e.g. future domain (used to ?) exercise this
>> bug.

I'm using a fdomain 1680 and am unable to use a SCSI partition as
swap - as soon as swapping starts, the system locks up within about
2 minutes.  This is with kernel versions 1.0.6, 1.1.13 and 1.1.24.

My solution was to get a cheap IDE drive and use that as a swap
device, which is a shame as my SCSI drive is 4 times faster both for
access time and data transfer :-(

Ade
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Adrian Savage                  |      Rank Xerox Ltd,
                               |      Document Solutions Group,
asavage.sbd-e@rx.xerox.com     |      Rank Xerox Systems Operations,
a.f.savage@bradford.ac.uk      |      Welwyn Hall, Bessemer Road,
                               |      Welwyn Garden City, Herts,
Telephone +44 707 382250       |      AL7 1BL, England
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

From: bcr@k9.via.term.none (Bill C. Riemers)
Subject: Re: 14'400 baud /dev/cua ?
Date: 8 Jul 94 07:10:09 GMT
Reply-To: bcr@physics.purdue.edu

In article <1994Jul7.050920.12734@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:

   In article <2vfm13$337@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
   >14400 non compressed link. The PC won't talk to the modem at 14400 so you
   >either have to turn line buffering on or drop to 9600.

   Actually this is not true, the PC can be made to talk to the modem at 14400 
   on Linux. You can set a custom divisor.

I think you are jumping in alittle late and missed one of the key
points is I receive at 38400.  Unfortunately the custom-divisor
works both ways.  So if I set to send at 14400, I also will be
receiving at the same speed.  :(  I commented on this in my post.

Anyways, it seems the real problem is both seyon and fet are not
setting the the flow controle correctly.  I just got a program
that I can run to solve this problem.  If it works I'll be happy
to pass it on.


   You are much better off turning on buffering and using a higher DTE rate in 
   any event.

It seems at connect time, seyon is changing the key modem settings
back from what I manually set????  I'm not sure if seyon is to
blaim but I know something is.  Anyways, if the above program
that uses standard libc functions works, then I'll be happy.
Then maybe I can try to figure out why I get corrupted data whenever
I try to use compression sending to my universities modems...

                             Bill

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

From: bcr@k9.via.term.none (Bill C. Riemers)
Subject: Re: 14'400 baud /dev/cua ?
Date: 8 Jul 94 07:13:25 GMT
Reply-To: bcr@physics.purdue.edu


Well it wouldn't be worth $240 today...  But it is still good
hardware, with 16C450 and all.  It used to work fine under Linux.
I already commented about the software problems I learned about in
the previous post, so I'll leave this at that.

                      Bill



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


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