Subject: Linux-Development Digest #992
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:     Sat, 6 Aug 94 01:13:06 EDT

Linux-Development Digest #992, Volume #1          Sat, 6 Aug 94 01:13:06 EDT

Contents:
  Re: 1.1.38 fixes uart detection (David Flood)
  Re: Fatal Signal 11 - reproduceable ! (Filip M Gieszczykiewicz)
  Re: SLIP, CSLIP, PPP and modems (Sunny Yum)
  XFree86 and backing store? (Chris Shenefiel)
  Re: Voice Mail cards. (Hans E. Kristiansen)
  Re: Linux backup of MSDOS? (Vassili Leonov)
  Re: Help needed compiling SLIPLOGIN (John Lellis)
  Re: SLIP, CSLIP, PPP and modems (Adam Tilghman)
  Re: SLIP, CSLIP, PPP and modems (Jay Denebeim P025)
  Re: Few simple questions... (Bjorn Ekwall)
  Re: gcc 2.6.0 intern. comp. error (Beeblebrox)
  Re: Using rs232 control lines from program? (Lynx man)
  Trouble compiling kernel (Adam Meltzer)
  Re: File Locking (Mike Grupenhoff)
  g++ 2.6.0 kernel compiler problem (Marc Duponcheel)
  Weird new Emacs (Hannes Reinecke)
  Re: ioctl() and using I/O ports (Grant Edwards)

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

From: dcflood@u.washington.edu (David Flood)
Subject: Re: 1.1.38 fixes uart detection
Date: 5 Aug 1994 03:42:36 GMT

I yelled before looking.  My other sysadmin (younger brother) just told me 
that he changed rc.serial to do a manual config on cua3 with declaration 
that it is the correct type.  Just for that, I lowered his access to user 
for the next week.  I might even make it perm.  
-- 
=============================================================================
dcflood@u.washington.edu

The above opinions are mine alone and do not reflect anyone elses.
Besides, who wants my opinion anyway?
=============================================================================

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

From: filip@alpha.smi.med.pitt.edu (Filip M Gieszczykiewicz)
Subject: Re: Fatal Signal 11 - reproduceable !
Date: 5 Aug 1994 03:45:14 GMT


        Greetings. This is completely off topic... well, kinda. 
        Speaking of "Fatal Signal 11"... I built gcc258 for our
        Sparc10 and, well, I can pretty reliably crash the
        machine when I feel like it. A build of emacs or some
        other 10+MB source package usually does the deed. First
        I'll get a few sig 6'es, then 2-3 sig 11's and then
        WHAMO! So, don't feel bad folks :-)

        Take care.

        P.S. I asked about this and was told to sod off... I guess
        they think I'm making this up OR they know about it and
        are trying to feel like they're getting what they paid
        for ;-)
-- 
+-->Filip "I'll buy a vowel" Gieszczykiewicz | E-mail: filip@alpha.med.pitt.edu
| http://alpha.med.pitt.edu:9000 for new sci.electronics FAQ V2 & my home page
| Enjoy your job, work within the law, make lots of money : Choose any two...
| Making money with CS and spending it on EE, robotics, windsurfing, & dreams.

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

From: n5298@cray.com (Sunny Yum)
Subject: Re: SLIP, CSLIP, PPP and modems
Date: Fri, 5 Aug 1994 17:25:04 GMT

In article <31rvve$8hd@herald.indirect.com>,
Dan McGuirk <mcguirk@indirect.com> wrote:
>No, you don't seem to understand what he's talking about.  A 14.4k modem
>can transmit at 14.4k in both directions, at the same time.  Normally, you
>are only transmitting data in one direction at a time, and the receiving
>system just echoes the characters back.  So you get, maybe, 1.7k/second 
>max for a transfer of random data at 14.4k.  But there are some transfer 
>protocols for DOS that will let you transmit at full speed in both 
>directions at the same time--so you could do a 14.4k upload and a 14.4k 
>download at the same time.  The bandwidth in each direction is limited to 
>about 1.7k, but you can have a total bandwidth of 3.4k.
>
>My limited knowledge tells me that you could do this with SLIP/PPP, but 
>you'd have to modify the protocol, making it incompatible with existing 
>SLIP/PPP installations.  And it sounds like a lot of work.  Probably not 
>worth it...  wait for ISDN or something...


