Subject: Linux-Development Digest #988
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 08:13:04 EDT

Linux-Development Digest #988, Volume #1          Fri, 5 Aug 94 08:13:04 EDT

Contents:
  ioctl() and using I/O ports (William Hoffman)
  expect (Frank Flannery)
  Adaptec controller fails with kernels 1.1.37 - 1.1.39 (Loong Yeu)
  Re: A/D drivers for Linux (Glenn Moloney)
  Re: lint for linux (Tor Arntsen)
  Linux 1.1.37 sys V/Coherent fs glitch (Jose Cordones)
  Re: Fatal Signal 11 - reproduceable ! (Janne Sinkkonen)
  Re: lint for Linux (Derek Jones)
  Re: -= good programmer's editor for X? (Andreas Nolte - Universitaet Bremen)
  Re: Interesting idea for lilo developers (Tim Smith)
  Re: Interesting idea for lilo developers (Tim Smith)
  Re: SLIP, CSLIP, PPP and modems (Jayme Cox)
  Re: Enhanced IDE?? (Pirih)
  Re: -= good programmer's editor for X? (Olaf Erb)
  Re: No Free Inode on 1GB harddisk!! (Christopher Shaulis)
  Lilo Support for NRC-SCSI (Christoph Martin)
  Re: SLIP, CSLIP, PPP and modems (Rob Janssen)

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

From: wmhoffma@crab.rutgers.edu (William Hoffman)
Subject: ioctl() and using I/O ports
Date: 4 Aug 94 21:25:46 GMT

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.)

-- George Hoffman

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

From: frank@oracorp.com (Frank Flannery)
Subject: expect
Date: Thu, 4 Aug 1994 21:21:52 GMT


Has expect been ported to Linux?  I looked around on sunsite, and didn't see
it.

frank


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

From: yeul@cs.curtin.edu.au (Loong Yeu)
Subject: Adaptec controller fails with kernels 1.1.37 - 1.1.39
Date: 4 Aug 94 16:16:04 GMT


Hi,
        I seem to have a problem with kernel versions 1.1.37 ,
1.1.38 and 1.1.39.
The last kernel I was running was patch 1.1.36 which worked just fine,
as did all the patches from 1.1.24 onwards. I am getting a kernel panic 
just before the sector size of my drives is reported.
This always occurs with patches 38 and 39. Sometimes with patch37
the error does not occur and the boot process finishes, but only 
after a cold boot (Press of the reset button) if the error does
occur with patch37 then warm boots (ctrl-alt-del) will not solve
the problem. I noticed that some of the scsi code for the 1542
controllers changed in patch37. Has anyone else had these problems?
does anyone know of a fix?

My configuration is as follows.

Slackware 2.0.0
Intel 486DX2-66Mhz CPU
8 Meg of RAM
Adaptec 1542b SCSI controller (Addr 330h, IRQ 11, DMA 5, 
        DMA transfer rate set at 5.7 M/s )
2 Quantum 240 Meg scsi drives.
1 Sony CDU-561 scsi CDROM drive.

The messages displayed during boot are as follows.

Kernel logging (proc) started.
8448 bytes for swap cache allocated
Console: colour EGA+ 132x25, 12 virtual consoles
Serial driver version 4.00 with no serial options enabled
tty00 at 0x03f8 (irq = 4) is a 16450
tty01 at 0x02f8 (irq = 3) is a 16450
lp_init: lp1 exists, using polling driver
snd2 <SoundBlaster Pro 3.1> at 0x220 irq 5 drq 1
snd1 <Yamaha 2-OP FM> at 0x388 irq 0 drq 0
Calibrating delay loop.. ok - 33.22 BogoMips
Checking 'hlt' ... ok
Configuring Adaptec at IO:330, IRQ 11, DMA priority 5
scsi0 : Adaptec 1542
scsi : 1 hosts.
  Vendor: QUANTUM   Model: LP240S GM240S01X  Rev: 6.4
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, id 0, lun 0
  Vendor: QUANTUM   Model: LP240S GM240S01X  Rev: 6.4
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, id 1, lun 0
  Vendor: SONY      Model: CD-ROM CDU-561    Rev: 1.9i
  Type:   CD-ROM                             ANSI SCSI revision: 02
