Subject: Linux-Development Digest #774
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, 28 May 94 18:13:05 EDT

Linux-Development Digest #774, Volume #1         Sat, 28 May 94 18:13:05 EDT

Contents:
  Re: How to print faster (David - Foulds)
  Re: Troubles with patches (Robert G. Smith)
  Re: SIGHUP - Deep Kernal Guts question! (Christian Henry)
  Re: Linux/SCO compatibility? (Charles E Meier)
  Re: NCR53C830 (Drew Eckhardt)
  Re: Bug in linux 1.1.16 (Cameron N. Heide)
  Re: 1.1.15 breaks SCSI (Rob Janssen)
  Re: 32-bit Novell desktop OS combines Unix, DOS 7 (Rob Janssen)
  Re: InterLink for Linux (Rob Janssen)
  Re: Troubles with patches (Rob Janssen)
  Re: How to print faster (Rob Janssen)
  Re: Linux/SCO compatibility? (Brandon S. Allbery)
  Re: Kernel change summaries (Richard Hodson)
  Re: 1.1.13 (or later) with > 16M? (Andrew R. Tefft)

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

From: foulds@shell.portal.com (David - Foulds)
Subject: Re: How to print faster
Date: 28 May 1994 05:01:05 GMT

rob@pe1chl.ampr.org (Rob Janssen) writes:

>In <2s353s$c06@news1.svc.portal.com> foulds@shell.portal.com (David - Foulds) writes:

>>The printer driver lp.c seems to need a longer busy-loop,
>>at least on my machine (486-SX33) and with my printer
>>(Panasonic KX-P4410 laser with 2.5MB).  The busy loop
>>that waits to send the next char in lp_char_interrupt
>>only counts to 3 before giving up.  I increases the count
>>to 30 or so (and also increased LP_BUFFER_SIZE to 2048)
>>and reduced the time to print ghostscript 200K raster
>>files (or whatever you call them) i.e. images of postscript
>>pages after having been ghostscripted from 4 minutes to 50 seconds.
>>This was while crunching the postscript in another process.
>>On an empty machine the time per page went from 80 seconds 
>>to 40, cpu utilization from 90% to 30% or so.

>It looks like you are talking about a different version than is
>in the kernel now.
>Anyway, the current version allows tuning of these parameters to the
>requirements of your printer and CPU speed using the program "tunelp",
>without modifying lp.c

>Rob

"tunelp" does indeed tune some parameters (by the way, the most
recent version on sunsite is from 3 July 1993, so I am up to
date this time) but it doesn't tune the parameter I am talking
about.  The spin loop I refer to is at the top of the function
lp_char_interrupt and doesn't look like a loop; it has the
form (a || a || a) where a is a condition based on the printer
status.  Tuning the parameter I think you are talking about,
which controls two other spin loops in the same function before
and after strobing the strobe line, doesn't help (I tried).

I disown all originality, as usual; I got the idea in the midst
of serious thumb-drumming (while waiting for my printer)
from the device-driver book by Pajori.

Cheers, David


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

From: rob@bip.anatomy.upenn.edu (Robert G. Smith)
Subject: Re: Troubles with patches
Date: 28 May 1994 05:03:52 GMT

Elaine Walton (ewalton@magnus.acs.ohio-state.edu) wrote:
: I decided to try my hand at compiling one of the "bleeding-edge" kernels.
: I have done builds before using some pretty shaky software, but this one
: stumps me:

: I downloaded 1.1.13 and tried to compile it.  I got an undefined variable
: in sbpcd.c (one of the switch-statement constants).  I posted a message
: for help here, and got a message that my problem was that I didn't have
: 1.1.14.  Okay, I downloaded patch14 AND patch15.  I would have downloaded
: a full 1.1.14 but none was available on tsx-11 (and sunsite had no current
: kernels at all--as far as I could find).  I was suspicious of the patch
: and looked at it--it had the wrong directories.  I set up the directories
: they way it expected then ran the patch.  All went okay.  I 'configged a
: kernel and compiled.  The compiler complained that I didn't have a
: particular .h file.  So, I ran the patch15.  I compiled and got an unknown
: variable.  Am I supposed to get the 1.1.16?  Is there one?

