Subject: Linux-Development Digest #989
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, 5 Aug 94 12:13:09 EDT

Linux-Development Digest #989, Volume #1          Fri, 5 Aug 94 12:13:09 EDT

Contents:
  Transferring control to BIOS ("Alexander During")
  For Linux 1.1.3x users: DOSEMU 0.53pl6+ development releases (Mark Rejhon)
  Re: No Free Inode on 1GB harddisk!!  (Juha Laiho)
  Re: Voice Mail cards. (Michael Reid H3-433)
  Re: Fatal Signal 11  - reproduceable ! (Charles E Meier)
  Re: SLIP hangs in newer kernels (Mr AJ Bradley)
  Re: PLIP problems solved! (mostly...) (Reinhard Schiedermeier)
  Re: Linux backup of MSDOS? (Salvador Pinto Abreu)
  Kernel change summary 1.1.37 -> 1.1.38 (Russell Nelson)
  multi-threaded linux-kernel (Bouwmeester L.)
  Re: Need Restricted Shell for Linux: Where? (laboratorium dydaktyczne)

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

From: 63912i@cfi.waseda.ac.jp ("Alexander During")
Subject: Transferring control to BIOS
Date: 2 Aug 1994 01:54:46 GMT


Hello out there. I am sporadically working on a driver to switch
some things on my laptop (backlight, external screen and such) and
I am beginning to get rather unwilling to dig further into the
VGA BIOS. The thing is this: Cirrus Locig has a call interface
to their (proprietary) hardware via the normal VGA interrupt. I
could analyse mine and hope this works on anybody else's machine.
The other way would be to activate the VGA-BIOS and do the things
there, as all of the calls would be done from the keyboard driver
(there are special keymappings for use by DOS drivers). 

I once heard that some people were trying to use such a thing to
implement something or other, but it was long ago and I don't know
what it was.

Any hints would be appreciated, as I don't know how this can be done.
I do have a 486 manual and I am somewhat able to read it (it's 
Japanese), but I really would like some hints.

Thanks

Alex

--
As MS-DOS is very abstruse, \\it's also quite tricky to use. \\So many give in
and try typing 'win'. \\But that means completely to lose.
Alexander D\"uring, Physics Department, Waseda University, Tokyo, Japan.
Statistical Physics, Linux, Shakespeare. --- This space for rent ---

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

From: mdrejhon@calum.csclub.uwaterloo.ca (Mark Rejhon)
Subject: For Linux 1.1.3x users: DOSEMU 0.53pl6+ development releases
Date: Wed, 3 Aug 1994 17:55:39 GMT

This is a hello from just one member of the DOSEMU development team...
DOSEMU 0.53pl8 is available to all who are on the bleeding edge..

DOSEMU 0.53 was supposed to have been released two weeks ago.  The
main reason we are delaying DOSEMU 0.53 is that it stopped
working with recent Linux kernels in the 1.1.30+ series (this mainly
happens when it was run at the Linux console or when EMS was enabled.)

Why did it stop working?   That is because of recent changes in the 
kernel that was incompatible with DOSEMU.

DOSEMU 0.53 is not quite ready yet, but if you are such on a bleeding
edge that you are running Linux 1.1.30+ kernel, then you certainly can
compile development DOSEMU releases.

Once a week (sometimes 3 times a week!) a development DOSEMU
package is put up for other DOSEMU developers and people who are on
the bleeding edge (namely you! :)

Current public release: 0.52 works with 1.1.12 up to 1.1.30
Current development version: 0.53pl8 works with all kernels above 1.1.12
Next public release: 0.53 or 0.54 within 2 weeks hopefully.

What is new in development releases?  Plenty.  They include:
  - Improved EMS support.
  - ANSI COLOR and IBM characters over a remote link! (NEW)
  - Xwindows support (just like xdos).  Works with text only. (NEW)
  - Works with latest 1.1.3X series kernels.
  - Many bugfixes.

Here's the location:

tsx-11.mit.edu:/pub/linux/ALPHA/dosemu/private/devel

Yes, the directory is hidden, and yes, your FTP program can get confused by
this.  Just blindly cd all the way into the "devel" dir (even if it cant
be viewed from below it).   In there you will be able to view the directory.
You will see a lot of pre53_*.tgz packages.