Detected scsi CD-ROM sr1 at scsi0, id 6, lun 0
scsi : detected 1 SCSI cdrom 2 SCSI disks total.
Kernel panic : scsi_devices corrupt (sd)
In swapper task - not syncing


I am posting from a friends account so either follow up here on the 
news, or email to his account.

yeul@marsh.cs.curtin.edu.au

Thank you.
        Jim Barber

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

From: glenn@tauon.ph.unimelb.edu.au (Glenn Moloney)
Subject: Re: A/D drivers for Linux
Date: 5 Aug 1994 02:48:47 GMT

In article <31qu1m$k2s@senator-bedfellow.MIT.EDU>,
David P. Boswell <dave@ndeux.space.thiokol.com> wrote:
>
>Is anyone working on any A/D drivers under Linux ?

Well, we have a project nearing completion here which involved writing a
Linux driver for one of the National Instruments multi-IO cards (don't
have the model number with me). The card in question is the general
purpose laboratory data acquisition and control cards. It has 16 channel
ADC, 2 channel DAC, 24 bit digital I/O, 3 * 16 bit counter/timers. The
driver is completed and working, but needs cleaning up. We expect to
release the Linux driver under the GPL. 

This reminded me about this - I might just look into getting this out
ASAP :-).

>This could be good publicity for Linux as this system involves a very
>political inspection in the Space Shuttle program.

Good luck.

>I am  dave@ndeux.space.thiokol.com  should you prefer to speak in private.

                                        cheers,
                                        glenn.

-- 
                                        
  Glenn Moloney                         glenn@tauon.ph.unimelb.edu.au
  School of Physics,                    Phone: +61 3 344 5081
  University of Melbourne,              Fax:   +61 3 347 4783
  Parkville, Australia 3052.

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

From: tor@spacetec.no (Tor Arntsen)
Subject: Re: lint for linux
Date: 1 Aug 1994 21:58:52 GMT
Reply-To: tor@spacetec.no

In article 5dj@senator-bedfellow.MIT.EDU, D.G.Jones@scuna.dircon.co.uk (Derek Jones) writes:
>Sigh, again,
>
>I have responded privately to some of the people who have
>said "gcc does everything" over the last few months
>but now feel it's time for the list.
>
>gcc -Wall -pedantic does *not* catch some of the (even
>more trivial) errors that a decent lint will catch. *Esp.*
>if those errors are *calling problems between* source files.
[..]
Use prototypes.  Put them in a .h file. Include the file in the .c file, and in
other applicable source files.  Put a target into the Makefile that sends GCC
'-fsyntax-only' and all the -W's you can think of.
Maybe it doesn't catch everything, but it does a good job in my opinion.
For old non-prototyped non-ANSI code it's another story of course.

Regards,
Tor



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

From: cordones@cs.nyu.edu (Jose Cordones)
Subject: Linux 1.1.37 sys V/Coherent fs glitch
Date: 1 Aug 1994 09:21:33 -0400

Hi.
I had applied patch36 and patch37 against linux-1.1.35.
Out of curiosity, I had enabled Sys V/Coherent File System support.
When making the kernel, I stumbled upon this problem:
mmap.c:69: conflicting types for `sysv_mmap'
/usr/src/linux-1.1.37/include/linux/sysv_fs.h:430: previous declaration 
of `sysv_mmap'
When I checked the function prototype in <linux/sysv_fs.h>,
It indeed was totally different to the definition type in 
../src/linux/fs/sysv/mmap.c
This puzzled me (for about a night).  I traced the problem to patch37.
Before the patch is applied, sysv_fs.h has this:
#if 0
 extern int sysv_mmap(struct inode *, struct file *, unsigned long, 
 size_t, int, unsigned long);
#endif
Of course, the prototype never gets defined since this is FALSE.
Patch 37 removes the #if 0 and #endif, so now this becomes part of
the include file.
What I did was re-type in the #if 0 and #endif, but putting an #else in 
between (which, then, will always get executed) and making a prototype 
copy of the actual definition in ../src/linux/fs/sysv/mmap.c
This is temporary, I hope it gets fixed in patch38 :-)

Someone rumored me that it would be.
I think someone else posted about having this problem before.

Hope it helps,
Jose' R. Cordones
cordones@vanzetti.cs.nyu.edu


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

