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, 28 Apr 94 16:13:17 EDT
Subject:  Linux-Development Digest #674

Linux-Development Digest #674, Volume #1         Thu, 28 Apr 94 16:13:17 EDT

Contents:
  KDDISPTYPE (bjdouma)
  Re: Looking for ports to do (David Sibley)
  SUMMARY: good programmer's editor for X? (Kris Nybakken)
  Re: Linux v1.1.8 seriously broken ("large" file copy)  (Juha Laiho)
  Re: WARNING -- swap files can cause a crash (&fix) (Matthias Urlichs)
  Re: WARNING -- swap files can cause a crash (&fix) (Matthias Urlichs)
  Re: WARNING -- swap files can cause a crash (&fix) (Matthias Urlichs)
  Dynamic Linking during program Runtime in Linux? (Peter Sommerlad)
  Re: X GUI Builder (Nigel Head)
  Re: Where is those new kernels ? (GLAUDE DAVID)
  Re: how do I get x-vga modes on cirrus controller? (Me Myself and I)
  Re: Why not a linux subsystem for NT? (Patrick Schaaf)
  Re: bdflush not running (Kent A Vander Velden)

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

From: bjdouma@xs4all.hacktic.nl (bjdouma)
Subject: KDDISPTYPE
Date: 28 Apr 1994 15:43:45 +0200


Hello,

Following question was posted before (though not that elaborate), but I
never saw a reply or may have missed same.

