Subject: Linux-Development Digest #41
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:     Thu, 18 Aug 94 23:13:16 EDT

Linux-Development Digest #41, Volume #2          Thu, 18 Aug 94 23:13:16 EDT

Contents:
  Looking for color ls source. (Paul Walker)
  Re: screensaver halts my machine (vaz)
  Re: NFS errors (David Fox)
  Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload. (Paul Southworth)
  Re: Suggest:SCSI Tape File System (Angelo Haritsis)
  Re: Kernel panic in 1.1.44 (David Dyer-Bennet)
  Re: too many kernel patches? (Heiko Herold)
  Re: Objc+linux+gcc=link error? ..... (Joe Zbiciak)
  Re: Future of Linux (H. Chad Lane)
  Re: Socket Timeouts in Linux 1.1 (Hans-Georg von Zezschwitz)
  Re: Where to get RCS (Alan McIvor)
  Re: Where to get RCS _source_ (Mark P. Nelson)
  Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload. (Dave Tweten)
  Re: Future of Linux (Tom Ford)

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

From: paul@Malcolm.camosun.bc.ca (Paul Walker)
Subject: Looking for color ls source.
Reply-To: paul@malcolm.camosun.bc.ca
Date: Wed, 17 Aug 1994 23:39:07 GMT


Slackware has a color version 'ls' from the GNU fileutils 3.9.

Does anyone know where the source is?  I wish to port it to a Sun.



--
  |)
 /|_    P A U L   W A L K E R
((|,)   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ~|~    paul@malcolm.camosun.bc.ca    COMPTEC92100@CAMOSUN.BC.CA
  |     


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

From: vaz@sharps.astro.wisc.edu (vaz)
Subject: Re: screensaver halts my machine
Date: 18 Aug 1994 15:49:45 GMT
Reply-To: vaz@sharps.astro.wisc.edu (vaz)

In article <32qcd7$dpn@kruuna.Helsinki.FI>, torvalds@cc.Helsinki.FI (Linus Torvalds) writes:

|> The usual reason why the screen blanking can fail is that the screen
|> blanking routines use long-word accesses when copying the screen memory
|> to kernel memory (and back) when doing the screen save and restore
|> operations.  And it should work perfectly ok on a good graphics card:
|> but there have been a few reports of it failing - mostly due to bad
|> hardware timings that make the bus confused when moving data that fast. 
|> 
|> Note that if you get this every time it blanks, you might get it when
|> scrolling too: the scrolling routines ordinarily just set the screen
|> origins to move the image on the screen, but they have to do a "hard
|> scroll" ever once in a while.  The memory accesses are different in this
|> case, though (scr->scr rather than scr->mem or mem->scr), so that may be
|> why it seems to work for you. 
|> 
|> Anyway, what you may test is to do the screen blank/unblank with a
|> slower routine that uses word-wide accesses for copying instead of the
|> current "memcpy()" (which will do the long-word copies).  Look in
|> linux/drivers/char/console.c, notably the get_scrmem() and set_scrmem()
|> functions.  You might want to change the "memcpy()" into "memcpy_video()",
|> and write your own memcpy_video() something like this:
|> 
|>      void memcpy_video(unsigned short * to, unsigned short * from, int count)
|>      {
|>              do {
|>                      *to = *from;
|>                      to++; from++;
|>                      count -= 2;
|>              } while (count > 0);
|>      }
|> 
|> That *might* help. 
|> 
|> If it does help, please mail me saying so (and include this article just
|> as a reminder of what I said - I try to keep as little state around in
|> my head as possible)
|> 
|>              Linus
|> 
|> PS.  The above is not tested, and you may have to work on it a bit.  It
|> should give you enough to go on, though. 
|> 
|> 

I tried it and it didn't work :-( And I'm sure that I'm running the
new kernel, with the modifications suggested above (I've done make zlilo).
I believe that this problem with the screensaver is related to the other
problem I have, that NO graphics applications (including X) can be run
under LINUX in my machine, which has the unfortunate combination: PARADISE
video card, WD90C33 chipset and PCI BUS. All these graphics applications
halt the machine in the same way as the screensaver. However the scrolling
works fine even with very large files being cat'ed to the screen or in vi
without any problem.

The card works though in DOS/WINDOWS (lemmings, fractint, and the WINDOWS
games freecell, mines, solitaire, tut's tomb, etc.etc.). It is probably
related to the way PCI handles this lower level transactions or even with
the mapping of the video memory by the card.

There must be a solution (I hope :-).

In article <CuMAMC.3K1@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) writes

|> Are you sure that your machine is halted?  Or do you merely have a black
|> screen?
|> Try keying in some command and see if you get disk activity as a result.

Yes, pretty sure! No activity is heard from the disk, the keyboard is
locked (the leds for CAPS-, SCROLL- and NUM-LOCk can change status) and
not even ALT-CTRL-DEL works... only a harsh RESET awakes the machine.

Thanks to your attention!

Luiz Paulo

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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Re: NFS errors
Date: 18 Aug 1994 13:55:36 GMT

In article <Cup9uB.74J@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:
] 
] In <FOX.94Aug16171813@first.cs.nyu.edu> fox@graphics.cs.nyu.edu (David Fox) writes:
] 
] >Following up on my own post, what surprises me is that I don't
] >get parity errors or something from a higher level of the network
] >protocol.  How is this possible?
] 
] Sun's are normally not sending checksums in UDP packets, hence NFS traffic
] is not checksummed.  You can enable this, but NFS will use more CPU.

