Subject: Linux-Development Digest #900
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 21:13:07 EDT

Linux-Development Digest #900, Volume #1          Fri, 8 Jul 94 21:13:07 EDT

Contents:
  Re: Linux Performance Enhance ? (Clayton Haapala)
  Re: lint for linux? (Steven A. Reisman)
  Re: Fatal Signal 11 - reproduceable ! (Erik Troan)
  Re: TCP/IP networking for DOSEMU - Why it should be there. (Andrew Anderson)
  Xconfig builder (Elaine Walton)
  GKS and PHIGS
  mmap /dev/mem beyond main memory size (Kwun Han)
  [ANSWER] Linux seems to perform terribly for large directories (Stephen Tweedie)
  Re: Linux (1.1.24) hangs in cdrom access. (Donald Jeff Dionne)
  Bug compiling smail with libc 4.5.26 and gcc 2.5.8 (John Henders)
  How to know the patch level (Yavuz Onder)
  Still attempting to compile kernel with g++ (Mr DV Watkins)
  Re: TCP/IP networking for DOSEMU (Johannes Stille)
  syscall() seems broken at least upto V1.1.13.. (Gautam Thaker)
  syscall() problem, actual program... (Gautam Thaker)
  SCSI debug info requested (Dave Williams)

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

From: clay@haapi.mn.org (Clayton Haapala)
Subject: Re: Linux Performance Enhance ?
Date: Fri, 8 Jul 1994 04:19:37 GMT

I believe Xenix 386  uses a paging/swapping method, where paging as we know
and love it happens as usual until the system gets really swamped, and
"thrashing" occurs.  Then whole processes start getting swapped-out in the
classic swapping manner, leaving, as a previous poster said, lots more
room for the paging algorithm to again work efficiently.
-- 
Clay Haapala                    "Well, there was the process of sitting around
clay@haapi.mn.org                and wishing I had more computer stuff."
                                        -- Dilbert

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

Crossposted-To: comp.os.linux.help
From: sar@bee.beehive.mn.org (Steven A. Reisman)
Subject: Re: lint for linux?
Date: Fri, 8 Jul 1994 01:34:01 GMT

David Lyle Robinson (robinson@ichips.intel.com) wrote:
: Is there a version of lint for linux?  I'm running slackware,
: and I didn't see it on any of the 'd' disks.



Here's a script you can call `lint':



#!/bin/sh

# This runs gcc with all warnings enabled, except for the following
# exceptions:
#
# -Wshadow              broken for C++ templates
# -Wredundant-decls     causes too many complaints in system header files
# -Wconversion          really only intended to help people using `unprotoize'
# -Waggregate-return    not useful, IMHO

OPTS="-ansi -pedantic
      -Wall -Wwrite-strings -Wid-clash-31 -Wpointer-arith -Wcast-qual
      -Wenum-clash -Wcast-align -Wtraditional
      -Wstrict-prototypes -Wmissing-prototypes
      -Wnested-externs
      -Woverloaded-virtual -Winline
      -O -felide-constructors -fnonnull-objects
     "

exec gcc $OPTS "$@"

-- 
Steven A. Reisman
12695 4th St. S.                                  sar@beehive.mn.org      
Afton, MN  55001                                      (612) 436-7125

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

From: ewt@merengue.unc.edu (Erik Troan)
Subject: Re: Fatal Signal 11 - reproduceable !
Date: 8 Jul 1994 14:02:14 GMT

In article <CsM1G3.AqB@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>1. $ is not a valid variable name in standard C.
>   maybe it is on some dialects on systems that use $ in names (VMS)

He pointed out that -traditional fixes it.

>2. This sounds more like a bug in GNU C, so you better ask it in a related
>   newgroup.  Be prepared, however, to be flamed about sending a bug report
>   without even mentioning the version number of the compiler...

I just tried this on a linux machine after ":1,$s/\$/dol/g" and it
worked fine. What versions of things is the original poster using? Here's
the important info on my system:

