Subject: Linux-Development Digest #831
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:     Wed, 15 Jun 94 08:13:04 EDT

Linux-Development Digest #831, Volume #1         Wed, 15 Jun 94 08:13:04 EDT

Contents:
  Re: RARP under Linux (Kethi-Reddy Vanier)
  Re: Adaptec 2742 driver (Mark A. Horton KA4YBR)
  Re: problems with TCP connection - linux or solaris error? (Charles Hedrick)
  Re: Why is Linux writing to Port 0x80? (Colin Plumb)
  Re: SCSI NCR drivers (Drew Eckhardt)
  Re: Why is Linux writing to Port 0x80? (Drew Eckhardt)
  Re: A means of networking through Firewalls (Doug Merritt)
  No Networking w/ Kernel > v1.1.12 (Jon D. Cardwell)
  Re: Linux game development (Was Re: Why [DOS, W (Greg McGary)
  Re: IDE PERF. PATCH SECURITY HOLE (Kevin Brown)
  Re: re: Linux CD (Richard M. Warner)
  Re: loop-2 status? (Mitchum DSouza)
  Help installing PAS under Linux (BRIAN KEITH PIPA)
  Smalltalk (GNU) (J.A.Dennison)
  RARP Under Linux (MATTHEW TIPPETT)
  dosemu/ET4000 help wanted (Bill Buie)
  Re: SCSI NCR drivers (Kevin Brown)

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

From: vanier@aurora.carleton.ca (Kethi-Reddy Vanier)
Subject: Re: RARP under Linux
Date: Wed, 15 Jun 1994 03:57:11 GMT

  I am also interested please post it here.

thank you

--
========================================================================
Vanier, Kethireddy                      email: vanier@aurora.carleton.ca
BEng, Computer Systems. (4th year)





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

From: mah@ka4ybr.com (Mark A. Horton KA4YBR)
Subject: Re: Adaptec 2742 driver
Date: Wed, 15 Jun 1994 04:01:00 GMT

Thomas Wahlbuhl (wahlbuhl@informatik.uni-hildesheim.de) wrote:
: Hello,

: I'm looking for a driver for the Adaptec 2742T SCSI controller for an EISA      
: board. Can anybody tell me whether there exists one (and where to get)?

:    Thomas Wahlbuhl
:    wahlbuhl@informatik.uni-hildesheim.de

From the SCSI-HOWTO :

Drivers that are being developed, but aren't publically available yet.

Announcements WILL be made when drivers are available for public
alpha testing.  Until then, please don't use up the developers'
valuable time with mail asking for release dates, etc.

Adaptec 2742 / 2842 / AIC 7770
DPT EATA
NCR53c8x0/7x0
Qlogic
Trantor T130B (interrupt driven, using pseudo-DMA)
 


--
We are all agreed that your theory is crazy.  The question which
divides us is whether it is crazy enough to have a chance of being
correct.  My own feeling is that it is not crazy enough.
                -- Niels Bohr
============================================================
Mark A. Horton       ka4ybr             mah@ka4ybr.atl.ga.us
P.O. Box 747 Decatur GA US 30031-0747         mah@ka4ybr.com
+1.404.371.0291                     33 45 31 N / 084 16 59 W

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

From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Subject: Re: problems with TCP connection - linux or solaris error?
Date: 14 Jun 94 22:38:32 GMT

rzm@oso.chalmers.se (Rafal Maszkowski) writes:

>I'm using Linux 1.1.19 (dain) and I'm connecting to Solaris 2.2
>(waldemar). They are on different networks and there is many hops
>between, two of the hops are heavy loaded satelite links.  There were no
>problems before but since few days almost every connection is reseted
>immediately. After some time I can telnet once, like here:

In the example that fails, data is sent with the SYN.  In the example
that works it is not.  I conjecture that Linux does not properly
process a segment that has both a SYN and data.  It's uncommon to
combine these.  (Solaris is the only system I've seen that does.)
It's dangerous because at the time you sent the SYN you have no way of
knowing what the window or segment size is at the other end, so you
could inadvertently sent a segment that will be thrown away by the
other end.  In that case the SYN might never get processed.  It looks
to me like there's a bug somewhere on the Linux side.  But I also
reported this to Sun as a bug, because it also caused trouble with an
older version of Cisco's TCP.  Cisco fixed their code to accept it,
and I believe Sun fixed their TCP to not send data with a SYN.  I
think Solaris 2.3 would fix this.  But Linux should also be fixed to
deal with Solaris 2.2.

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

From: colin@nyx10.cs.du.edu (Colin Plumb)
Subject: Re: Why is Linux writing to Port 0x80?
Date: 14 Jun 1994 22:03:18 -0600

In article <2tkqs0INN2hi@vision.uccs.edu>,  <news@vision.uccs.edu> wrote:
>Hi,
>I have a POST-card (Power On Self Test) installed in my Linux-box;
>it decodes and displays data written to port 80H, and during boot
>all sorts of stuff is displayed.  Even after boot, some commands,
>like 'ls' spew data to the port.
>
>Currently, I'm running Linux 1.0.4; but this phenomena was present
>in 0.99 pl 10, too.
>
>Is this an undocumented feature for hardware debugging?  :-)

No; it's an not-well-documented feature for dealing with buggy hardware.

Well, okay, there are warnings about accessing certain I/O ports too
quickly, but a problem arises finding a way to enure you don't do
that.  After playing with jumps (to flush the instruction pipe), short
loops, and so on, Linux settled on using an access to port 0x80 as a
way to force a small delay.  Because it is widely used by BIOSes for
displaying POST results, it is unlikely to be used by anything else
that will blow up on the access, and because the POST needs to be seen
off-chip, even future highly-integrated chip sets that might incorporate
other peripherals (timers, DMA controller, interrupt controller, whatever)
on a single chip (likely resulting in drastic reductions in the time to
access) are unlikely to spoof this one, so it will force a slow ISA bus
access.

The disk drivers use it particularly heavily, but it's used all over the
place.
-- 
        -Colin

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: SCSI NCR drivers
Date: 14 Jun 1994 20:41:10 GMT

In article <2tkfep$pln@linus.mitre.org>,
John G. Wagner <jwagner@mental.mitre.org> wrote:
>
>Anybody heard anything about when the drivers for the PCI/SCSI NCR chip
>is going to be ready? 

No, because there hasn't been an announcement as to the release date,
and won't be one since there's no way to accurately estimate the amount
of time it will take to finish debugging and what else will come up 
(like moving, sister's highschool graduation, week long business 
trips, etc).

>a month ago it was this month

This month is only half over :-) 

>any update on the release date? 

Nope.  I finally have more time to spend on the driver, and probably
put in more hours on it last night than I had in the last two 
weeks combined, and fixed a lot of nasty bugs, but they're not quite 
ironed out yet.

Of course, if Novell were to actually sell a Linux derrived product,
hire us developers, and let us work full time on fixing our toys 
rather than fixing BASIC compilers like we do at our day jobs, 
things might happen a lot faster.

-- 
Drew Eckhardt drew@Colorado.EDU
1970 Landcruiser FJ40 w/350 Chevy power
1982 Yamaha XV920J Virago

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Why is Linux writing to Port 0x80?
Date: 14 Jun 1994 20:43:51 GMT

In article <2tkqs0INN2hi@vision.uccs.edu>,  <news@vision.uccs.edu> wrote:
>Hi,
>I have a POST-card (Power On Self Test) installed in my Linux-box;
>it decodes and displays data written to port 80H, and during boot
>all sorts of stuff is displayed.  Even after boot, some commands,
>like 'ls' spew data to the port.

More acurately, device I/O accesses port 0x80.  Port 0x80 is an
undefined port according to PC standards, and can be used to create
short delays needed for timing purposes, ie in the IDE driver where
reading/writing certain ports too fast causes data corruption on some
machines.

-- 
Drew Eckhardt drew@Colorado.EDU
1970 Landcruiser FJ40 w/350 Chevy power
1982 Yamaha XV920J Virago

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

From: doug@netcom.com (Doug Merritt)
Subject: Re: A means of networking through Firewalls
Date: Tue, 14 Jun 1994 19:21:43 GMT

In article <timd.771031132@extro> timd@extro.ucc.su.OZ.AU (Tim Docker) writes:
>Either way the connection mechanism should be transparent to the client
>programs so standard clients could be used (ftp, telnet, Mosaic etc).

I'm 90% done with a potential solution, although it requires recompilation
of the clients. We use "socks" to relay requests through our firewall,
but programs that use socks can't do *local* requests. This is the
aspect of it that I'm fixing (currently Mosaic works but ftp doesn't).