From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen)
Subject: Re: Fatal Signal 11 - reproduceable !
Date: 1 Aug 1994 23:50:40 +0300

In article <CtuqL8.73o@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:

>Errors in SIMM memory should be reported as parity errors, at least some
>of the time.  Make sure you have parity enabled in the system setup (CMOS).

They should, but this is not always the case. At least I have one
counter-example. I get rare sig 11s and occasional complains about
"bad swap page map" etc. in my syslog. After swapping memory chips,
the number in those error messages changed. I replaced the SIMMs, and
have not seen sig 11s or the error messages ever since.

--
Janne.Sinkkonen@helsinki.fi  <http://avocado.pc.helsinki.fi/~janne/>

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

From: D.G.Jones@scuna.dircon.co.uk (Derek Jones)
Subject: Re: lint for Linux
Date: 5 Aug 1994 05:35:23 -0400
Reply-To: D.G.Jones@scuna.dircon.co.uk (Derek Jones)

Hello,

In reply to my posting about lint being better in the
multi-file case, someone said I should use prototypes . . .

I teach C for a living.

I am well aware of how to do it properly. Lint is useful in
those cases you haven't! 8-)

As I remember, that wasn't the only problem. Oh well.

I will put my test files together again , (later, I'm up to my
ears right now). I am reluctant to post these in order not to
clog the list on what is now not a Linux topic. So, - if you 
would like to see the results, please drop me an email saying
something like, "Lint: me too" in the subject line and I'll
email you something in due time.

(Won't be in the next two weeks . . .)

Kind regards to all.

Derek


================================================================================
Derek Jones                                          !SCUNA Computer Consultancy
Computer Consultant                                  ! 53 Archer Road, Sheffield
SCUNA (Systems,C,UNIX,Networking,Advice)             !                    S8 0JT
Email: D.G.Jones@scuna.dircon.co.uk                  !                        UK
WWW: http://scuna.dircon.co.uk/public_html/scuna.html!       Tel: +44 742 555524
================================================================================


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

From: nolte@theo.physik.uni-bremen.de (Andreas Nolte - Universitaet Bremen)
Subject: Re: -= good programmer's editor for X?
Date: 5 Aug 1994 06:55:00 GMT

Gaybeul (liphy02@frbdx12.cribx1.u-bordeaux.fr) wrote:
: Kris Nybakken (nybakken@world.std.com) wrote:

: : Hi.

: : Are there any good programmer's editors for X - not term-like ports?

: : I'm diving into *nix development from the Mac and Windows world, and 
: : haven't had to use a terminal-like editor since my Apple II days!  I'm 
: : thinking of something like you'd find under Think C or Visual C (not 
: : super-feature loaded, but a good tool).  I've tried the Emacs with the X 
: : stuff (menus and the like), but I was kinda hoping for things like syntax 
: : coloring, font-size-on-the-fly, etc.  Not to mention that I don't like the C 
: : mode and am not into learning elisp to change it.  Not to mention I'm not 
: : a believer in having everything AND the kitchen sink installed in my editor.

: : Anything out there?

: : Please email - I'll summarize and/or forward for other interested parties.


: : kristof-
: : nybakken@world.std.com

: Emacs has a syntax coloring mode (highlit) and is font sensitive (see previous
: messages). But there's also a version called Lucid Emacs, which should have been
: called xemacs ;-) which handles these things more easily...
: If you have free memory to use, try Lucid Emacs.

: Lokh.

There's an editor, which almost looks and functions like the Borland IDE.
It's called Xwpe and you can pick it up somewhere on ftp.rrzn.uni-hannover.de.
(looks great!)

A.N. (nolte@physik.uni-bremen.de)



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

From: tzs@u.washington.edu (Tim Smith)
Subject: Re: Interesting idea for lilo developers
Date: 5 Aug 1994 09:27:20 GMT

Jon Thackray <jrmt@froggy.demon.co.uk> wrote:
>Then you can run Linux via loadlin from DROS, so you can get
>Linux to boot DROS, and DROS to boot Linux. What more do you

If "loadlin" does what it sounds like it does, what is the need
for boot managers, anyway?  Note that MS-DOS 6.xx allows you to
have multiple configurations, which you can easily select from
a menu when config.sys is processed.