Just get the latest numbered version, and carefully read its "ChangeLog" 
file for a summary of changes.  At time of this writing, it is pre53_8.tgz

If you want color X windows support too, please also get
ansi_xterm_pre2.0.tgz too, in conjunction with the pre53_*.tgz package
that you got.   This is a specially programmed Xterm that is compatible with 
DOSEMU to display all 16 colors.

Enjoy.  But please do so at your own risk.
I welcome feedback directly to this message or via Email of this message,
or at:

ag115@freenet.carleton.ca

The main DOSEMU co-ordinator is at jmaclean@fox.nstn.ns.ca

Blast me away with bug reports, but please be detailed, including
your /etc/dosemu.conf file if possibl.  State your DOSEMU version
and kernel version as well.


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

From: jlaiho@ichaos.nullnet.fi (Juha Laiho)
Subject: Re: No Free Inode on 1GB harddisk!! 
Date: Mon, 1 Aug 1994 17:56:25 GMT

g609296@win.or.jp (Barry Yip kam-wa) said:
>We have a 1GB scsi harddisk used for storing a full newsfeed. After
>getting about one week of news, there is no more free inode space left
>and I think the only solution is to get another bigger one harddisk
>even we still have enough harddisk space.

I've seen this too, and found the solution.

>Is there any way to increase the available inodes in this situation.
>Also, will it be better if the ext2 filesystem can have a bigger limit
>on the max. no. of inodes allocated.

I suppose you should find the optimal amount of inodes for every
filesystem so that inodes and disk space are used roughly at the same
rate. That is, for news spool you need a lot more inodes than for
file archive. With my news spool I've calculated that approximately
1 inode for 3kbytes of data space seems to be good. Your measure may
vary. Don't reserve too much inodes, as they unnecessarily eat up
diak space.

To increase the amount of inodes on a filesystem you need to create the
filesystem from scratch again. It will destroy all the files on the
filesystem, so if you'd like to save the old news articles, be sure to
make a backup.

And, below is the relevant part from mke2fs manual page:
:MKE2FS(8)                                               MKE2FS(8)
:
:NAME
:       mke2fs - create a Linux second extended file system
:
:SYNOPSIS
:       mke2fs  [  -c | -l filename ] [ -b block-size ] [ -f frag
:       ment-size ] [ -i bytes-per-inode ] [  -m reserved-blocks-
:       percentage ] [ -v ] device [ blocks-count ]
...
:       -i bytes-per-inode
:              Specify the bytes/inode ratio.  mke2fs  creates  an
:              inode  for  every bytes-per-inode bytes of space on
:              the disk. This    value  defaults to  4096  bytes.
:              bytes-per-inode must be at least 1024.
-- 
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: miker@diamante (Michael Reid H3-433)
Subject: Re: Voice Mail cards.
Date: Tue, 2 Aug 1994 02:16:35 GMT

I recently purchased the ZyXEL 1496 to do voicemail.  I found that the
vgetty info was somewhat scant.  Does anyone have pointer to any documentation
that might get me up to speed on this stuff.  I have vgetty running but I'm
trying to play back messages on my Soundblaster and I'm having a dickens
of a time with the pvf utilities.  There must be other people doing this?

Thanks,
--
Mike Reid (miker@oakhill.sps.mot.com)      

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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: Fatal Signal 11  - reproduceable !
Date: 2 Aug 1994 04:18:58 GMT