If you don't need to use those clients to access local machines, then
the generic socks package should work. Recompilation is needed in order
to e.g. "-Dconnect=Rconnect" etc. The socks daemon runs on the host
that can talk to the internet, of course.
        Doug
-- 
Doug Merritt                            doug@netcom.com
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow

Unicode Novis Cypherpunks Gutenberg Wavelets Conlang Logli Alife HC_III
Computational linguistics Fundamental physics Cogsci SF GA VR CASE TLAs

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

From: jdc@garnet.msen.com (Jon D. Cardwell)
Crossposted-To: comp.os.linux.help,comp.os.linux.admin
Subject: No Networking w/ Kernel > v1.1.12
Date: 15 Jun 1994 00:34:36 -0400

I've been using Linux kernel 1.1.12, and recently went to 1.1.19.
I also fetched and installed the route program from
ftp://ftp.funet.fi/pub/OS/Linux/PEOPLE/Linux, but now, even
after I've set up my route correctly, I can't telnet or FTP
from one machine to another on a local LAN. I can ping OK
from one machine to the other, but nothing else works...

I'm clueless. Can anybody help me out here?

-Jon Cardwell

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

From: gkm@magilla.cichlid.com (Greg McGary)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: Tue, 14 Jun 1994 16:45:29 GMT