I've never had a problem with receiving corrupt files
over NFS except under Linux.  It really makes the whole
thing almost pointless.  Any ideas why it might be
happening, and how to stop it?
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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

From: pauls@locust.cic.net (Paul Southworth)
Crossposted-To: comp.unix.bsd,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc,comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.unix.pc-clone.32bit
Subject: Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload.
Date: 18 Aug 1994 16:01:04 GMT

In article <MIB.94Aug18102735@geech.gnu.ai.mit.edu>,
Michael I Bushnell <mib@geech.gnu.ai.mit.edu> wrote:
>In article <jmonroyCuq5J1.Fy8@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes:
>                      Bill and Lynn plainly stated that the code is
>                      freely re-distributable and freely re-modifiably,
>                      *AS ALWAYS*.
>
>                      The CD-ROM and the annotations may *NOT* be placed
>                      on any FTP'able site for redistribution.
>
>Don't these seem just a little contradictory?

There you go, trying to make sense of a Monroy posting.  Shame on you!!
You should know better.

Read what Vixie posted shortly before:  the point is that the code can be
redistributed, but the CD also contains non-redistributable documentation
written by Jolitz, and consequently you can extract the code and put it
up for ftp, but you can't put the whole CDROM on line for public access.

--
Paul Southworth
CICNet Systems Support
pauls@cic.net

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

From: ah@doc.ic.ac.uk (Angelo Haritsis)
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: Suggest:SCSI Tape File System
Date: 18 Aug 94 23:48:25 GMT

Just to extent the very good suggestion:

If it is possible to seek to and write individual blocks on a tape
the filesystem can be made to simulate a disk fs - simply slower.
Of course, I know it is not possible to do seek on all drives or
is it (I have the Wangtek 5525ES scsi and it is and I always wanted
to do something like it but lacked the time...) Do the QIC-80
drives also support seek/tell ?

If this is applicable to only a small amount of drives then probably
it is not worth - but rather easy to implement: just get a disk fs code
and try to midify it accordingly (i know, there are a lot of
special problems to face - ie eliminate motor movement, fragmentation etc)

Just a suggestion ...

Angelo
-- 
#include <standard.disclaimer.h>
 Angelo Haritsis, Applied Systems Section
 s-mail: Dpt of Computing,Imperial College, 180 Queen's Gate, London SW7 2BZ, UK
 e-mail: ah@doc.ic.ac.uk - !!!NEW!!! tel:+44 71 594 8434 - fax:+44 71 589 7127

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