Occaisonally a new patch has an error that prevents even a
complete compile and link.  This is what happend with 1.1.13,
but is not the usual case (usually errors aren't so obvious).

If you get the unmodified 1.1.0 from 

  ftp.funet.fi:/pub/OS/Linux/PEOPLE/Linus/v1.1

this is mirrored at e.g.:

  linuxftp.caltech.edu:pub/Linux/Linus/v1.1

and if you get all the patches (from same site:dir,
latest is 1.1.16) into a directory, you can get a working 
source code by:

     cd /usr/src/linux  (or whatever your source tree is called)
     zcat patchdir/patch{?,1?}.gz |  patch -p1

The "-p1" removes the first level directory so prevents problems
with the top dir of the source tree being called the wrong name.

Make sure the proper symbolic links are made in /usr/include
for "asm" and "linux":

        asm -> /usr/src/linux/include/asm
        linux -> /usr/src/linux/include/linux

Once these are made correctly they need not be redone for
each new patch level.

Any other errors from missing ".h" files must mean something
else is missing from your /usr/include directory.

All the kernels from 1.1.6 to 1.1.16 have compiled for me fine,
except 1.1.13...

This works, reliably!

Rob Smith


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

From: henryc@reality.UUCP (Christian Henry)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 27 May 1994 23:39:05 -0400
Reply-To: henryc@io.org

In article <2rtcac$7rs@paperboy.osf.org>,
Dan Swartzendruber <dswartz@pugsley.osf.org> wrote:

>>    >4.  Applications rely on POSIX-compliant systems to not send a SIGHUP.
>>    >      True.  Programmers assume their environment will always be POSIX
>>    >      and don't bother to trap for SIGHUP.  And then their programs
>>    >      bomb unexpectedly when they're ported to non-POSIX systesm.
>>    >      That's bad programming.
>> 
>>    I had been under the impression that almost all mainstream systems are
>>    either POSIX or shooting for POSIX as soon as possible... This is the
>>    first time I have heard somebody imply it is bad programming to shoot
>>    for POSIX complience, should we look for things that all non-POSIX
>>    systems do?  It seems like a waste of a standard to me...
>> 
>> You're correct, the vast majority of mainstream systems are POSIX
>> compliant.  To say that it is bad programming style to write application
>> programs to be POSIX compliant boggles the mind.....
>
>I think you're both misreading his statement.  He didn't say it is
>bad to write your programs to be POSIX compliant, he said it is bad
>programming to write your programs assuming they will always run on
>a POSIX-compliant platform.  There's a world of difference, as I'm a
>few minutes of thought will show...

Is there a world of difference?  If there is, are we to assume that it's
also bad practice to assume that programs created for ANSI-C-compliant
compilers won't always be compiled on ANSI-C-compilant compilers?

A few minutes of thought on your behalf might not be such a bad idea
either...  A programmer would have to be _incredibly_ lacking in brain cells
to create programs which make assumptions about what _might_ occur in the
future.  Or, perhaps, were you thinking about those features which have
never become standardized (such as BSD signal handling, etc.), and (no
doubt) never will (for some _very_ good reasons)?

-- 
 |  Christian Henry   //   North York, Ontario   |  e-mail:  henryc@io.org  |
 |      ``Read my lips, I don't care what you say...''  - Sacred Reich      |

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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: Linux/SCO compatibility?
Date: 28 May 1994 19:31:25 GMT

In article <23f_9405281911@idn.nl>,
Kevin Spousta <Kevin.Spousta@f0.n100.z61.fidonet.org> wrote:
>From: d00n@crash.cts.com (Kevin Spousta)
>Organization: CTS Network Services (CTSNET/crash), San Diego, CA
>Date: 25 May 94 16:44:48 GMT

>--
>| This msg is brought to you via IDN Internet Gateway (idn.nl)
>| Internet: Kevin.Spousta@f0.n100.z61.fidonet.org
>|
>| Standard disclaimer: The views of this user are strictly his own.
>

Deja-vu all over again.  Would someone please fix their USENET/Fidonet
gateway so that it doesn't repost articles to USENET that have already 
appeared on USENET.  Its a bit rude to make sites pay for articles twice.

(Note: Kevin Spousta isn't responsible for this.  A repost of his article 
was just the tenth in a series of these and the one that I am using to 
alert whoever is responsible for the broken gateway (idn.nl?)). 

Thanks,

cem

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: NCR53C830
Date: 28 May 1994 06:23:03 GMT

In article <2s4a81$jps@ugle.unit.no>,  <amund@itk.unit.no> wrote:
>Do anyone have any information about the availability
>of a driver for NCR53C830 SCSI chip used for PCI
>SCSI controllers ?

It's not.  

It's a nifty parallel programming problem that has some
inherent debugging complexities which, along with various 
time constraints, the author being evicted (Okay, technically
it wasn't an eviction, but a three day notice for compliance
with the lease or to surrender the property to the landlords),
etc, certain bugs haven't been worked out.

>(Or enough information about it to enable a mere mortal to
>write one ? )

Trust me, you don't want to do that.
-- 
Drew Eckhardt drew@Colorado.EDU
1970 Landcruiser FJ40 w/350 Chevy power
1982 Yamaha XV920J Virago

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

From: heide@ee.ualberta.ca (Cameron N. Heide)
Subject: Re: Bug in linux 1.1.16
Date: 28 May 1994 20:56:12 GMT

[snip]
>net/net.o: Undefined symbol _dev_init referenced from text segment
>net/net.o: Undefined symbol _net_bh referenced from text segment
>make: *** [tools/zSystem] Error 1

I had the same problem too, even though I'm pretty sure my source
tree was clean.  The problem seems to be that net/socket.c calls
dev_init in net/inet/dev.c, which only gets compiled and linked in
when you answer yes to CONFIG_NET.  (I'm not sure about net_bh, since
fixing the first error fixed the second as well :-)

The simple fix seems to be to take the Makefile in net/inet and
remove the section that creates a dummy inet.o file when CONFIG_NET
is not defined.  The following patch should work as a quick fix:

--- /archive/linux/net/inet/Makefile     Sat May 28 14:58:57 1994
+++ linux/net/inet/Makefile     Tue May 24 17:50:31 1994
@@ -42,17 +42,8 @@

 endif

-ifdef CONFIG_NET
-
 inet.o:                $(OBJS)
                $(LD) -r -o inet.o $(OBJS)
-
-else
-
-inet.o:
-               echo | $(AS) -o inet.o
-
-endif

 dep:
                $(CPP) -M *.c > .depend

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.1.15 breaks SCSI
Reply-To: pe1chl@rabo.nl
Date: Sat, 28 May 1994 09:31:10 GMT

In <2s573j$4a@renux.frmug.fr.net> rene@renux.frmug.fr.net (Rene COUGNENC) writes:

>This is what is shown with all previous kernels, (I never had any problem
>since the Adaptec 1542 is supported by Linux):

>--------------------------------------------------------------------------
>Calibrating delay loop.. ok - 4.34 BogoMips
>Configuring Adaptec at IO:330, IRQ 11, DMA priority 5
>scsi0 : Adaptec 1542
>scsi : 1 hosts.
>  Vendor: FUJITSU   Model: M2622F-512        Rev: 0404
>  Type:   Direct-Access                      ANSI SCSI revision: 01 CCS
>Detected scsi disk sda at scsi0, id 0, lun 0
>scsi0 : reseting for second half of retries.
>  Vendor: MICROP    Model: 1624-07MZ1077801  Rev: HZ2P
>  Type:   Direct-Access                      ANSI SCSI revision: 01 CCS
>Detected scsi disk sdb at scsi0, id 1, lun 0
>scsi0 : reseting for second half of retries.
>scsi : detected 2 SCSI disks 0 tapes 0 CD-ROM drives total.

You have apparently always had some kind of trouble...
I don't think it is normal that you get the "scsi0 : reseting for second
half of retries." message every time!  At least it does not happen on
my system (with 1542 as well)

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

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 32-bit Novell desktop OS combines Unix, DOS 7
Reply-To: pe1chl@rabo.nl
Date: Sat, 28 May 1994 09:32:29 GMT

In <NELSON.94May27132012@crynwr.crynwr.com> nelson@crynwr.crynwr.com (Russell Nelson) writes:

>In article <1994May26.124452.11394@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes:
>   In article <NELSON.94May25141928@crynwr.crynwr.com> nelson@crynwr.crynwr.com (Russell Nelson) writes:
>   >You don't understand -- Corsair is a desktop system, not a server
>   >system.  It's IPX support is going to be as a client, not a server.
>   >You'll still need your netware server.

>   Russ - NCP the layer the client would need to talk is a Novell trade secret
>   and fairly well guarded. If they give out a client source it'll only be a
>   month before someone knocks out a clone server (at least for file services)
>   as it is it might take 6 months to deduce from documents and ethernet traces

>It's already been done -- Puzzle Systems has NetWare server software
>that runs on various Unix machines.

Is that a clone, or is it a licensed implementation of 'portable netware'?

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

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: InterLink for Linux
Reply-To: pe1chl@rabo.nl
Date: Sat, 28 May 1994 09:38:07 GMT

In <940527163549@lambada> steve.mcmahon@lambada.oit.unc.edu (Steve McMahon) writes:

>Has anybody written for linux something like DOS' InterLink? In DOS,
>you can connect two computers by a NULL-modem cable and network them
>using InterLink (i.e. access hard and floppy drives of one as if it
>were a local drive). This is very convenient for laptops.

>So I'm wondering, has it been done for linux? If not, is there anyway
>I can access the drive of a computer connected by a NULL-modem cable?
>I realize one could use a comm program, but it's not the same. I'd
>like to install things on my laptop using the CD-ROM of the desktop.

It is a standard feature of the networking software.
Setup a link using SLIP, CSLIP or PPP (serial ports), or PLIP (parallel ports)
and you can connect two systems by a serial or parallel cable.
Then you can just NFS-mount anything both ways.

>Can FreeBSD do that?

Serial: yes
Parallel: I don't know

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

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Troubles with patches
Reply-To: pe1chl@rabo.nl
Date: Sat, 28 May 1994 09:48:40 GMT

In <2s5t8e$2ma@charm.magnus.acs.ohio-state.edu> ewalton@magnus.acs.ohio-state.edu (Elaine Walton) writes:

>I decided to try my hand at compiling one of the "bleeding-edge" kernels.
>I have done builds before using some pretty shaky software, but this one
>stumps me:

>I downloaded 1.1.13 and tried to compile it.  I got an undefined variable
>in sbpcd.c (one of the switch-statement constants).  I posted a message
>for help here, and got a message that my problem was that I didn't have
>1.1.14.  Okay, I downloaded patch14 AND patch15.  I would have downloaded
>a full 1.1.14 but none was available on tsx-11 (and sunsite had no current
>kernels at all--as far as I could find).  I was suspicious of the patch
>and looked at it--it had the wrong directories.  I set up the directories
>they way it expected then ran the patch.  All went okay.  I 'configged a
>kernel and compiled.  The compiler complained that I didn't have a
>particular .h file.  So, I ran the patch15.  I compiled and got an unknown
>variable.  Am I supposed to get the 1.1.16?  Is there one?

Did you patch it the correct way?

Do it like this:

        cd /usr/src
        rm -rf linux
        tar xzf your-base-version-file.tar.gz
        zcat first-patch.gz | patch -p0 -s
        zcat second-patch.gz | patch -p0 -s
        ... etc
        cd linux
        make config
        make dep
        make zlilo

Of course, the rm and tar are only needed if you don't already have
a correctly installed version.  Right now, assume you don't.
There should be no output from the commands, any error messages probably
mean you are trying to patch out-of-sequence.

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

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: How to print faster
Reply-To: pe1chl@rabo.nl
Date: Sat, 28 May 1994 12:20:14 GMT

In <2s6j6h$rf9@news1.svc.portal.com> foulds@shell.portal.com (David - Foulds) writes:

>rob@pe1chl.ampr.org (Rob Janssen) writes:

>>In <2s353s$c06@news1.svc.portal.com> foulds@shell.portal.com (David - Foulds) writes:

>>>The printer driver lp.c seems to need a longer busy-loop,
>>>at least on my machine (486-SX33) and with my printer
>>>(Panasonic KX-P4410 laser with 2.5MB).  The busy loop
>>>that waits to send the next char in lp_char_interrupt
>>>only counts to 3 before giving up.  I increases the count
>>>to 30 or so (and also increased LP_BUFFER_SIZE to 2048)
>>>and reduced the time to print ghostscript 200K raster
>>>files (or whatever you call them) i.e. images of postscript
>>>pages after having been ghostscripted from 4 minutes to 50 seconds.
>>>This was while crunching the postscript in another process.
>>>On an empty machine the time per page went from 80 seconds 
>>>to 40, cpu utilization from 90% to 30% or so.

>>It looks like you are talking about a different version than is
>>in the kernel now.
>>Anyway, the current version allows tuning of these parameters to the
>>requirements of your printer and CPU speed using the program "tunelp",
>>without modifying lp.c

>>Rob

>"tunelp" does indeed tune some parameters (by the way, the most
>recent version on sunsite is from 3 July 1993, so I am up to
>date this time) but it doesn't tune the parameter I am talking
>about.  The spin loop I refer to is at the top of the function
>lp_char_interrupt and doesn't look like a loop; it has the
>form (a || a || a) where a is a condition based on the printer
>status.

Interesting...  apparently the printer delays quite a while before it
releases busy after sending the ACK.
The PC parallel port interrupt design is braindead, in that it sends an
interrupt before the device is ready for more data.  This has been noted
before, and the use of interrupts for the printer is often avoided.
Note that spinning a while at this point will cost you CPU time and will
probably bring increased interrupt latency on other interrupts, which could
cause trouble on serial ports.  It would be a good idea to tune this parameter
very carefully, and even better to construct some hardware solution.
(the ACK from the printer should somehow be gated with BUSY so that the
interrupt only arrives when the printer is ready for new data)

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

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Linux/SCO compatibility?
Date: Sat, 28 May 1994 21:06:11 GMT

In article <308_9405281912@idn.nl>, Brandon.S..Allbery@f0.n100.z61.fidonet.org (Brandon S. Allbery) says:

(a lot of stuff from a week or more ago)

Looks like we've got another buggy FidoNet gateway online :-(  Someone who
knows how please tell thenm how to fix it...

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

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

From: richard@radar.demon.co.uk (Richard Hodson)
Subject: Re: Kernel change summaries
Date: Sat, 28 May 1994 21:42:21 +0000

Whistler (slouken@cs.ucdavis.edu) wrote:

:       Thanks! :)

Seconded! Makes reading the patches Soooo much quicker.


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

From: teffta@cs690-3.erie.ge.com (Andrew R. Tefft)
Subject: Re: 1.1.13 (or later) with > 16M?
Date: Sat, 28 May 1994 21:27:45 GMT

In article <CqH58q.DH2@cs690-3.erie.ge.com>,
Andrew R. Tefft <teffta@cs690-3.erie.ge.com> wrote:
>I have been using 1.0 and upgraded to 1.1.13 in order to get caught
>up on the ppp stuff.
>
>I was unable to boot, with a crash coming after the "honours the
>WP bit" message. I found that I could boot if I limit the kernel
>to the lower 16M.

After trying many things, I noticed a parameter in my BIOS called
"memory remapping" which was enabled. I turned it off and everything
worked fine!

My motherboard manual says that this option can't be used with more
than 1M ram. For one reason or another, I had ignored that, probably
because I thought that it was being auto-configured because previous
kernels worked.

At any rate, this option sucks up a few hundred K, which is nothing
compared to 32M ram and a much better sacrifice than external cache.


-- 

Andy Tefft               - new, expanded .sig -     teffta@cs690-3.erie.ge.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
******************************