David Kastrup (dak@messua.informatik.rwth-aachen.de) wrote on 12 Jun 1994 07:17:09 GMT:
> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:

> >g++ 2.5.x is broken, ask the OI folks...  Supposedly the current development
> >snapshot works properly; let us hope they release it before they break it
> >again...  For that matter, bugs in g++ 2.4.x aborted an attempt to make a C++
> >Linux kernel some time ago.
> 
> As far as I remember OI discussions on various threads, the problem with
> g++ was that when a derived class redeclared some overloaded function,
> all overloaded functions of same name but different arguments from
> base classes were ignored in that class.
> 
> Now while this might be a nuisance for OI compiling, it is proper ANSI
> behaviour.
> 
> However, this is just from hearsay, and I will not guarantee that this
> was the only problem, or at all a problem. It is just what I recollected
> in the back of my head. Others might be more competent to tell.

I was one of the first to discover gcc-2.5.7's dislike for OI.  As I
recall, there were two major problems:

1) The OI headers are by default stored in /usr/include/OI.  g++ 2.5
   introduced the behavior that *all* files included from the
   /usr/include hierarchy have extern "C" linkage by default.  The
   peculiar way this broke was that at compile time (not link time, as
   you would expect) the argument-signatures were ignored, so
   perfectly valid intra-class function overloads got errors.  This
   is obviously possible to work around by moving the header hierarchy
   to /usr/g++-include, and Warner Losh did so.

2) The killer bugs had to do with pointers to member functions.  There
   were numerous places in OI that were valid ANSI, but caused g++ to
   give compile errors.  (I don't have the examples in front of me.  If
   anyone really cares, I can dig them up.)  This prevented the OI
   libs from being compiled with 2.5.x.  My OI *application* code
   happened to compile just fine with 2.5.x, but I couldn't link it
   with the 2.4.5 compiled OI libraries because
   sizeof(<pointer-to-member-function>) changed from 4 to 8, causing
   misalignment of OI runtime bindings.

--
Greg McGary          (804) 361-1665          gkm@cichlid.com
   (ask me for information about intentional communities)

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Wed, 15 Jun 1994 05:03:49 GMT