From: ddb@terrabit.mn.org (David Dyer-Bennet)
Subject: Re: Kernel panic in 1.1.44
Date: Thu, 18 Aug 1994 14:03:53 GMT

ludwimax@rubc.rz.ruhr-uni-bochum.de (Martin Ludwig) writes:

>In Kernel 1.1.44 it happens:
> 
>Unable to handle kernel NULL pointer dereference at virtual address c0000246
>current->tss.cr3 = 00101000, %cr3 = 00101000
>*pde = 00102027
>*pte = 00000027
>Oops: 0000
>EIP: 0010:0010e47c
>EFLAGS: 00010002
>eax: 0035bee8 ebx: 00000246 ecx: 00000000 edx: 0003e000
>esi: 0035bee8 edi: 00000001 ebp: 001912dc esp: 001912d4
>ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
>Process swapper (pid: 0, process nr: 0, stackpage=0019038c)
>Stack: 00000000 001a8f5c 00000000 0016678d 0035bee8
>Code: 8b 13 85 d2 74 2e 8b 02 83 f8 02 74 07 8b 02 83 f8 01 75 20
>Aiee, killing interrupt handler task[0] (swapper) killed: unable to recover
>Kernel panic: Trying to free up swapper memory space
>In swapper task - not syncing

>I use this kernel on a 4MB 486SX with 11852k swap (swap partition)
>and the error occures by freeing the swap-space by exiting emacs or
>other programs.

>On my other Linux-Box with 8MB 386/387 with 16600k swap-partition no error
>occures even if swap-space is heavily used! 

I've seen that error (seems to have scrolled off my logs now) and also
this one: 

Aug 17 01:01:43 terrabit kernel: Unable to handle kernel paging request at virtual address 40725b5e
Aug 17 01:01:43 terrabit kernel: current->tss.cr3 = 0031a000, @r3 = 0031a000
Aug 17 01:01:43 terrabit kernel: *pde = 00000000
Aug 17 01:13:00 terrabit kernel: Unable to handle kernel paging request at virtual address 40725b5e
Aug 17 01:13:00 terrabit kernel: current->tss.cr3 = 005e0000, @r3 = 005e0000
Aug 17 01:13:00 terrabit kernel: *pde = 00000000

In my case they occur during long idle periods.  They come in large
groups, and I've usually had to reboot once I get them.  I've got 16
meg of memory and *NO* swap space configured.  I'm not running X; I
only get out-of-memory errors when doing a kernel build with -j 4 (so
I don't do that any more :-) ).

I'm running 1.1.41 with the quota patches.
-- 
David Dyer-Bennet, proprietor, The Terraboard    4242 Minnehaha Ave. S.
ddb@network.com, ddb@terrabit.mn.org              Minneapolis, MN 55406
Don't waste your time arguing about allocating          +1-612-721-8800
blame; there'll be enough to go around.             Fax +1-612-724-3314

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

From: hman@arianna.dei.unipd.it (Heiko Herold)
Subject: Re: too many kernel patches?
Date: 18 Aug 1994 16:33:21 GMT

In article <32tbp0$o8i@csnews.cs.colorado.edu>,
Drew Eckhardt <drew@frisbee.cs.Colorado.EDU> wrote:
>In article <32sck5INN1m12@rs1.rrz.uni-koeln.de>,
>Johannes Rest <rest@IKP.Uni-Koeln.DE> wrote:

[ham!]

>
>If you don't like it, stay with the 'normal' users 1.0.x 
>set of kernels, for which no new features were added and 
>there haven't been any releases for months.  If you also 
>want the new features, wait a month or two for 1.2 based on
>the enhancements in 1.1.x.

One moment - is this just smalltalk, or is there already
a fixed idea out there 'bout the next stable version ?
It happens very often (at least here :) that someone needs a feature of
1.1.x (see quota, iBCS, many things) but can't afford the
problems with the development kernel...IMHO there should be a new
"stable" version, i.e. a trial period ecc like that just before 1.0,
not less often than every 6 months;
having a "stable" version every 6 months may be silly, but otherwise
there's no choice except
normal_version=without_that_*IMPORTANT*_feature and
development_version=yuck!_lets_hope...

Probably this _does_ sound silly but it's true...

Heiko


-- 
\________________/ hman@[paola][chiara][maya].dei.unipd.it \________________/
 DON'T PANIC - The Hitch Hiker's Guide to the Galaxy            {itself}
 PANIC - The Hitch Hiker's Guide to the Galaxy MK II        {Mostly Harmless}
      (perceiving the Whole Sort of General Mish Mash)       [Douglas Adams]

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

From: im14u2c@cegt201.bradley.edu (Joe Zbiciak)
Subject: Re: Objc+linux+gcc=link error? .....
Date: 18 Aug 1994 16:27:02 -0500

In <32u09j$1uh@news.nynexst.com> hjl@nynexst.com (H.J. Lu) writes:

>In article <32qbhi$a3c@winx03.informatik.uni-wuerzburg.de>, rainer@wmax62.mathematik.uni-wuerzburg.de (Rainer Frohnhoefer) writes:

>|> :Shitty.m:16 (Shitty.o): Undefined symbol _objc_msg_lookup referenced from text  

>gcc -Wno-import Shitty.o Shitty_main.o -o shitty -g -lobjc


I dunno... the whole thing sounds rather, uhm, shitty.  ;-)