In article <1994Jul31.113753.30256.chiark.ijackson@nyx.cs.du.edu>,
Ian Jackson <iwj10@cus.cam.ac.uk> wrote:
>In article <31e3t7$gp9@rs18.hrz.th-darmstadt.de>,
>olav woelfelschneider <wosch@rbg.informatik.th-darmstadt.de> wrote:
>[quoting normalised, lines reformatted to <75 characters - iwj]
>>Ian Jackson (iwj10@cus.cam.ac.uk) wrote:
>>>In article <1994Jul7.193105.20509@kbbs.kiel.sub.org>,
>>>Holger Petersen <hp@kbbs.kiel.sub.org> wrote:
>>>> The following small C-program gives the Message "Fatal signal 11"
>>>> [ further description and listing deleted ]
>>>> cc: Internal compiler error: program cc1 got fatal signal 11
>>>
>>> 1. This is answered in the FAQ.
>>> 2. You're posting to completely the wrong group.
>>
>>[stuff deleted]
>>
>>This is not neccessarily the wrong group, since I have lots of cases
>>when I got this signal 11 (SIGSEGV, btw.) under kernel 1.1.37 (my
>>hackers paradise), while everything runs fine with 1.1.9(which I
>>think is very stable).
>
>You've had *repeatable* fatal signals (ie, ones that always happen at
>the same point) appear just by changing kernel version ?  That sounds
>unlikely to me.  Perhaps you should have read what you deleted.
>
>>So you can not be absolutely sure wether this is a compiler bug or a
>>linux bug.
>
>You can't be absolutely sure of anything.  However, the entry in the
>FAQ, which you deleted, is correct.  It says:
> If the fault is repeatable (ie, it always happens at the same place in the
> same file) you have discovered a bug in GCC.

>This is almost certainly true.  Furthermore, it also says what to do
>if the problem isn't repeatable:
> If the problem is not repeatable you are very probably experiencing memory
> corruption --- see Q7.7 `make says Error 139'.
>
>Anybody using a kernel that's so unstable that it repeatably causes
>GCC to fall over should know what they're doing, and in particular
>make sure that the problem occurs with a known good kernel.
>

Careful here, Ian.  I've had fatal sig 11es when compiling big programs.
Restarting the compile would always result in a sig 11 at the same spot 
as before - unless I did a reboot, and then I could pick up again from 
the spot where it had died earlier.  I suspect flaky hardware, although
the first derivative of the number of sig 11s is negative wrt the gnu c
version number and the kernel version number and so it could still be
a problem that can be reduced by kernel and/or gnu c changes.

With three variables to play with, one needs to track down the 
cause by varying one while holding the other two constant.  Any good
scientist will tell you that that "repeatable" often requires many,
many time consuming trials.

As far as I am concerned, the jury is still out on this one.

>The point of the FAQ is precisely to tell people like Holger Petersen
>where to get assistance for their problem.  This is of course defeated
>if they don't bother to read it.
>
>It's also defeated if people post misinformation.
>

I thought that this was an appropriate place for this question.  
IMHO, this newsgroup has a much higher than average s/n.  The 
netcop attitude drives this down far faster than most any of the
inappropriate postings that I've seen.

cem



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

From: ajbra2@mdw059.cc.monash.edu.au (Mr AJ Bradley)
Subject: Re: SLIP hangs in newer kernels
Date: 4 Aug 1994 04:41:26 GMT

David A. Ranch (dranch@ecst.csuchico.edu) wrote:
>In article <311gh4$879@nz12.rz.uni-karlsruhe.de>,
>Klaus Schneider <uk0q@rzstud1.rz.uni-karlsruhe.de> wrote:

>>Since about kernel 1.1.25 my SLIP connections hangs for a few seconds
>>or even minutes before resuming its work.  This still happens in
>>v1.1.35.  Has anybody else experienced a similar problem?
>Klaus,

>Have you tried to re-compile DIP recently?  I had a similar problem
>but a re-compile helped LOTS!  You also might want to check out
>DIP 3.3.7-uri.  It has more features and seems more stable on my
>Linux box.


Thank god, I was beginning to think I was the only one with this problem! 
I had 1.0.9 and even _then_ the SLIP connection would hang for some time.
I'm now running 1.1.33 (but not for long, just got the 38 patches) and Ill pick
up the new version (and recompile it) of DIP and fingers crossed.. :)

Ill post my observations and the results of the procedure in due course... but
then again, maybe I wont need to post them, because you'll all hear me yelling
for joy from where you are !


Regards,

Adam Bradley- 3nd Year Comp Sci       |"Everything you do bears a will,
 Monash University- Clayton Campus    | And a why and a wherefore - 
  Melbourne Victoria, 3162.           | Each little bit of love and joy"
   email- ajbra2@ccds.cc.monash.edu.au|
    Linux - XFree86 - Term            |"March Of The Black Queen" (Mercury) 


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

From: Reinhard.Schiedermeier@deejai.mch.sni.de (Reinhard Schiedermeier)
Crossposted-To: comp.os.linux.help
Subject: Re: PLIP problems solved! (mostly...)
Date: 3 Aug 1994 15:01:21 GMT

ddelsig@uoft02.utoledo.edu wrote:
: Hi all,

:      Good news!  I finally got PLIP working on my machine.  I'm posting this
: mostly for the sake of the few other guys who futilely posted for help with
: me on this subject.  Here are my experiences:

: First of all, the only kernel I've gotten things to go on successfully is
: 1.0.9.  I got connections under 1.1.3x, but they were extremely slow and
: subject to timeouts.  For example, under 1.0.9 ping returns a consistent
: time of 3-4 ms with no packets lost.  Under 1.1.36 ping returns times in the 
: 70-80 ms range, with a scattering of others down to around 45 ms, and a
: packet loss of around 50%.  I'm not sure why this is, perhaps the cable
: design has changed for the newer kernels?  Read on...

You are right, ping gives me ~40 ms from my 486dx33 to a 386sx16
notebook, both running a 1.1.30 kernel.
With a 1.1.0 kernel, I had about 10ms.
However, have you tried transmitting files by ftp?
The transmission rates are about the same as with an old 1.1.0
kernel, about 20-30 kb/sek.
I have no idea why this is so.

--Schiedi

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

From: spa@fct.unl.pt (Salvador Pinto Abreu)
Subject: Re: Linux backup of MSDOS?
Date: Wed, 3 Aug 1994 23:12:47 GMT

In article <Cty94D.12A@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:

> >     for FS in $FILESYSTEMS; do
> >       cp /dev/zero $FS/.zero.
> >       rm $FS/.zero.
> >     done

> >the idea is to fill the unused space with zeros so that gzip will do a
> >better job.

> Sorry but that won't work...  cp is clever enough not to store blocks
> of zeroes on your disk!

right!

> You can try a similar construct with "dd" instead.

Nevertheless, `cp' is ok when dealing with DOS filesystems (the
original problem, if I remember well), which don't implement holes in
files. (in that case you'd have to change ".zero."  to some valid DOS
filename, anyway.)