In article <1994Jun12.203822.15133@unlv.edu>,
Frank Lofaro <ftlofaro@unlv.edu> wrote:
>The IDE performance patch has a serious security hole!  ANY USER can
>set the multiple mode and irq unmasking if they have access to the
>drive. Even if it is ONLY READ-ONLY access to one partition.
>
>I have a Seagate 1239A (a total piece of crap), and a Samsung drive.
>The Samsung works fine with the IDE patch, but the Seagate trashes
>file systems badly if ANY IDE performance features are enabled. Now if
>a user has even read-only access to any partition on /dev/hda (the
>Seagate), they can trash all the filesystems there. NOT GOOD.
>
>I think putting an suser() check on the setting ioctls would be the
>best solution.

Nope.  There are two changes that really need to be made to make this
"correct" in my eyes:

1.  If the performance patches are designed to affect entire drives,
    then that is clearly the granularity you want for the activation
    mechanism.  Thus, for this patch, you should be able to turn
    on/off multiple mode for a drive *only* by accessing the device
    that refers to the entire drive.  This would allow you to make
    the individual partitions accessible for whatever reasons you'd
    need.

2.  "Read-only" access to a device means just that: you can read
    attributes, data, etc. from the device, but you can't make any
    changes to either the status or the data.  Changing a device
    to multiple-mode should thus require write access to the device,
    since that's an attribute change.

These two changes will allow the system admin almost complete
control over who gets the ability to change a device to multiple
mode, which is a much better solution than requiring that the user
have root permissions (or that the program be suid root, which has
the potential for vast security risk).


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

From: rick@sjsumcs.sjsu.edu (Richard M. Warner)
Subject: Re: re: Linux CD
Date: Tue, 14 Jun 1994 21:39:45 GMT

In article <acc-corp.1121973500A@tigger.jvnc.net> acc-corp@tigger.jvnc.net (Robert Wolf) writes:
>From: acc-corp@tigger.jvnc.net (Robert Wolf)
>Subject: re: Linux CD
>Date: Tue, 14 Jun 1994 09:24:20 GMT
>There are about a dozen Linux CD's:
>
>The ones that I know of and can recommend include:
>
>-Yggdrasil Plug and Play Linux
>-Infomagic 2 CD Set.
>-Transameritech
>-Morse Telecommunications Linux Quarterly

Add the Walnut Creek CD-ROM "Toolkit for Linux" - it has an installable
Slackware tree, and snapshots of sunsite and tsx-11.

>The ones we know very little about include:
>
>-Jana

Did they ever ship after the spate of mini-disasters?  After a 
series of apologetic messages, they quit sending me e-mail.

>All three of Yggdrasil, Transameritech and Snow feature the ability to run
>Linux from the CD, although it runs slowly as a result of CD interface
>limitations.

Actually, it is not bad from a good double or triple speed drive.  It
is painful on a single-speed drive - very painful.

- Rick Warner
  Network Manager

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

From: Mitchum DSouza <m.dsouza@mrc-apu.cam.ac.uk>
Subject: Re: loop-2 status?
Date: 15 Jun 1994 05:13:26 -0400
Reply-To: m.dsouza@mrc-apu.cam.ac.uk

| I've tried loop-2 (e.g. for mounting floppy images, NOT the network loopback
| device) with Linux 1.1.19 and the loop patch required a small
| fix in loop.c:
| 
|         current->filp[arg]
| 
| must be replaced by 
| 
|         current->files[0].fd[arg]
| 
| two times. However, this seems not enough. I get messages about "short inode
| reads" when running e2fsck (0.5a) on /dev/loop0. In most cases the filesystem
| will eventually deadlock: every 'df', 'sync', umount of the loop device
| hangs. This last problem occurred in the 1.0 kernel as well but much
| less frequently and only under special conditions.
| 
| Does anyone know the status of the loop device?
| 
| Thanks in advance,

The loop device has been modularized (i.e. a loadable module) and updated for
newer kernels (as a kernel patch) and can be found at

        tsx-11.mit.edu /pub/linux/BETA/loop/lo.3.1.tar.gz

Please report any problems.