Hold on one sec... I always assumed that SLIP/PPP used both channels
at all times -- in fact, there is no special setting you need to do to
get this to work.  If you have a full duplex modem, and are receiving
data (assuming 14.4Kbps modem) at 1.7KBps, sending data simultaneously
at 1.7KBps will affect _minimally_ (maybe 10% max) the speed of your
receive.  SLIP/PPP, for sure, have the ability to send and receive
at the same time, so your effective throughput is ~3KBps minus SLIP/PPP
overhead.  Even "Term" has the ability to send and receive simultaneously
and I have sent and received files at the same time with xfer rates of
~1.5KBps in both directions.

-- 
Sunny D. Yum (n5298@marvin.cray.com) -- My Opinions Are MINE!
GCS d-- H-- s g+(-) p? au->+++ a- w+ v+(*) C++++(++)$ UL++++ P->++++ L++(+++)
3- E>++ N++ K- W(---) M-- V-- -po+ Y+ t(-) 5++ j- R- G? tv(+) b++ D++(+++)
B(-) e+>++ u h!>++ f+ r n-(----) y?

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

From: shenefil@slip-cas (Chris Shenefiel)
Subject: XFree86 and backing store?
Date: 5 Aug 1994 02:32:33 GMT

Can anyone tell me if the Linux Xfree86 X server supports backing store.

This would be a nice feature since I am using slip to dial up to work and
am trying to use some graphically intensive Xwindows apps over the SLIP
interface.  

Thanks,
Chris

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

From: hans@nuts.com (Hans E. Kristiansen)
Subject: Re: Voice Mail cards.
Date: Fri, 5 Aug 1994 12:58:56 UNDEFINED

In article <CtvyBo.4qw@oakhill.sps.mot.com> miker@diamante (Michael Reid H3-433) writes:
>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)      

I am working on this problem as well. But my work is based around the Zyxel 
driver from sunsite. It works. I have ported a program which will 
convert the special .zvd format to .voc.

I have also written a program which plays .zvd files directly to /dev/dsp.

I am working on a X-window interface for the above.

Hans


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

From: vassili@cs.sunysb.edu (Vassili Leonov)
Subject: Re: Linux backup of MSDOS?
Date: 5 Aug 1994 15:53:06 GMT

I don't quite get the point of the discussion. I normally use
tar cvf /dev/rmt0 /msdos
where msdos is my msdos partition mounted. And it does the job!

Even, if I need to make this sort of backup on a NON-LINUX machine on the
network - I just boot Linux from diskette and do the same thing -
even over the network:
tar cvf - /msdos | rsh hostwithtape dd of=/dev/rmt0

If you like to trouble trouble - say zcvf instead of cvf...

good luck,
Vassili.

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

From: lellis@dmccorp.com (John Lellis)
Crossposted-To: comp.os.linux.help
Subject: Re: Help needed compiling SLIPLOGIN
Date: 5 Aug 1994 15:01:51 GMT

Bart Kindt (bart@dunedin.es.co.nz) wrote:

: The program often (but not always) does not terminate after receiving a SIGHUP 
: when a dialer disconnect, with the result the dial-in line is hanging forever.