It seems to me that instead of bothering with fancy boot managers, it
would be simpler just to always boot DOS, and have a selectable DOS
configuration that runs a program to switch to Linux.  On my computer,
it only takes a couple of seconds from the time I tell it to boot
DOS to the time it's in menu from config.sys, so going through DOS
on each boot of Linux would not really add much time.

--Tim Smith

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

From: tzs@u.washington.edu (Tim Smith)
Subject: Re: Interesting idea for lilo developers
Date: 5 Aug 1994 09:29:27 GMT

Bill Kress <kress@kentrox.com> wrote:
>So, the night before I'm supposed to guess what system I'm 
>going to want to use when I come home from work the next day?
>From experience I'd be wrong at least 70% of the time...

Uh, if you would make you choice, and then do the opposite, you'd
only be wrong 30% of the time.

--Tim Smith

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

From: jayme@rain.org (Jayme Cox)
Subject: Re: SLIP, CSLIP, PPP and modems
Date: 5 Aug 1994 02:55:30 -0700

Someone known as Jay Denebeim P025 (denebeim@bnr.ca) spake thus:

> yuriev@astro.ocis.temple.edu (Starcon SysAdmin) writes:
> >Linux <--> Linux using Hydra on 1.7Mb & 1.4Mb ZIP files: total time 17 min
> >
> >Linux <--> Linux via SLIP (ftp transfer). Total time: 28 min 48 sec. 

> Alex, you're comparing apples and oranges.  A network is not the same
> thing as a file transfer.  SLIP is used to send arbitrary packets over
> the phone line onto a network.  Its not limited to sending files.
> Because of this, there is quite a bit more information that is
> required for each packet then a file transfer takes.  Because of this,
> it is definately going to be slower.

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.

However, I am not sure exactly what test Alex is running. Are you doing two
simultaneous ftp sessions? (one from linux1 -> linux2 and one from
linux2 -> linux1 at the same time?) And that is what takes 28 mins?
Or are you just ftp'ing two files (1.7Mb & 1.4Mb)?

I'm not at my Linux box or I'd test it. But try this:
telnet to linux-box2 and ftp back to linux-box1. At the same time ftp from
linux-box1 to linux-box2. If the modem is transfering bi-directional
there should be no difference in transfer times vs a single ftp session.
(discounting kernal overhead, disk writes, etc)

-- 
Jayme@rain.org                       http://www.rain.org/~jayme/sig.html
JC158
"Angelheaded hipsters burning for the ancient heavenly connection to the
 starry dynamo in the machinery of night."  --"Howl" by Allen Ginsberg

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

Crossposted-To: comp.os.linux.admin
From: pirih@eskimo.com (Pirih)
Subject: Re: Enhanced IDE??
Reply-To: pirih@eskimo.com
Date: Thu, 4 Aug 1994 00:31:28 GMT

In article <Ctz9sM.48M@haapi.mn.org>, clay@haapi.mn.org (Clayton Haapala) wrote:
> The physical drive params are: 1057 cylinder, 16 heads, 63 sectors/track.
> The BIOS, of course, would like to limit that to 1024 cyls.
> 
> Because it physically doesn't have more than 16 heads, I would like to see
> it work like this:
> 
>       Set BIOS to 1024 cyls/16 heads/63 sectors
> 
>       When Linux boots (with kernel 1.1.37 or higher), the actual drive
>       parms are queried and stored, and then used in programs such as
>       linux fdisk.

I get the feeling the BIOS would be pretty confused by a partition
that spans the 1024 cylinder boundary.  (LILO uses the BIOS to read
the disk, so whatever partitions LILO reads had better be BIOS-
accessible.)  I'd say the best plan is to use cylinders 1024-1057
for a swap partition.

---
chris

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

From: erb@inss1.etec.uni-karlsruhe.de (Olaf Erb)
Subject: Re: -= good programmer's editor for X?
Date: 5 Aug 1994 10:32:24 GMT

South Street North Studios (ssn@pnet1.pnet.com) wrote:
: Chris Bitmead (chrisb@cssc-syd.tansu.com.au) pondered:
: => Emacs 19.25 has syntax colouring.

: Really?! Holy smoke -- I've been wishing for that. I'm *just* getting to 
: know emacs; I love it. But how does one activate this syntax colouring?