[4] % gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/2.5.8/specs
gcc version 2.5.8
[5] % cat /proc/version
Linux version 1.1.25 (root@bittyblue) #15 Thu Jul 7 13:03:38 EDT 1994
[6] % ldd mandel
        libc.so.4 (DLL Jump 4.5pl24) => /lib/libc.so.4.5.24


If anyone cares, it also works with gcc verison 2.3.3 on HPUX.

Erik
-- 
===========================================================================
"I'm not like that -- except when I am"   ewt@sunsite.unc.edu  = Erik Troan
                                          sasewt@unx.sas.com
    - Nora from "Pump up the Volume"      gr-ewt@druid.csc.ncsu.edu

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

From: andersoa@news.db.erau.edu (Andrew Anderson)
Subject: Re: TCP/IP networking for DOSEMU - Why it should be there.
Date: 8 Jul 1994 19:41:18 GMT

James B. MacLean (jmaclean@fox.nstn.ns.ca) wrote:
:   I know I've been doing a poor job of tantalizing anyone into taking 
: anything on with this :-(, but Johannes, I'd really appreciate the 
: interface, even just to say that YES DOSEMU supports TCP/IP over the 
: pktdrvr. Jason, Rob and Tim Bird have blown the useablity of DOSEMU wide 
: open with an interface to NetWare. Now I'm interested in getting full-true 
: pktdriver compatibility.

Just an idea here -- a friend said that he was able to get multiple 
logins to a Netware server by loading the ODI drivers *only* before
starting windows, and then loading VLM's under a different DOS session
under windows.  This was using only one e-net card.

Could this be done under linux?  I've tried using the VLM's, but I
haven't had any luck.  Has anyone else tried this?

Andrew (by god, one of these days I'm gonna make this work!) Anderson

--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

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

From: ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
Subject: Xconfig builder
Date: 8 Jul 1994 18:45:40 GMT

I recently completed updating my ModesDB timings generator.  Now it makes
an Xconfig.  I have tested it on 256-color SVGA; it needs testing on 16-
and 2-color VGAs.  It does not work yet on excelerators (like S3, etc.).
I would like to have a few more volunteers who would like to test this
tool.
Please email me if interested.
-Sean Walton

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

From: 92284395@cpccspc.cphk.hk ()
Subject: GKS and PHIGS
Date: Fri, 8 Jul 1994 06:45:09 GMT

I am looking for a graphic database for linux (GKS and PHIGS). Anyone else
who knows the information about that, Please leave a message for me.

Thanks

Nelson Mok

92284395@cphkvx.cphk.hk



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

From: kwh@cs.brown.edu (Kwun Han)
Subject: mmap /dev/mem beyond main memory size
Date: Fri, 8 Jul 1994 19:47:40 GMT

Hi kernel hackers,

        I am having problem trying to mmap memory mapped device via
/dev/kmem. I have this device which maps it memory space to physical
memory location 0xa0000000, and I would like to map it into user's
space. How would I go about doing that? I would prefer not having to
copy stuff around.

Thanks!
Kwun
-- 
=================================================================
kwh@cs.brown.edu (preferred)    | Box #2392, Brown University,
kwh@lems.brown.edu              | Providence, RI 02912
Kwun_Han@brown.edu              ------------------------------
GE/CS d? p c++(+++) l(++)+++ u e+ m++@ s+/- n+@ h* f(+) g+ w+ t r-
=================================================================

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

From: sct@dcs.ed.ac.uk (Stephen Tweedie)
Subject: [ANSWER] Linux seems to perform terribly for large directories
Date: Fri, 8 Jul 1994 13:39:29 GMT

Hi,

I just thought I'd mention that this is very much a work-in-progress
topic.  At the Heidelburg conference, Ted Ts'o and I discussed this at
some length, and Ted even found a glaring bug in the existing
readdir() system call (one which affects all long-filename
filesystems, by the way).

So, I've currently got tentative bug-fix patches and performance
improvements for the directory handling code.  The bug-fix should also
mean that the ext2fs directory cache may now be re-enabled.

There are two major performance enhancements: first, readdir() now
returns more than one directory entry if requested (up to a whole
block-full, in fact).  This requires library support too, by the way,
but will not require any applications to be recompiled: *all*
applications use the readdir(3) from the library, not readdir(2).

Secondly, there is the directory cache.  This is a major win for
things like "ls -l", where an application does a repeated
readdir()/stat().  Up to 128 directory names resolved by readdir() and
lookup() will be cached, and these names may then be referenced
without scanning the entire directory tree again.

Once they are tested, these patches should be in a kernel soon.  Watch
this space... :-)

Cheers,
 Stephen.
---
Stephen Tweedie <sct@dcs.ed.ac.uk>   (JANET: sct@uk.ac.ed.dcs)
Department of Computer Science, Edinburgh University, Scotland.

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

From: jeff@ee.ryerson.ca (Donald Jeff Dionne)
Subject: Re: Linux (1.1.24) hangs in cdrom access.
Date: 8 Jul 1994 22:18:59 GMT

Laurent Chemla (laurent@brasil.frmug.fr.net) wrote:
: Description:
: From time to time, when accessing my scsi cdrom (Chinon), mostly from an nfs
: mounted DOS host, but also from the console itself, the kernel just hangs
: during a read access. The cdrom drive is quite slow, and I usually get
: some:
:       kernel: SCSI host 0 abort() timed out - reseting


I also have a 1542c and I get this problem regularily.  I can also make it
happen at will, too.  All you have to do is run WorkMan under X, set it
to autorepeat the whole disk, anbd when it tries to go over the end and
wrap around to the beginning of the disk, the kernel will ALWAYS lock solid.
the syslog then contains the same messages you describe below. 

BTW, I'm running 1.1.18, but  have had what I thought werre random lockups
since long before.  It's just recently I found out how to make it happen
at will.  I have a Panasonic CD-ROM 4101, so if it's anything, it's that
we don't have a solid SCSI bus or the 1542 driver is somehow broken, or
the SCSI CD_ROM code is broken.  My SCSI HD works no prob, and I've only got
8MEG so it swaps like there's no tomorrow...  I'll bet it's the CD-ROM code.


Good Luck, Jeff@EE.Ryerson.Ca

: in my /var/adm/messages file. It looks like sometime this timeout occurs when
: the kernel is in the linux/drivers/scsi/sd.c rw_intr() routine, leading my
: box into a crash.

: I tried to add some debug messages from the scsi driver and got:

: Jul  8 15:59:49 brasil kernel: SCSI host 0 abort() timed out - reseting
: Jul  8 15:59:49 brasil kernel: Sent BUS DEVICE RESET to target 0
: Jul  8 15:59:49 brasil kernel: Sending DID_RESET for target 0
: Jul  8 15:59:49 brasil kernel: Sending DID_RESET for target 0
: Jul  8 15:59:49 brasil kernel: aha1542_intr_handle: Unexpected interrupt
: Jul  8 15:59:49 brasil kernel: tarstat=0, hastat=0 idlun=10 ccb#=5
: Jul  8 15:59:49 brasil kernel: aha1542_intr_handle: Unexpected interrupt
: Jul  8 15:59:49 brasil kernel: tarstat=0, hastat=0 idlun=10 ccb#=6

: in /var/adm/messages.
: This crash occurs regularly (i.e. almost always, but the days I got a lot of
: luck) when I try to use thiis cdrom drive.

: Configuration:
: Linux 1.1.24 with both scsi and ide drives, 1542B ISA card.
: One 500Mo IDE HD
: One 1Go Micropolis SCSI HD
: One Chinon SCSI CDROM.
: Pentium 60 PCI.
: Same symptoms when the kernel is compiled with gcc2.5.8 or when I use the
: Pentium optimized 2.5.8 gcc version. Same symptoms from a very long time
: ago (I dont remember when this begun, but it was around 1.0 release). Same
: symptoms on my previous 486DX2/66 PC.

: Kernel debug report:
:         Oops: 0000
:         EIP:   0010:0019120d (linux/drivers/scsi/sd.c rw_intr() routine).
:         eax: 00000000   ebx: 000000c0   ecx: 00000000   edx: 3d1dd1f
:         esi: 001e6dee   edi: 001e6c6e   ebp: 18000000
:         ds: 0018  es: 0018  fs: 002b  gs: 002b
:         Pid: 0, process nr: 0
:         8a 42 01 50 8b 74 24 20 31 c0 8a 06 50 8b 7c 24 8b 47 0c

: Hope this helps someone to debug :-)
:  
: --
: Laurent Chemla : chemla@cnam.cnam.fr or laurent@brasil.frmug.fr.net
: Brasil BBS  - +33 1 44 67 08 44 -  Atari France developpers support

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