We've had a similar experience both using sliplogin and Karel Kubat's callback
server.  I believe that it isn't related to sliplogin, but rather to the new
serial drivers, since backing down from kernels 1.1.x to 1.0.9 alleviates the
problem.  All kernels after 1.1.12 exhibit the behaviour you describe, while
the 1.0.x kernels do not.  Try going back to the "trailing edge" series of
kernels and see if it makes a difference.  It did the trick for us.  Hopefully,
one of these days the serial drivers will be fixed and we can take advantage of
the "bleeding edge" features, but until our dial-ins recycle reliably, we are
stuck at kernel 1.0.9, I guess.  :-(

--

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: atilghma@sdcc10.ucsd.edu (Adam Tilghman)
Subject: Re: SLIP, CSLIP, PPP and modems
Date: 5 Aug 1994 22:09:46 GMT

In article <31rvve$8hd@herald.indirect.com> mcguirk@indirect.com (Dan McGuirk) writes:
>No, you don't seem to understand what he's talking about.  A 14.4k modem
>can transmit at 14.4k in both directions, at the same time.  Normally, you

>My limited knowledge tells me that you could do this with SLIP/PPP, but 
>you'd have to modify the protocol, making it incompatible with existing 
>SLIP/PPP installations.  And it sounds like a lot of work.  Probably not 
>worth it...  wait for ISDN or something...

        Just as a rough test I ftp'ed a 512Kb file (dd'ed from a
gzipped file) to and from my Linux box at home.  The
(home-to-school) transfer had an effective transfer rate of
1.2Kb/sec, while the reverse direction saw 1.4Kbps.  My 
normal transfer rate is 1620cps (using either FTP or Zmodem).

        From looking at the modem lights, my end was losing
the battle for bandwidth at first, but after 100K both directions
seemed to settle down to something fair.  FYI, the hardware on 
both sides is:  Linux 1.1.38+16550+ZyXEL U1496E, to a Sun4+Xylogics
Annex Terminal Server+USR Sportster 14.4K modem.  Low end Zyxel's
aren't known for their bidirectional transfer speed...

        Of course, YMMV.  

                -- adam

-- 
Adam G. Tilghman | email:              | voice:          | Rng FCNZ naq yvir.
                 | atilghma@mib.org    | +1 619 658 0743 | Cyhf PurrmJvm?

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

From: denebeim@bnr.ca (Jay Denebeim P025)
Subject: Re: SLIP, CSLIP, PPP and modems
Date: Fri, 5 Aug 1994 22:13:34 GMT

In article <31t2ai$a4g@rain.org> jayme@rain.org (Jayme Cox) writes:
>Someone known as Jay Denebeim P025 (denebeim@bnr.ca) spake thus:
>This is not true at all. While the slip connection is responsible for
>sending other information (rip, arp, etc) if you arn't doing anything
>else, ftp's should be with 1-2% of zmodem/xmodem/ymodem transfers. Period.

Actually, it is true.  Think about it, I don't know how much overhead
SLIP and FTP adds to a packet, but the TCP/IP header is around 20
bytes.  A ZMODEM packet is much less then this.  

There are only so many bytes per second that go over the link, heavier
protocols go slower then lighter ones.
-- 
Jay Denebeim     Address: UUCP:     duke!wolves!deepthot!jay
                          Internet: jay@deepthot.cary.nc.us
                 BBS:(919)-233-9937      VOICE:(919)-233-0776

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

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: Few simple questions...
Date: 5 Aug 94 22:39:49 GMT

Simo Varis (svaris@cs.joensuu.fi) wrote:
[...]
 > Well, it really doesn't matter what's in my
 > kernel, if it doesn't use memory, but this does,
 > I'm afraid. So how could I avoid this? I watched
 > what's going in, and for my surprise, also
 > 3c509, de600, de620, 3c501 and plip got compiled.
 > Why? Also at least bios32 was compiled, and it's
 > totally useless for me, VLB-user. Maybe it doesn't
 > take up any memory...

These drivers are mentioned in "linux/drivers/net/MODULES", which
means that they will be compiled as loadable modules unless you
enabled them in "make config".

This means that the drivers are _not_ linked into the kernel, so
they won't take up any memory, _unless_ you include them with the
"insmod" utility.  That's the whole point with loadable modules.

If you look at the output from "make", you will see that the drivers
had the compile flag "-DMODULE", and also that they were _not_
included in the kernel. They will just lay around (with symlinks
from "linux/modules") for you to "insmod" them at your convenience.

Anyway, since you didn't enable the networking package in your
"make config", you won't be able to "insmod" them in a running kernel,
even if you wanted to...

 > Next, is there any way how could I see what's in
 > my kernel, like those card-drivers?