Mitch

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

From: bkpipa@eos.ncsu.edu (BRIAN KEITH PIPA)
Crossposted-To: comp.os.linux,alt.os.linux,comp.os.linux.help,comp.os.linux.misc
Subject: Help installing PAS under Linux
Date: 14 Jun 1994 23:23:58 GMT
Reply-To: bkpipa@eos.ncsu.edu (BRIAN KEITH PIPA)



I am running Linux and have been trying to get the PAS to work with it. I tried
recompiling the kernal and it almost worked. When I installed the PAS
under DOS it worked. I used the same DMA and IRQ settings during the configurati
on
for the Linux kernal. It asked about 5 different cards - what am I supposed
to answer for cards I don't have? I put in the PAS IRQ and DMA and I put
the IRQ and DMA dfor the SB emulation.

When I compiled it seemed to work, but when I froze after saying this:


snd3 <Pro Audio Spectrum 16d rev 191> at 0x388 IRQ 7 DRQ 3
snd2 <Sound Blaster 2.0> at 0x220 IRQ 5 DRQ 1
snd6 <Souind Blaster 16 2.0> at 0x220 IRQ 5 DRQ 6


The IRQ and DMA for the PAS under DOS was set at 7 and 3 and
the IRQ and DMA for the SB emulation was 5 and 1


Anyone been through this before?
Please help!!!

Thanks!
Brian


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

From: cs5121@ccub.wlv.ac.uk (J.A.Dennison)
Subject: Smalltalk (GNU)
Date: 15 Jun 1994 11:03:00 +0100

        Help, I know it's out there some where.. but where ?
        Can some one give me an ftp site for the GNU version
        of smalltalk, either the new alpha ver 1.2 or the older
        version 1.1

        Ta muchly



                        DaVe....

        
        
-- 
Jim.

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

From: 9208033h@levels.unisa.edu.au (MATTHEW TIPPETT)
Subject: RARP Under Linux
Date: 15 Jun 94 00:34:57 +0930

Hi...

I am wondering if anyone can give me concise information on how to use
RARP under Linux.   The questions i need answered are :

        Which Kernel do I need ? ( >1.1.13 I assume)
        How do I get a machines IP at boot time ?

Replies Via EMAIL ONLY please.

Matt
--
WWW ref under construction...

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

From: wjb@fep47.com (Bill Buie)
Subject: dosemu/ET4000 help wanted
Date: 13 Jun 1994 14:15:49 GMT
Reply-To: wjb@fep47.com


I am running version Linux 1.0.8 on the hardware configuration below.  If
I try to run dosemu version 50p11, I get the following error,
 
        (wjb)$ dos
        SCREEN saves at: 0x115000
        debug flags: -a
        debug flags: -vsdDRWkpiwghxmIEc
 
which from the release notes I presume is related to me having an ET4000
video card.  On the other hand, I can't build dosemu version dosemu0.51
(with or without pre51_17), which I presume is because I don't have the
latest linux kernal available (it's using a VIF_MASK #define that isn't
declared anywhere on my system).
 
So:
 
        Is there a dosemu out there that will run on my current OS/HW
        configuration?  If so, where can I get it?
 
        If not, where can I get whatever I need to have dosemu/Linux
        running on my current HW?

My hardware:
 
        386SX/33
        ET4000 video w/ 1MB RAM
        16MB RAM
        200 MD HD
 
All help is appreciated.
 
                --Bill

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: SCSI NCR drivers
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Wed, 15 Jun 1994 06:06:41 GMT

In article <2tkfep$pln@linus.mitre.org>,
John G. Wagner <jwagner@mental.mitre.org> wrote:

>Anybody heard anything about when the drivers for the PCI/SCSI NCR chip
>is going to be ready? a month ago it was this month, any update on the
>release date? I have a new Pentium system just waiting to get Linus on it
                                                               ^^^^^
>but I can't load it without the drivers.

Yeah, but is Linus "just waiting: to get on your Pentium?  One suspects he's
not quite *that* much ... erm, um ... *interested* ... in computers.

:-) :-) :-)



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


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