> Rob

../salvador
--

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

From: nelson@crynwr.crynwr.com (Russell Nelson)
Subject: Kernel change summary 1.1.37 -> 1.1.38
Date: 05 Aug 1994 05:23:57 GMT

Include the compiler version number in the version banner.
Add NCR53c[78].. SCSI support to config.in
Add some ...Xsig modules to FPU-emu.
Switch from version 1.12 of wm-FPU-emu to version 1.20.  The accuracy
        of the emulator is in almost all cases equal to or better than
        that of an Intel 80486 FPU.  Prior to version 1.20 of the
        emulator, the accuracy of the results for the transcendental
        functions (in their principal range) was not as good as the
        results from an 80486 FPU. From version 1.20, the accuracy has
        been considerably improved and these functions now give
        measured worst-case results which are better than the
        worst-case results given by an 80486 FPU.
Updated to release 2.5 of the SoundBlaster Pro CD-ROM driver for Linux.
 *      Added "#ifdef EJECT" code (default: enabled) to automatically eject
        the tray during last call to "sbpcd_release".
 *      Added "#ifdef JUKEBOX" code (default: disabled) to automatically
        eject the tray during call to "sbpcd_open" if no disk is in.
 *      Turn on the CD volume of "compatible" sound cards, too; just define
        SOUND_BASE (in sbpcd.h) accordingly (default: disabled).
PCMCIA Ethernet adapters are not probed for.
DEPCA driver is now a loadable module.
Future Domain SCSI driver now supports TMC-3260 PCI SCSI host adapter.
Switched to NCR 5380 SCSI driver release 6.
PAS can't share SCSI and sounds irq's.
Support added for SCSI Common Access Method.
Seagate SCSI timeout changed to wait for IO or busy.
dcache_lookup now returns error code (and ino via a pointer).
Directory entries were being added to the cache incorrectly.
If we're running a memory-mapped file, remember that it's an executable.
Under iBCS-2, attempting to unlock a not-locked region is not
        considered an error condition.