From: jhenders@jonh.wimsey.com (John Henders)
Subject: Bug compiling smail with libc 4.5.26 and gcc 2.5.8
Date: Fri, 8 Jul 1994 03:53:58 GMT



        I have been trying to get a working version of smail 2.1.28
compiled under recent libraries, and have run across a weird bug. I used
the config files from newspak as a starting point, and wanted to add the
tap patches and change the file locking code. However, this bug shows up
without any modifications to the default config files.
        What happens is, if my machine is not connected to the net by
slip, I have a uucp connection for mail and news. When I'm on the net,
outgoing mail goes out via smtp and everything works. If I am off the
net, the smtp fails and smail falls through to uux. Then the bug hits.
The D.* file is created in /usr/spool/uucp/sitename with 0 byte size.
This used to work fine under the smail that came in the Slackware I
installed last December. Also, to make things harder to check, if I try
to use the debug flag to see what smail is doing, then it works
properly.

        I tried compiling smail with no optimising, but that doesn't fix
the problem. I haven't seen anyone else report this, but has anyone run
across it, and is there a fix?

-- 
                  John Henders - Wimsey Information Services
               http://www.wimsey.com/ (teletimes, gnn and more)
                  GAT/MU/AE d- -p+(--) c++++ l++ u++ t- m--- 
                       e* s-/+ n-(?) h++ f+ g+ w+++ y*

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