If you don't trust <linux/autoconf.h>, you could look
in "linux/zSystem.map", where all global symbols in the
kernel is displayed...

 > Thanks.
 >
 > -- 
 > Simo Varis -- svaris@cs.joensuu.fi

Bjorn Ekwall == bj0rn@blox.se

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

From: M.S.Ashton@dcs.warwick.ac.uk (Beeblebrox)
Subject: Re: gcc 2.6.0 intern. comp. error
Date: Fri, 5 Aug 1994 15:18:10 GMT

zloebl@piis10.joanneum.ac.at (Klaus ZLOEBL) writes:

>So what is the IOT signal or instruction?

It's an (obsolete in some people's opinion) term for the signal which is
generated by abort();

Sounds like it gave up the ghost to me...
Reduce the problem to the smallest possible subset and post to gnu.gcc.bug
___
M.S.Ashton@dcs.warwick.ac.uk              M.S.Ashton@csv.warwick.ac.uk
C++ consultant and emacs support.         Mail me if you have any problems.

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

From: ez008579@dale.ucdavis.edu (Lynx man)
Subject: Re: Using rs232 control lines from program?
Date: Fri, 5 Aug 1994 22:54:07 GMT

In article <Cu05zu.1Cz@pe1chl.ampr.org> you wrote:

[...]

: Check the TIOCMBIC and TIOCMBIS ioctl's, e.g.:

:         int arg,fd;

:         arg = TIOCM_RTS;
:       ioctl(fd,TIOCMBIS,&arg);                /* RTS ON */

:         ...

:         arg = TIOCM_RTS;
:       ioctl(fd,TIOCMBIC,&arg);                /* RTS OFF */

Thanks.  Just after I posted I discovered /usr/include/linux/termios.h
and reread the ioctl man page for the fortieth time and did just that.
I actually did a TIOCMGET, masked out the TIOCM_RTS bit, then a
TIOCMSET, as in (abridged):

        int arg,fd;

        ioctl (fd, TIOCMSET, &arg);          /* get current state */
        arg &= ~TIOCM_RTS;                   /* clear RTS */
        ioctl (fd, TIOCMSET, &arg);          /* do it */
        arg |= TIOCM_RTS;                    /* set RTS */
        ioctl (fd, TIOCMSET, &arg);          /* do it */


--dduuddlleeyy                  <dudley@water.ca.gov>
California Cooperative Snow Surveys
Department of Water Resources           (916) 653-0881


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

Subject: Trouble compiling kernel
From: rampage@clubcal.uucp.netcom.com (Adam Meltzer)
Date: Fri, 5 Aug 94 16:23:12 PST

I have this problem.

I want to recompile the kernel so I can get SB suppourt and FPU emulation.
Whenever I try to compile the kernel though, I'll always get some sort of
signal 11 error with one of the header files.

Someone told me to change the wait states on my motherboard, which I did, it
didn't help much. I even went as far as to disable the external cache on my
computer. I still get the errors when making the "zImage" file.

I really don't have a clue as to why it isn't working right, I have a pretty
standard setup:
 i386/40DX
 5 Megs of RAM
 Trident 8900C SVGA card
 40 Meg hard drive for Linux (has about 10 megs free before doing the make)
 Slackware kernel 1.0.8
 The latest version of GCC and Libs ftp'ed from sunsite.unc.edu

I simply can't understand why I am having so much trouble doing a seemingly
simple thing. I go through the steps of:
 make mrproper
 make config
 make dep
 make clean
 make zImage

The only thing I change in the make config is the -m486 flag (since I have a
386), and enable SB suppourt, and disable SCSI suppourt.