--Joe


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

From: hcl@dsroc4.dsdoe.ornl.gov (H. Chad Lane)
Subject: Re: Future of Linux
Date: 18 Aug 1994 16:23:13 GMT

In article <32nlom$p3p@solaria.cc.gatech.edu> byron@gemini.cc.gatech.edu (Byron  
A Jeff) writes:
 
> All you'll end up doing is emasculating the OS we know an love by chaining
> more and more restrictions so that it'll look/feel like DOS/Windows/MacOS.

And this is also a very trite argument.  It's analogous to the argument that
a poor sequel or remake of a movie ruins the original -- it doesn't!  If 
Van's ideas are used someday, and you don't like them, the answer is simple:
don't use them.  You have access to the Linux source, so you can make Linux
what you want.  If someone out there is willing to implement the things Van  
suggests and someone wants these types of changes, it would be against
the spirit of Linux to deny this!  

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

From: 1zezschw@rzdspc2.informatik.uni-hamburg.de (Hans-Georg von Zezschwitz)
Subject: Re: Socket Timeouts in Linux 1.1
Date: 18 Aug 94 21:18:32 GMT

thomasc@ATHENA.MIT.EDU (Thomas Wallace Colthurst) writes:

>METHOD #2:  fd_set readfds;  FD_ZERO(readfds);  FD_SET( skt, &readfds );
>            select( 1, &readfds, NULL, NULL, NULL, &tv );
>Problem:  select always waits till the timeout, and then returns 0.


>Am I using either of these methods incorrectly?  Is there another

NO.

The first parameter of count is declared as "count".
You probably guessed that this means, how many different handles have
to be controlled. This is wrong.
It means something like "up to which handle number do I have to look
at? With your parameter 1 it only could have a look at stdin (filehandle
number 0) if it was set by FD_SET, but in your case it looks for nothing.
You should set the first parameter of select to the maximum number of
file handles that can occur in your system.
You can find out the number of file handles like this:

maxFh = ulimit (4, 0);   /* This determines the maximum numbers of handles */
                         (Should remain allways the same till Linus changes
                          it :-)  ) */
select (maxFh,  &readfds, NULL, NULL, NULL, &tv );


Better luck, I had the same problem.

Georg



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

From: alan@auck.irl.cri.nz (Alan McIvor)
Subject: Re: Where to get RCS
Date: 18 Aug 94 20:45:46 GMT

In <zeppelin.777144048@login.dknet.dk> zeppelin@login.dknet.dk (Thomas B. Pedersen) writes:


>Can anyone tell me where to get RCS from? I have tried finding it 
>with archie, but to no avail. Please respond by email.