Links under /proc weren't returning right inode for executables.
Oops, gotta gram(sic) the floppy irq and dma when switching to root floppy.
Kernel now has an splx() syscall for SYSV-compatible ipl manipulcation.
hlt'ing causes problems on some 486DX4's and old 386's.  Make a
        command line parameter "no-hlt" that stops hlt from being
        used.  If hlt'ing causes a problem, you'll know it real quick,
        because the kernel prints a message while starting up.
Define register_serial and unregister_serial for module creation of
        serial units.
Optimize the gid testing in doing system calls.
Missed a test for allowing sgid execution to make a syscall.
Time single shot adjustment wasn't working quite right.
tcp.c and arp.c now use init_timer().
Only run something through NIT if it's going back on the head of the queue.
Fix mtu/length error in ip_forward (in ip.c) and packet.c so that we
        don't excessively fragment.
IPX fix for multiple local networks (IPX 0.28 BETA).
--
-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

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

From: leonb@tyr.research.ptt.nl (Bouwmeester L.)
Subject: multi-threaded linux-kernel
Date: Fri, 5 Aug 1994 13:18:30 GMT


Hi linuxers,

A couple of times of times I have seen requests about whether Linux
was supporting threads on kernel level. Well, I can safely announce that
work is going on in that area for quite some time now. 

To avoid any confusion: code is NOT available yet, I repeat, code is NOT
available yet, so please don't ask where you can ftp it from, how to get info
etc.

The new kernel (called Linux Viper, linux 2.0) is still in design phase, which
is near completion. Coding will start very soon. When the first code is
actually running, we'll make a new announce because then we can estimate
when the first releases shall be available for non-commercial use.

However, we need an *experienced* person who knows about debuggers and
profilers (that kind of stuff) to design and develop a debugger/profiler
for the multi-threaded applications.

Regards,
        Leon Bouwmeester

PS. The guy that posted last week something about a multi-threaded kernel
    is in this project.

PS2. My news servers screwed up. Apologies if this message is posted twice.


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

From: stud37@sun1000.ci.pwr.wroc.pl (laboratorium dydaktyczne)
Crossposted-To: comp.os.linux.help
Subject: Re: Need Restricted Shell for Linux: Where?
Date: 5 Aug 1994 14:02:05 GMT

Andreas Joppich (aj@z2-db11.ms.DeTeMobil.de) wrote:
: In article <bart.65.00087E9A@dunedin.es.co.nz>, bart@dunedin.es.co.nz (Bart Kindt) writes:
: |> Hello out there,
: |> 
: |> I need a "restricted shell" for my dial-in users, to prevent them to roam all 
: |> about the system.  The RSH in Linux is actually the *remote* shell. And the 
: |> KSH as ported for Linux, has the 'restricted' options not included!
: |> 
: |> Can anybody tell me where to get one?  Or, if there is none at this time, 
: |> could somebody out there maybe Port / Compile one?  I would have no idea where 
: |> to begin...
: |> 


: On my box there is a guest account with a restricted shell. To set up
: an account to restricted shell, do : 

: z2-db11:~$ chsh guest
: Changing the login shell for guest
: Enter the new value, or press return for the default

:         Login Shell [/bin/bash]: /bin/rbash 

But one can break out of rbash using "exec /bin/sh"... Don't forget
to disable the builtin "exec" command in .profile (maybe there are
some other builtins which create such security hole)! I think that
chroot() (like in anonymous ftp) would be more secure. It should
not be very hard to write a C program which does chroot, then runs
the shell. Then use this program as a shell for this account.
This program should be setuid root and change to a normal user
after doing chroot (only root can do that).
This is not my own idea - I have read about it here few weeks ago.

: -- 
: _______________________________________________________________
: Andreas Joppich                              aj@ms.DeTeMobil.de
: DeTeMobil GmbH                        
: D-48153 Muenster                         Phone +49-251-977-2943              
: Germany                                  Fax   +49-251-977-2949
: ---------------------------------------------------------------
:    The above statements are my privat and personal opinions 
:        and not represantive for the DeTeMobil company !  

--
Marek Michalkiewicz
stud37@ci3ux.ci.pwr.wroc.pl

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


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