From: yavuz@bnr.ca (Yavuz Onder)
Subject: How to know the patch level
Date: Fri, 8 Jul 1994 21:07:49 GMT

I want to know what patch level of 1.0 I am running. I tried "uname"
it only tels me it is "1.0".

Is there a place in source distribution, in header files or
wherever else, I can extract this info?

Please post or e-mail as you find convenient...

Thanks in advance
-- 
   Yavuz Onder    | Bell-Northern Research Ltd.  | My opinions aren't
   yavuz@bnr.ca   | P.O. Box 3511 Station C      | necessarily BNR's,
 1-(613)-763-2294 | Ottawa, Ont. CANADA  K1Y 4H7 | or vice versa.

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

From: damien@monu1.cc.monash.edu.au (Mr DV Watkins)
Subject: Still attempting to compile kernel with g++
Date: 8 Jul 1994 05:13:03 GMT

Hello (again).

I recently posted a question about compiling and linking the kernel
using gcc -x c++ to allow me the modify the kernel code using c++.

The problem is caused by function name mangling and the linker
cannot resolve some addresses. To solve this I thought I would compile
the entire kernel as c++, (as c++ is a superset of c I thought it
would work). Still the same problem.

Has anyone compiled the kernel using g++? If so can you send me a line
telling me how it is done.

Thanks (again)
Damien
damien@monu1.cc.monash.edu.au

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

From: johannes@titan.westfalen.de (Johannes Stille)
Subject: Re: TCP/IP networking for DOSEMU
Date: Thu, 7 Jul 1994 22:04:03 GMT

In article <2vgaf8$raf@smurf.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
[...]
>There are two ways to let dosemu talk TCP/IP:
>- Implement a "packet driver" and give dosemu its own IP number via the
>  method outlined by Byron.
>- Implement a DOS-TCP/IP driver which takes TCP/IP requests from DOS programs
>  and uses the corresponding Unix socket()/bind()/read()/whatever calls.
>
>The advantage of the first version is that it's easy to code.
>
>The advantage of the second version is that the machine has only one IP
>address, you don't have to do fancy routing or subnetting in your network,
>and you don't have to load an entire (possibly buggy) TCP/IP stack into
>dosemu. After all, there's already a perfectly workable TCP/IP stack in the
>kernel...