Is there any rationale behind not implementing KDDISPTYPE in vt_ioctl (it
_is_ after all #defined in kd.h)?  Svgalib could use it, for one thing, it
has this piece of code in its vga initialization routine:

#if 0     
    /* Check for EGA/VGA display */
/*   linux/kd.h defines this function but doesn't work (or am I wrong) ? */
    if (ioctl(tty0_fd, KDDISPTYPE, &display_type)){
        printf("VGAlib: can't get display type\n");
        exit (-1);
    }
    if (display_type != KD_EGA) {
        printf("VGAlib: EGA/VGA display required\n");
        exit(-1);
    }
#endif

In taking a shot at implementing this, I added the following piece of code
to /usr/src/linux/drivers/char/vt.c:

    case KDDISPTYPE:
        i = verify_area(VERIFY_WRITE, (void *) arg, sizeof(unsigned char));
        if (i)
                return i;
        put_fs_byte((unsigned char)screen_info.orig_video_mode,(char *)arg);
        return 0;

An appropriate ioctl now returns 7 (mono-whatever), which apparently is OK,
since I'm using a Mono Hercules, but I believe it should return a more
complete value according to #defines in either kd.h or tty.h; however, they
#define things their own way, there's the problem:

tty.h:
#define VIDEO_TYPE_MDA          0x10    /* Monochrome Text Display      */
#define VIDEO_TYPE_CGA          0x11    /* CGA Display                  */
#define VIDEO_TYPE_EGAM         0x20    /* EGA/VGA in Monochrome Mode   */
#define VIDEO_TYPE_EGAC         0x21    /* EGA/VGA in Color Mode        */

kd.h:
#define KDDISPTYPE      0x4B2E  /* gets display info */
#define         KD_MONO         0x01
#define         KD_HERCULES     0x02
#define         KD_CGA          0x03
#define         KD_EGA          0x04

You could do it like con_init does it in console.c, using the #defines in
tty.h, sorta like this:

        if (screen_info.orig_video_mode == 7)   /* monochrome display? */
        {
                if ((screen_info.orig_video_aga_bx & 0xff) != 0x10)
                        video_type = VIDEO_TYPE_EGAM;
                else
                        video_type = VIDEO_TYPE_MDA;
        }
        else                            /* If not, it is color. */
        {
                if ((screen_info.orig_video_ega_bx & 0xff) != 0x10)
                        video_type = VIDEO_TYPE_EGAC;
                else
                        video_type = VIDEO_TYPE_CGA;
        }

but I think the KD_ #defines from kd.h should be used.  Problem is, what for
example should be returned for EGA color or EGA mono then, or, for that
matter, my Hercules (mda), which is MONO, but also HERCULES; you can't OR
those KD_ values as they are #defined now. 
Any insights appreciated.


Wonderingly yours,

BJD

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                        bjdouma@xs4all.hacktic.nl

        * none of you really exist, my sysadmin types all this in *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

From: sibley@math.psu.edu (David Sibley)
Subject: Re: Looking for ports to do
Date: 26 Apr 1994 20:49:14 GMT

In article <2pjd5h$lo2@pretzel.cs.huji.ac.il> ury@humus.cs.huji.ac.il (Ury Segal) writes:
>
>Well, I have time to help writing this Linux thing, someone have recommendation
>of what should I do? SOme group need one more person? Anything?

The other day I was looking for 'skill'.  As far as I can tell it
hasn't been ported yet.  It's a program that kills other programs based
on name or other information (tty, etc) rather than just pid which kill
uses.

It needs to gather information about processes, in the Linux case from
the /proc directory, quite different from other UNIX systems, so the
port is non-trivial.  I don't know enough about this to do it myself,
but it's certainly something there to be done by some ambitious
person.  Possibly a lot of what one needs to know is already in the
source code for ps.  There's general information about /proc in the
kernel hacker's guide, of course.

I don't know whether someone else is already working on this.


David Sibley        | "Accurate reckoning.  The entrance into knowledge
Amateur radio NT3O  |  of all existing things and all obscure secrets."
sibley@math.psu.edu |      -- The Rhind Papyrus
http://www.math.psu.edu/sibley/


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

From: nybakken@world.std.com (Kris Nybakken)
Subject: SUMMARY: good programmer's editor for X?
Date: Thu, 28 Apr 1994 05:15:28 GMT

Hi!

This is a summary of a request I made a few weeks ago for a good 
X-Windows based programmer's editor.  In my request, there were a few 
things that I mentioned:

I wasn't too turned on by emacs for lots of reasons involving learning 
curves and UI.  People gave me some good tips for configuring emacs 
(thanks!) that I haven't included here.  I also got several flames about 
being a heathen for not liking emacs - I promptly dumped those.

I was looking for an editor to use in programming my Linux box.

I also was looking for font-size adjustability, and syntax highlighting 
for C and C++.

I'd like to thank everyone who replied - I would have never gotten this 
far in such a short amount of time without your help.

SUMMARY
-= good programmer's editor for X?
(28 Apr 94)

== xcoral ==
The latest seems to be 2.1.  Function and class browsers are provided for 
C and C++.
Can be found on sunsite

== Nedit ==
Is staticly linked with Motif.
Can be found on sunsite.

== Andrew Toolkit ==
will soon have (from 16 Apr 94) the EZ editor configured 
for source code.  Terry Gliedt said he would be uploading it soon to 
sunsite with a name like 'auis62L0-src'.

== aXe ==
Can be found at ftp.x.org

== Jed ==
can be found at sunsite.unc.edu in /pub/Linux/apps/editors

== xwpe ==
an project to make an environment based on Borland's IDE.  quick mention, 
with no other real description

END SUMMARY



Once again - thanks to everyone who responded!


kristof-
nybakken@world.std.com


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

From: jlaiho@ichaos.nullnet.fi (Juha Laiho)
Subject: Re: Linux v1.1.8 seriously broken ("large" file copy) 
Date: Wed, 27 Apr 1994 04:21:36 GMT

cougnenc@hsc.fr.net (Rene COUGNENC) said:
>I tried to reproduce that but it works for me... Linux 1.1.8, on a 386
>whith xiafs  and a 486 whith ext2fs: No problem. Both machines have
>4 days uptime, and I have absolutely no problem whith theses systems.

Well, I didn't have the file copy problem either, but the following appeared
when the machine was unpaking incoming news articles:

EXT2-fs error (device 3/65): ext2_readdir:
        bad directory entry: rec_len % 4 != 0
offset=184, inode=24932, rec_len=9854, name_len=0
EXT2-fs error (device 3/65): ext2_readdir:
        bad directory entry: rec_len is smaller than minimal
offset=256, inode=25190, rec_len=0, name_len=0
EXT2-fs error (device 3/65): ext2_readdir:
        bad directory entry: directory entry
across blocks
offset=140, inode=851996, rec_len=19796, name_len=12368
EXT2-fs error (device 3/65): ext2_readdir:
        bad directory entry: rec_len is too small for name_len
offset=164, inode=810569044, rec_len=12336, name_len=12336

Kernel configuration:
1.1.8, IDE performance patches with interrupt unmasking and multiple mode
enabled.

Machine configuration:
386dx33 (&387), IDE disks, SCSI disks. The disk on which the error was is
Quantum PD120A, ~120MB slowish IDE, configured as slave, not able to do
multiple-sector transfers.

So far, I have had no problems with the configuration. Previous kernels
include f.ex. something on which I patched both cluster and IDE perf.
patches, so I suppose it's not the interaction btw the two, but some
small error in the ext2 code. (Ok, it may be that it's just the old
Quantum finally giving out the smoke..)
-- 
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: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: WARNING -- swap files can cause a crash (&fix)
Date: 27 Apr 1994 15:50:43 +0200

In comp.os.linux.development, article <2plh6t$1kc@smurf.noris.de>,
  I wrote:
> 
> A quick fix is appended. (The patch is relative to 1.1.8.)
> 
Too quick -- one line was missing (the first "+").
Apply this patch instead.

--- mm/swap.c.orig      Wed Apr 27 12:59:00 1994
+++ mm/swap.c   Wed Apr 27 15:48:51 1994
@@ -579,6 +579,7 @@
                        nr_free_pages -= 1 << order; \
                        restore_flags(flags); \
                        EXPAND(next, order, new_order); \
+                       recurse--; \
                        return (unsigned long) next; \
                } new_order++; queue++; \
        } while (new_order < NR_MEM_LISTS); \