>Thanks,

>Thomas Pedersen
>zeppelin@login.dkuug.dk

There are compiled versions of 5.6.0 on most of the ftp sites
(sunsite.unc.edu, tsx-11.mit.edu, etc). The source for this is
available on most ftp sites having GNU software. But note that if
you are using gcc 2.5.8, then it won't compile: You need to get
rcs-5.6.7 (a beta release) from ftp.cs.purdue.edu in pub/hammer,
which is the site used by the people who maintain RCS.

Alan

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

From: mpn@AlleleB.Berkeley.EDU (Mark P. Nelson)
Subject: Re: Where to get RCS _source_
Date: 18 Aug 1994 16:57:22 GMT
Reply-To: mpn@alleleb.berkeley.edu

Thomas B. Pedersen (zeppelin@login.dknet.dk) wrote:
: Thanks to those who told me where to get RCS, I already had the binaries.
: I should have asked for the source. Any? Please respond by email.

Done.

--
Mark P. Nelson (mpn@alleleb.berkeley.edu)
                         While I'll admit that anyone can make a mistake once,
                         to go on making the same lethal errors century after
                         century seems to me nothing short of deliberate.--V.

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

Crossposted-To: comp.unix.bsd,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc,comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.unix.pc-clone.32bit
From: tweten@wilbur.nas.nasa.gov (Dave Tweten)
Subject: Re: Report on SVNET: Bill Jolitz's Talk; Mind Overload.
Date: Thu, 18 Aug 1994 21:39:46 GMT

In article <MIB.94Aug18102735@geech.gnu.ai.mit.edu> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>In article <jmonroyCuq5J1.Fy8@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes:
>
>              Second: The issue of code reuse....
>
>                      Bill and Lynn plainly stated that the code is
>                      freely re-distributable and freely re-modifiably,
>                      *AS ALWAYS*.
>
>              Fourth: The CD-ROM
>
>                      The CD-ROM and the annotations may *NOT* be placed
>                      on any FTP'able site for redistribution.
>
>Don't these seem just a little contradictory?

Actually not.  I was at the meeting, and asked about the apparent
contradiction.  The answer is that the code is re-distributable, with
credit, and the "annotations" are not re-distributable at all.  Since
the CD contains both, it can't be put up for anonymous FTP as a whole.

It was also interesting to me that Jolitz said the CD was "in
production", implying herds of gnomes stamping disks, about ready to
ship them.  He even waived around a gold colored prototype CD.  Later,
however, he said that he didn't yet know whether Mosaic would be on the
disk, due to its need for Motif.  That destroyed my fantasy of herds of
gnomes.  He hasn't even decided what will be on the final master yet.
It can't have been recorded.  CD shipment will be a while.

The final revelation to me was how he planned for users to boot directly
off the CD, with no need for a boot floppy.  The actual scheme is:

    1.  Have an Adaptec 154xy SCSI controler, for all values of x and y.
        Also have a Mitsumi CD drive.

    2.  Boot DOS.

    3.  Mount the CD under DOS and run a "boot 386BSD" program off the CD.

Not quite as mysterious and awe inspiring as the first story I heard on
the net.
-- 
===========================================================================
Dave Tweten                                             tweten@nas.nasa.gov
NASA Ames Research Center, M/S 258-5                         (415) 604-4416
Moffett Field, CA  94035-1000                           FAX: (415) 604-4377

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

From: tford@convex.com (Tom Ford)
Subject: Re: Future of Linux
Date: 18 Aug 1994 14:16:52 -0500

In article <CupnwK.DIs@freenet.carleton.ca>,
Michael Stevens <af082@FreeNet.Carleton.CA> wrote:
>
...
>I think that your idea about "small commercialism" in Linux is 
>silly, a number of Commercial products already can run on 
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Linux...spend the money that you saved on buying an os, and 
>buy some apps!
>

I haven't heard this.  Can you give me a list?

Thanks,
Tom Ford
Convex Computer Corp.

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


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