Generally, this is a great idea. Is there anybody out there who could /
would implement this?

There are possible problems, though: If you run SOSS under dosemu to
access Netware servers or compressed DOS disks, I don't think you could
run another NFS server under Linux. Also if you have some binary-only
MSDOS program that wants to use a packet (or ODI, or NDIS) driver and
contains the TCP/IP code itself, a dosemu integrated TCP/IP interface
doesn't help.

[...]
>> 
>Umm, routing in the presence of point-to-point links, non-byte-boundary
>network masks, and similar stuff, didn't work all that well until fairly
>recently.

I can't remember any special routing problem with point-to-point links
even with the original Net-2d in - was it 0.99.10?
Arbitrary network masks were introduced with the later 0.99.14* kernels.

        Johannes

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

From: gthaker@polyphony.sw.stratus.com (Gautam Thaker)
Subject: syscall() seems broken at least upto V1.1.13..
Date: 08 Jul 1994 14:22:42 GMT


The following program works fine under SUNOS, but fails under Linux
1.1.13. I did some asm debugging and it seems that pgm
goes into syscall () routine in the userspace but once it
enters the kernel by doing a "int 0x80" the program simply exits
without any msgs of any type.

Is this a linux bug or am I missing something....

Thanks.

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

From: gthaker@polyphony.sw.stratus.com (Gautam Thaker)
Subject: syscall() problem, actual program...
Date: 08 Jul 1994 14:24:40 GMT


I failed to include this in my original mail. Sorry.
(note: this pgm fails on linux kernel 1.1.13 (and on 0.99pl15f).

#include "stdio.h"
#include "unistd.h"

#include <sys/param.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/socketcall.h>
#include <sys/ioctl.h>
#include "/usr/include/netinet/in.h"
#include "/usr/include/netinet/in_system.h"      /* in_systm.h on SUNOS */
#include "/usr/include/netinet/ip.h"
#include "/usr/include/net/if.h"
#include <sys/uio.h>
#include <netdb.h>
#include <errno.h>

int foo(int domain, int type, int protocol) {
/* under SUNOS SYS_SOCKET is SYS_socket. */
  return syscall(SYS_SOCKET, domain, type, protocol);
}


int main() {
  int s;
  s = foo(AF_INET, SOCK_DGRAM, 0);
  printf("s = %d\n", s);
  return 1;
}

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

From: williams@etc.atinc.com (Dave Williams)
Subject: SCSI debug info requested
Date: Fri, 8 Jul 1994 10:35:24


OS: Slackware Linux 1.2.0 w/Kernel 1.1.24
SCSI support compiled in for AHA 1542: Disk, Tape, CD, Generic 
HW: 486/33 w/AHA-1542B 2 SCSI drives, ExaByte 8500 8mm tape

I have the above configuration working well with the exception
of the SCSI Tape.  I have checked SCSI termination [system hangs nicely 
when it isn't terminated properly] and cabling issues and can repeat the 
problem with kernels down to 1.1.18 (I'll try a 1.0 kernel this weekend).

Problem Symptoms: First attempt to access the SCSI tape (/dev/st0 or 
/dev/rmt0) results in an I/O error

Excuse me if I'm not explicit here the machine is at home:

mt -f /dev/rmt0 status
I/O Error ..... 

Subsequent attempts succeed with the response of:
unknown tape (114)

Write appear to function properly (tar lists all the files being written, 
and the tape spins away).  But I'm UNABLE TO READ from the tape to
ensure the data was written.

I'd like to find out what's hanging the system so I enabled DEBUG in 
aha1542.c with a #define DEBUG.  Now the 1.1.24 kernel hangs during 
bootup.  The final message being "device timed out".

Any hints/suggestions on a useful way of performing the SCSI debugging 
would help.

Replies appreciated via email:
williams@etc.atinc.com



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


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