@@ -603,6 +604,7 @@
 unsigned long __get_free_pages(int priority, unsigned long order)
 {
        unsigned long flags;
+       static int recurse = 0;
 
        if (intr_count && priority != GFP_ATOMIC) {
                static int count = 0;
@@ -613,16 +615,20 @@
                }
        }
        save_flags(flags);
+       if(recurse++)
+               priority = GFP_ATOMIC;
 repeat:
        cli();
        if ((priority==GFP_ATOMIC) || nr_free_pages > MAX_SECONDARY_PAGES) {
                RMQUEUE(order);
                restore_flags(flags);
+               recurse--;
                return 0;
        }
        restore_flags(flags);
         if (priority != GFP_BUFFER && try_to_free_page(priority))
                goto repeat;
+       recurse--;
        return 0;
 }
 
-- 
Treffen sich zwei Kurven. Sagt die eine zur anderen: "Hau ab hier, du stehst
in meinem Definitionsbereich." Worauf die andere antwortet: "Hau doch selber
ab, sonst differenziere ich dich." Sagt die andere: "Aetsch! e-Funtion."
-- 
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: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: WARNING -- swap files can cause a crash (&fix)
Date: 28 Apr 1994 10:04:01 +0200

In comp.os.linux.development, article <2pm33g$d13@apollo.west.oic.com>,
  dillon@apollo.west.oic.com (Matthew Dillon) writes:
> In article <2plh6t$1kc@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
> :I just had a rather ugly crash:
> :
> :getblk() -> get_free() -> swap_out() -> rw_swap_page() -> bmap() ->
> :inode_getblk() (the indirect page was deallocated) -> getblk() ...
> :--> kernel stack overflow.
> :
> :Oops. Definitely in the "not so good" category.
> 
>     This sounds nasty!  It also sounds like it might be related to all
>     of the 'machine crashes during heavy swapping' bug reports that have
>     been posted off and on over the last two dozen kernel releases.
> 
Actually, I have to correct myself somewhat -- the main cause for the
problem was a local kernel modification, and the patch, even in its new
form, doesn't work due to out-of-memory conditions.

The underlying problem, which is that swapping to a file may cause a
crash or deadlock, _does_ exist, unfortunately. (I really would like to
be wrong about this.)

The reason is that a file access may cause more than one page to be
referenced -- most file systems needs meta-data (ext2: indirect blocks)
to access a file, and these are referenced from disk. In a low-memory
condition, therefore, the system needs more free memory for page-out. Brrr.

-- 
It is surely a great calamity for a human being to have no obsessions.
                -- Robert Bly
-- 
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: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: WARNING -- swap files can cause a crash (&fix)
Date: 28 Apr 1994 10:12:49 +0200

In comp.os.linux.development, article <2plqjj$if@smurf.noris.de>,
  urlichs@smurf.noris.de (Matthias Urlichs) writes:
> In comp.os.linux.development, article <2plh6t$1kc@smurf.noris.de>,
>   I wrote:
> > 
> > A quick fix is appended. (The patch is relative to 1.1.8.)
> > 
> Too quick -- one line was missing (the first "+").
> Apply this patch instead.