If anyone can help, please E-Mail reply to this message. Thanks.
__
.  __________   _____      _____   _______  _____      ____     ____    __   .
|  \._____   \  \__  \    /     \  \____  \ \__  \    / ___\  _/ __ \  /  \  |
|   |       _/   / __ \_ |  . .  \ |  |_>  > / __ \_ / /_/  > \  ___/  \  /  |
|   |    |   \  (____  / |__|_|  / |   ___/ (____  / \___  /   \___  >  \/   |
:   |____|_  /       \/        \/  |__|          \/ |_____/  -RM-  \/  <__>  :
.          \/             -- << rampage@clubcal.com >> --                    .
.                                                                            .

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

From: kashmir@umiacs.umd.edu (Mike Grupenhoff)
Subject: Re: File Locking
Date: 5 Aug 1994 21:49:06 -0400

dillon@apollo.west.oic.com (Matthew Dillon) wrote:
>
>    Why not just use flock() ?
>
>    I dunno about it working over NFS tho, don't think it does.
>
>                                       -Matt

The point of using lockf/fcntl is that it does work over nfs, although 
it suffers from many race conditions.  I think the main reason linux lacks
lockf is because there is no port of statd/lockd which handle the lock 
requests.


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

From: marc@offline.be (Marc Duponcheel)
Subject: g++ 2.6.0 kernel compiler problem
Date: Sat, 6 Aug 1994 19:50:11 GMT

Hello linux developers,

With gcc 2.6.0 I get (builing kernel):

gcc -D__KERNEL__ -I/var/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486  -c -o init/main.o init/main.c
init/main.c: In function `checksetup':
init/main.c:233: fixed or forbidden register was spilled.
This may be due to a compiler bug or to impossible asm
statements or clauses.

Anyone has tried to use 2.6.0 for kernel builing ?

-- 

-- marc.

 email  marc@offline.be [= me@home]

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

From: hare@zarquon.mathi.uni-heidelberg.de (Hannes Reinecke)
Subject: Weird new Emacs
Date: 05 Aug 1994 15:26:21 GMT

Hi all,
is someone out there working with the most recent Emacs (19.25) ?
I compiled it lately, but playing with it gives me some weird
behavior:
In an ordinary buffer only the first character of the input will be
displayed and the point is blinking just right of it. After hitting
return all text is displayed correctly.
In the minibuffer only the last character of the input is displayed,
but the point doesn't move forward.

Did anyone have some hints about the reason being ?

Configuration:
i486, Linux 1.1.38, gcc 2.6.0, libc 4.5.26, Emacs 19.25 -with-x11
-with-x-toolkit 

Thanx

Hannes
=======
Hannes Reinecke                      |
<hare@vogon.mathi.uni-heidelberg.de> |  XVII.: WHAT ?
                                     |  
PGP fingerprint available            |          T.Pratchett: Small Gods
see  'finger' for details            |          

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

From: grante@reddwarf.rosemount.com (Grant Edwards)
Subject: Re: ioctl() and using I/O ports
Date: Fri, 5 Aug 1994 21:26:09 GMT

William Hoffman (wmhoffma@crab.rutgers.edu) wrote:

: I'm trying to write some code to use a joystick under Linux, but I'm
: running into a problem with the I/O port.  The gameport is at I/O port
: 0x201, but Linux does not want me to use that and gives me a
: segmentation fault when I try to read from it.  I tried doing an
: ioctl(tty_fd,KDADDIO,port_num), but while this works for some ports (I
: succeeded using it to gain access to the VGA registers), it does not want
: to work for 0x201.  I'm sure there is something very easy that I'm
: missing, but I'm no Linux guru, so if someone could point me in the
: right direction I'd be very grateful.  (I do have a game port; it is
: on my Sound Blaster Pro.)

There is a joystick device driver for Linux.  I hacked up cbzone to
let my drive my tank with the joystick.  I've also added an ioctl to
adjust the "speed" of the joystick, but I don't know how portable my
addition is (I traced the DOS speed-adjust program's I/O using DOSEMU
to figure out what was going on).

It's a loadable module, so you'll need that capability in your kernel.

--
Grant Edwards                                 |Yow!  Hmmm..  A hash-singer
Rosemount Inc.                                |and a cross-eyed guy were
                                              |SLEEPING on a deserted
grante@rosemount.com                          |island, when...

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


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