I've this in my site-lisp/default.el, but .emacs should work, too:

(cond (window-system
       (setq hilit-mode-enable-list  '(not text-mode)
             hilit-background-mode   'light
             hilit-inhibit-hooks     nil
             hilit-inhibit-rebinding nil)

       (require 'hilit19)
       ))

Gives nice highlighting, but *only* under X11. Update the screen with
^L.

Have fun,
Olaf

Ah, anyone got xwpe running under Solaris2.3 :) ? The I/O redirection 
doesn't work for me with the debugger..
--
===============================================================
!   erb@insu1.etec.uni-karlsruhe.de  dc1ik@db0sao.ampr.org    !
! <A HREF="http://inss1.etec.uni-karlsruhe.de/~erb">click</A> !
===============================================================

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

From: cjs@netcom.com (Christopher Shaulis)
Subject: Re: No Free Inode on 1GB harddisk!!
Date: Mon, 1 Aug 1994 19:47:51 GMT

g609296@win.or.jp (Barry Yip kam-wa) writes:

>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. 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.
>Any suggestion and comments welcome.

As I understand the inner workings of the news software, it involves 
storing and manulipating thousands of little files. Those will chew
op your inodes like nothing else. =)

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

That is an excert from the mkfs.ext2 man page. Because you are running it
as a news server you should probably do -i 1024. You will then be able
to store many many more of those itty-bitty news articles. The trade off
is that you'll be dedicated 4x as much space to inodes. 

Christopher

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

From: martin@wilbur.zdv.Uni-Mainz.DE (Christoph Martin)
Crossposted-To: comp.os.linux.admin
Subject: Lilo Support for NRC-SCSI
Date: 5 Aug 1994 09:23:19 GMT

Hello,

I installed Linux-1.1.19 on my ASUS-PCI Computer with the ncr-kernel
and it works fine. Only lilo won't install in the master boot record
for booting OS/2 from /dev/sda1 or Linux from /dev/sda2.

/etc/lilo.conf :
>boot = /dev/sda
>delay = 50
>vga = normal
>ramdisk = 0
>
>image = /ncr
>  root = /dev/sda2
>  label = Linux
>
>other = /dev/sda1
>  label = OS/2
>  table = /dev/sda

Lilo can add the option to start Linux but not to start OS/2:

>HDIO_REQ not supported for your SCSI controller. Please use /etc/disktab

I use a 540MB Quantum disk and tried disktab entries like

> 0x800 0x80    32      64      ..

I'm just guessing these values, but there is no difference in the
error message.

Christoph Martin

--
============================================================================
Christoph Martin, Zentrum f|r Datenverarbeitung, Uni-Mainz, Germany
Internet-Mail:  martin@goofy.zdv.Uni-Mainz.DE
   Paper-Mail:  C. Martin, Zentrum f|r Datenverarbeitung,
                Johannes-Gutenberg-Universitdt, 55099 Mainz, Germany
      Telefon:  +49 6131 396316

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: SLIP, CSLIP, PPP and modems
Reply-To: pe1chl@rabo.nl
Date: Fri, 5 Aug 1994 08:48:21 GMT

In <31rvve$8hd@herald.indirect.com> mcguirk@indirect.com (Dan McGuirk) writes:

>In article <1994Aug3.134423.5631@brtph560.bnr.ca>,
>Jay Denebeim P025 <denebeim@bnr.ca> wrote:
>>Alex, you're comparing apples and oranges.  A network is not the same
>>thing as a file transfer.  SLIP is used to send arbitrary packets over
>>the phone line onto a network.  Its not limited to sending files.
>>Because of this, there is quite a bit more information that is
>>required for each packet then a file transfer takes.  Because of this,
>>it is definately going to be slower.
>>
>>It probably shouldn't be a factor of two though.  Are you sure you
>>wern't using the link for something else at the same time?

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

Of course such protocols exist for UNIX as well.  E.g. Taylor-UUCP.
I think it is "marketing speak" to just add-up the throughput figures
in each direction.  Users would be easily misled by this.

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

No, SLIP and PPP are bidirectional.  You can get and put a file at the
same time, in two different FTP sessions.
This has *totally nothing* to do with ISDN, which simply means a speed
increase.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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


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