Back to the drawing board -- that patch caused out-of-memory errors when
memory was getting tight (the recursion flag should be per-process, not
global). That should teach me that kernel programming is _not_ easy.
(As if I didn't know already. ;-)

Anyway, the problem with recursion was apparently triggered by a local kernel
mod. The underlying cause, which is that swap files don't work well in
low-memory conditions because the file system needs to read their meta-data
(indirect pages) before it can swap anything _out_, is still there, and I
still do urge people to use swap partitions and not swap files.

-- 
The pedestrian works where I work. She is a standards coordinator. Funny
she should be the one I hit.
-- 
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: peter@merlion.zfe.siemens.de (Peter Sommerlad)
Subject: Dynamic Linking during program Runtime in Linux?
Date: Thu, 28 Apr 1994 11:56:30 GMT


Hello everybody,

is it possible to load .o modules during program runtime in Linux.

I've seen this using a function dld_load_more with gnu CC on
a Sun. Since Linux uses DLLs it might be possible.

Anyone any help?

Thanks
Peter.

--
===============================================================================
+ Peter Sommerlad                       email: Peter.Sommerlad@zfe.siemens.de +
+ ZFE BT SE 43                          phone:               +49-89-636-48148 +
+ Siemens AG                            fax:                 +49-89-636-45111 +
+ Otto-Hahn-Ring 6                                                            +
+ D-81739 Munich                                                              +
===============================================================================


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

Date: Wed, 27 Apr 1994 09:36:34 EST
From: Nigel Head <NHEAD@ESOC.BITNET>
Subject: Re: X GUI Builder

There are patches for OI on tsx-11 which make it work again ... try it and see!


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

From: dglaude@vub.ac.be (GLAUDE DAVID)
Subject: Re: Where is those new kernels ?
Date: 28 Apr 1994 11:34:49 GMT

Robert G. Smith (rob@bip.anatomy.upenn.edu) wrote:
: Ury Segal (ury@humus.cs.huji.ac.il) wrote:
: : Where are the sources for newer kernels ( 1.1.8 ?)  I searched at sunsite
: : and tsx and ftp.uni-paderborn.de !!

: You can get the original patches to make the newer 
: kernels from "ftp.funet.fi:pub/OS/Linux/PEOPLE/Linus/v1.1"

: Rob Smith

I have a small proposition about thoses patch in .../Linux/v1.1 and .../v1.0
 why do theses patches have the same name in each directory.
I am sure that a lot of peaple made some mistake in using patch for the
 v1.0 on the v1.1 or the inverse.
For exemple, when I update my linux-box... I ftp everything in the same
 directory... guess what append ?


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

From: akw@ukc.ac.uk (Me Myself and I)
Subject: Re: how do I get x-vga modes on cirrus controller?
Date: Wed, 27 Apr 94 16:07:11 GMT
Reply-To: akw@ukc.ac.uk (Me Myself and I)

In article <1994Apr26.204435.1604@physc1.byu.edu>,
 <nelsonm@physc1.byu.edu> wrote:
><<apologies if you got my last post where I referred to setup.S as boot.S
>  It should be cancelled.>>
>
>       I am trying to use the extended vga modes on my cirrus controller.

You have a 54xx series card right? The controller refered to as cirrus
in setup.S is the older 62xx series I believe.

>       What makes me wonder even more if there is a problem, is the fact that
>there is a descrepancy between cirrus mode numbers and the mode descriptors.
>mocirrus lists five mode numbers: 0x06, 0x1f, 0x20, 0x22, 0x31;

This lists only the modes specific to the chipset,

> while
>dsccirrus lists _six_ mode descriptors: 80x50, 80x28, 132x25, 132x44, 132x30,
>100x37.  This seems very odd to me.

whereas this lists the 80x50 and 80x28 modes available on any SVGA, followed
by the ones in the 'mo' line.

>       I tried to bypass the auto-detect code by lea'ing specifically
>the cirrus modes, i.e.
>       lea si,mocirrus
>       lea di,dsccirrus

The easiest way to sort things out, is to make that :-

        lea si,dsc9GXE
        lea di,mo9GXE

as the modes seem to be the same as those for the #9GXE and Orchid.
That is a bit of a hack though, the better way is to add entries for
the 54xx series cards and detect them properly by copying the detection
code for the #9GXE e.g :-

        .               .               .
        .               .               .
svga:   cld
        lea     si,id9GXE               ! #9GXE test
        mov     di,#0x49                ! id string at c000:049
        mov     cx,#0x<<somenumber>>    ! length of id string
        repe
        cmpsb
        jne     CLGD
is9GXE: lea     si,dsc9GXE              ! BIOS video mode numbers
        lea     di,mo9GXE               ! table of sizes
        br      selmod  

CLGD:   cld
        lea     si,idCLGD               ! Cirrus CL-GD54xx test
        mov     di,#0x39                ! id string at c000:039
        mov     cx,#0x07                ! Length of "CL-GD54"
        repe
        cmpsb
        jne     of1280
isCLGD: lea     si,dscCLGD              ! As above
        lea     di,moCLGD
        br      selmod

of1280: cld
        lea     si,idf1280      ! Orchid test
        .               .               .
        .               .               .
        .               .               .
idf1280:        .ascii  "Some id string"
id9GXE:         .ascii  "Some other id string"
idCLGD:         .ascii  "CL-GD54"
        .               .               .
        .               .               .
        .               .               .

!       Mode size :-    80x50   80x28   132x43  132x25

dsc9GXE:        .word   0x5032, 0x501c, 0x842b, 0x8419
dscf1280:       .word   0x5032, 0x501c, 0x842b, 0x8419
dscCLGD:        .word   0x5032, 0x501c, 0x842b, 0x8419
        .               .               .
        .               .               .
        .               .               .
mo9GXE:         .byte   0x04,   0x54, 0x55
mof1280:        .byte   0x04,   0x54, 0x55
moCLGD:         .byte   0x04,   0x54, 0x55
        .               .               .
        .               .               .

I found the start address of the id string with MSD in MSDOG (yuck!).
This works for my BIOS but the id string may be different for cards other
vendors using the Cirrus chipset. There is probably a more reliable and
universal way of detecting the 54xx series, but this works, you may just
need to change the address and id string. (Please note this was typed
from memory, so there may be some errors in the above code :)

Will post a patch when I can get the files from home.

I also "fix132x43 -vf" in my rc.local to give me a 400 line mode
instead of the 350 one, when using the 132x43 mode.

>This gave me all five options at boot-up, but only the first two worked--that
>is, the two that were already working anyway.

That's because the other modes were for the wrong chipset :)

>       I can't find any documentation on Cirrus controllers to help me sort
>through this and figure out the modes.  If anyone knows what to do about this,
>please let me know.

Hope this works for you,

Anna.

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

From: bof@wg.saar.de (Patrick Schaaf)
Subject: Re: Why not a linux subsystem for NT?
Date: Thu, 28 Apr 1994 15:44:50 GMT

michael@ecel.uwa.edu.au (Michael Simmons  - division) writes:

>Just a thought

Hmm. Has MS released detailed docs on their kernel and subsystem interface?
I was under the impression that we are not supposed to know that. I would
love to get a good book on the NT Executive.

Also, what would be the point of running Linux under NT? What would you
use it for?

Patrick


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

From: graphix@iastate.edu (Kent A Vander Velden)
Subject: Re: bdflush not running
Date: 27 Apr 94 16:15:35 GMT

In <1994Apr21.175719.19311@iglou.com> wakep@iglou.iglou.com (J. Wakeley Purple) writes:

>In 1.1.4:

>  I get the 'bdflush not running' message because it never gets
>started.  Looks like nice code, too bad 8).

>  Looking at fs/buffer.c I can see that somewhere during kernel
>initialization sys_bdflush(0,0) should be fork()ed to start
>it as a daemon (it goes into a while(1==1) loop).

>  However, the comments in init/main.c about fork()ing from
>kernel space (before there *are* any processes?) keep me from
>trying to do is myself.  Besides, I've never fork()ed anything
>and don't really know how it works (does that make me a virgin?).

>  Is there a patch to get it running?  Also where are these
>'bleeding edge' patches?  I can't find them at sunsite or tsx-11.

No patch, just the program itself. 
ftp.funet.fi:/pub/OS/Linux/PEOPLE/Linus/v1.1

-- 
Kent Vander Velden                          Project Vincent
graphix@iastate.edu                         System Operations
                                            Student Development Group
                                            Engineering Animation, Inc.

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


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