Subject: Linux-Development Digest #858
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, 25 Jun 94 22:13:04 EDT

Linux-Development Digest #858, Volume #1         Sat, 25 Jun 94 22:13:04 EDT

Contents:
  Re: more breakage under 1.1.21 (rlogin xterms freeze up until being reset) (Hubert Weikert)
  Re: Wine-940620 (John Richardson)
  Re: Problems with kernel 1.1.20 and UltraStor 24f EISA SCSI host adapter (Caleb Epstein)
  Re: Disk-compression for Linux (Kevin B. Fluet)
  bad blocks (richard)
  Linux-3D-package (Ben-Lumumba Kheir)
  Re: Need help with gcc/ncurses under 99pl15 (Dennis Heltzel)
  NFS file locking: writing or porting 'lockd' (dave sims)
  Re: IDE PERF. PATCH SECURITY HOLE (Richard Hodson)
  Re: Runtime compilation and execution (Robert Andrew Ryan)
  Re: more breakage under 1.1.21 (rlogin xterms freeze up until being reset) (Malcolm Reeves)
  Re: linux-1.1.20 breaks dosemu0.52 - Some suggestions (James B. MacLean)
  Re: linux-1.1.20 breaks dosemu0.52 - Some more thoughts :-) (James B. MacLean)
  Re: 1542C & PAS 16 problem (Ed Pendzik)
  Re: Major device number clash (iCS) (Matthias Urlichs)

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

From: weikert@salyko.cube.net (Hubert Weikert)
Subject: Re: more breakage under 1.1.21 (rlogin xterms freeze up until being reset)
Date: 25 Jun 1994 17:11:28 GMT

David Barr (barr@pop.psu.edu) schrieb:
> [ removing Distribution: na ]
> In article <2uf0na$qe0@salyko.cube.net>,
> Hubert Weikert <weikert@salyko.cube.net> wrote:
> >'make clean' isn't sufficient, .depend files are not removed.  You
> >should use 'make mrproper' to clean up all, especially if you step up to
> >a new patchlevel. 

> I never understand why people insist on using "make mrproper" when
> upgrading kernels.
> I've been using "make dep;make zlilo" (or whatever) and it works fine.
> It saves a _lot_ of time, compared to a full rebuild.

Your are wrong, especially when, for example, config.in is changed.
A complete rebuild isn't always necessary, but it is the best way to
receive a konsistent kernel.

Hubert
--
Hubert Weikert    DB1MQ    weikert@cube.net
CIS: 100034,374  weikert@muninn.sta.sub.org 


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

From: jrichard@cad1.uml.edu (John Richardson)
Subject: Re: Wine-940620
Date: 23 Jun 1994 20:25:03 GMT




   Sorry should have said kernel is 1.1.21
   Nick


The 1.1.2x kernels break wine.  I'm not sure of the reason, perhaps
if someone sees Bob they could ask him?  :)

I noticed some changes in the singal handling and ldt changes as well
in the 1.1.19 -> 1.1.20 patch.  

Wine still works with 1.1.19.

John Richardson
jrichard@cs.uml.edu     http://www.uml.edu/~jrichard

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

From: cae@cae.ny.jpmorgan.com (Caleb Epstein)
Subject: Re: Problems with kernel 1.1.20 and UltraStor 24f EISA SCSI host adapter
Date: 22 Jun 1994 15:58:32 GMT

Anders Hedborg (ahe@elixir.e.kth.se) wrote:

| This is probably allready well known by now but as there are perhaps not so 
| many of us using the UltraStor 24F EISA SCSI adapter - I thought I might 
| as well post.

| I'm having problems with v1.1.20 and my UltraStor 24f.

[ ... excerpt from /var/adm/messages deleted ... ]

        Have you been able to use your 24F with earlier kernels with
success?  The UltraStor driver was indeed changed in 1.1.20 (or .19, I
forget), to extend the size of the scatter-gather list for the 24F
host adapter to 33 entries (it was 16).

        Just as a test, you might try changing the constant
ULTRA24F_MAX_SG (I think thats the name - grep through the file
drivers/scsi/ultrastor.h for MAX_SG) from 33 back to 16 and recompile
your kernel.  If this fixes the problem then you can stop here.  Send
me email if that is indeed what happens.

        I have a 24F and my system works fine with the larger
scatter-gather list size (the 24F tech specs say the list supports up
to 33 entries).  I patched the driver to support the larger size after
testing it on my system, but it may cause problems for others so I
would like to hear what your results are.

--
[ cae@jpmorgan.com ][ Caleb Epstein ][ JP Morgan & Co. Incorporated ]

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

From: kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet)
Subject: Re: Disk-compression for Linux
Date: 22 Jun 1994 15:55:43 -0600

phil@zeus.fasttax.com (Phil Howard) writes:

>vinter@cs.uit.no (Brian Vinter) replies to what
>kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet) writes:

>>What is this about compression is proved unreliable ? I have seen high school
>>kids PROVE that compression is 100% reliable. 

My personal experiences playing with compression over the last few years
have made me VERY wary of it.  I have lost backed up files on all kinds of
platforms because of bit errors, etc.  I know at least 3 people who lost their
entire DOS FS due to that stupid Stacker (or whichever package it was).  I
have lost compressed binaries under Linux with gzexe.  

...
>>utilities, I'd claim that the unreliability comes from lack of compability
>>with existing applications - not from the compression. So if the compression
>>was included in the kernel it should be as reliable as any other FS. 

How is that?  What if the implementation in the KERNEL wasn't quite up to
the job?  Just because it is in the Kernel doesn't automatically make it
work perfectly with all the other parts of the kernel.  New technology (I
mean new to Linux here) takes a while to stabilize.  Remember the xiafs file
system?  I know at least 2 people locally who asked me what to do when they
lost their entire file system.  Of course the answer was "Switch to e2fs."
Xiafs was (still is) in the kernel.

>Well he did say "unreliability of compressed FILE SYSTEMS".  Hopefully he
>knows that it is not the compression theory itself that is faulty.

I guess I should have said 'less reliable' rather than 'unreliable'.  

And, yes, you do have to weigh the costs involved.  If you can't afford
$1/MB for the storage you need, you will have to take the risks of loss and
be willing to put up with the lost time in un/recompressing files.  

I, for one, can't afford to take the risk of losing a partition due to a
compression error.  No matter what you like to believe about compression, it
DOES add another level of complexity to the system, and therefore decreases
the overall reliability.

Of course, compression has it's place.  Like I said, I might try it on a
news spool (if I lose a couple days of news, I don't think anybody would
really even notice).  I use compression to back up files to tape
(compressing individual files with afio, NOT the whole thing with tar -cz
which is BAD news).  I have also played with gzexe (the executable
compressor that comes with GZIP).  After losing too many executables to it,
I gave up.

-- Kevin

============================================================
Kevin Fluet                WorldGate Public Access Internet
fax: (403) 444-7720         kevin@worldgate.edmonton.ab.ca      
email info@worldgate.edmonton.ab.ca for rates and other info

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

From: rpritz@phantom.com (richard)
Subject: bad blocks
Date: 22 Jun 1994 21:27:13 GMT

does linux test for bad disk sectors on installation or disk formating? 
when i installed it (current version), it did not say it was marking bad 
blocks.  freebsd and os/2 both find bad sectors on my harddrive.  linux 
crashes, the other two don't, and i thought this may be the reason.

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

From: ben@cc.univie.ac.at (Ben-Lumumba Kheir)
Subject: Linux-3D-package
Date: 25 Jun 1994 18:42:24 GMT






Hallo,
J'm interresting to find any 3D software for Linux 1.0.
Please. if you know something about it, e-mail:ben@wsks.cc.univie.ac.at

Best regards,
Ben Lumumba Kheir
--
********************************************************************************@ My address:Kheir Ben Lumumba                                                 @
@           Schloeglgasse 10/1/1                                               @
@           Austria                                                            @
@ Tel.:(0043)1-804-18-29                                                       @
@ Fax.(0043)1-83-73-885                                                        @
@ Internet:ben@wsks.cc.univie.ac.at                                            @
******************************************************************************** 

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

From: dheltzel@crl.com (Dennis Heltzel)
Subject: Re: Need help with gcc/ncurses under 99pl15
Date: 23 Jun 1994 13:24:07 -0700

It sounds like BSD curses is still around somewhere. Try executing find:

find / -name curse* -print | more

Then track down each reference and make sure it is ncurses. I did that 
and it fixed errors similar to yours.

Dennis



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

From: sims@usa.acsys.com (dave sims)
Subject: NFS file locking: writing or porting 'lockd'
Date: 23 Jun 1994 14:07:18 -0600

Hi again.  We have a few Linux boxes here at work connected by a
network running NFS.  We need to lock and unlock NFS mounted files.
Unfortunately, the lock daemon 'lockd' that resides on Suns doesn't
exist on Linux.

So, my choices for Linux NFS file locking basically are: (1) port or
write 'lockd' for Linux or (2) write an out-of-band locking mechanism.

My company maintains eight computer installations around the country
consisting of Suns and PCs running Windows.  My employer is seriously
looking at replacing the Suns by Linux boxes.  However, we need some
sort of file locking.

So, I just might write or port lockd to Linux.  QUESTION: Any ideas on
where sources or specifications to 'lockd' could be found?

Anyone else interested in writing 'lockd' for Linux?  Since my
employer is interested in it, I could be available to work on it full
time.  Any other suggestions?

thanks in advance,
dave sims
-- 
Dave Sims                                       PGP encryption key available
Internet:  sims@usa.acsys.com                   on my home page.
WWW:       <A HREF="http://cnn.acsys.com:5050/dave.html">my home page</A>

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

From: richard@radar.demon.co.uk (Richard Hodson)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: Thu, 23 Jun 1994 20:19:20 +0000

Eberhard Moenkeberg (Eberhard_Moenkeberg@p27.rollo.central.de) wrote:

: 5 years warranty and a MTBF longer than the rest of my life is
: nothing special today, but they give it, too.

I am sure I saw some small print somewhere saying that the MTBF of
Seagate drives is measured continuously running under cleanroom
conditions (ie controlled moisture & dust in the air).  The failures I
have had with Slowcrates were due to me being foolish enough to switch
them off, and when I switched on again the heads had stuck to the
platters :-(

--
Richard Hodson                          |  richard@radar.demon.co.uk
:1,$s/DOS/anal secretion from hell/g    |  rhodson@cix.compulink.co.uk

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

From: Robert Andrew Ryan <rr2b+@andrew.cmu.edu>
Subject: Re: Runtime compilation and execution
Date: Sat, 25 Jun 1994 14:16:53 -0400

Excerpts from netnews.comp.os.linux.development: 25-Jun-94 Re: Runtime
compilation and.. Donald Jeff Dionne@ee.ry (987)

> Steven Hugg (hugg@xi.cs.fsu.edu) wrote:
> : Well, la-dee-daa!!! Looks like the data segment is executable after all.
>                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^

> Unless I misunderstand what I'm reading, The Design Of the UNIX Operating
> System (Bach, Prentice Hall) says that should be a protection fault.....
> In my interpretation, a segment fault.  Am I wrong, or does the 
> memory management of the i386 not allow for detection of this?

Most unices I've encountered allow execution of code from the data
segment.  I would have to go on a killing spree if this didn't work
under Linux.  (Unless of course I could still use mmap to map memory as
executable :-)

-Rob

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

From: reeves@strata.usask.ca (Malcolm Reeves)
Subject: Re: more breakage under 1.1.21 (rlogin xterms freeze up until being reset)
Date: 25 Jun 1994 19:41:58 GMT

: > I never understand why people insist on using "make mrproper" when
: > upgrading kernels.
: > I've been using "make dep;make zlilo" (or whatever) and it works fine.
: > It saves a _lot_ of time, compared to a full rebuild.

: Your are wrong, especially when, for example, config.in is changed.
: A complete rebuild isn't always necessary, but it is the best way to
: receive a konsistent kernel.

I thought I could get away with make dep; make zImage and it worked fine for
me from 1.1.13-1.1.19. Then 1.1.20 failed. I had to start from scratch 
because the patches were not applied correctly. make mrproper; make config;
make dep; make clean; make zImage everytime - saves time in the end. It's
usually best to set the terminal scrollback to some huge line count and
run the rebuild when you go home :-)

--
==============================================================================
Malcolm Reeves, Geological Engineering, University of Saskatchewan, Saskatoon,
SK, S7N 0W0 aka reeves@rocky1.usask.ca aka reeves@dvinci.usask.ca
==============================================================================

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

From: jmaclean@fox.nstn.ns.ca (James B. MacLean)
Subject: Re: linux-1.1.20 breaks dosemu0.52 - Some suggestions
Date: 25 Jun 1994 21:32:18 -0300

In article <Cry437.D75@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:
>From: rob@pe1chl.ampr.org (Rob Janssen)
>Subject: Re: linux-1.1.20 breaks dosemu0.52
>Date: Sat, 25 Jun 1994 09:09:07 GMT

>In <2ufv7m$ri@sun0.urz.uni-heidelberg.de> mrex@indigo0.urz.uni-heidelberg.de (Martin Rex) writes:

>>Mike Heidt (heidt@mikey.jsc.nasa.gov) wrote:
>>> I also had problems with dosemu0.52 and linux 1.0.20. Dosemu would report no
>>> problems, then blank the screen and hang. I was using an ATI ultra 
>>> mach 8 card. I replaced the mach 8 with an et4000 card and everything
>>> works fine, so I conclude that the problem is in the video drvers. The
>>> mach 8 was hanging during execution of the onboard bios. Turning graphics
>>> off worked mostly, but no cursor. I would like to go back to the mach 8
>>> if the problem ever gets fixed because it is faster in X windows. BTW, the
>>> mach 8 worked fine in dosemu0.49.

>>The reason your ATI Ultra was not working might be the video ports it
>>is using.  I had the same problem with my ATI Graphics Ultra, so I enabled
>>port debugging and traced what ports where accessed.  With the following
>>line dosemu-0.52 and linux-1.1.19 works just as good as dosemu-0.49 did.

>>ports  { 0x1ce 0x1cf 0x238 0x23b 0x23c 0x23f 0x9ae8 0x9ae9 0x9aee 0x9aef }

>Actually, there is indeed a problem like that in the new dosemu.  On
>an Olivetti M400-40 at work it just crashes the system when starting, no
>matter what I do with ports, BIOS, etc.
>The only way to get around that is to comment-out the "video" line in
>the config file, causing it to just use stdin/stdout.  Of course there
>are no attributes and colors anymore, then.
>This worked okay in 0.49, just as in the original poster's case.

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


Sorry I'm late getting into this one :-(. Can I suggest 2 things:

1) Since some SIG's seem to have been modified in the later kernels, please
   always recompile DOSEMU after recompiling the 1.1.20 kernel if it was 
   working in prior kernels.
2) If you are unable to get your video card working, and have had it working
   in prior versions of dosemu, or have it working in its most simplistic 
   form 'video { VGA chunks 3 }', please (pretty please) send to me a debug 
   with all debugging on, like:

   dos -D+a 2>debug

   for a second or 2. This file will get quite huge, and should be 
   gzip|uuencoded prior to being sent.

An another note, IPC is being used for HMA, and EMS at this time, and 
definitely should be compiled into your kernel.

Thanks for the feedback, please continue :-),
JES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James B. MacLean                    jmaclean@fox.nstn.ns.ca
Department of Education
Nova Scotia, Canada (902) 424-8438

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

From: jmaclean@fox.nstn.ns.ca (James B. MacLean)
Subject: Re: linux-1.1.20 breaks dosemu0.52 - Some more thoughts :-)
Date: 25 Jun 1994 21:34:14 -0300

Oh ya :-):

1) Make sure video and bios shadowing are OFF for testing graphics stuff.
2) If your video bios is at E000, you can configure it in /etc/dosemu.conf 
   to properly notice that :-)

Take it easy, but take it,
JES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James B. MacLean                    jmaclean@fox.nstn.ns.ca
Department of Education
Nova Scotia, Canada (902) 424-8438

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

Crossposted-To: comp.os.linux.help
From: edp@pt.com (Ed Pendzik)
Subject: Re: 1542C & PAS 16 problem
Date: Sat, 25 Jun 1994 21:29:51 GMT

does this work under dos? I have a pas16 and I remember reading
in the troubleshooting section of the pas16 manual that MV noticed
a problem with this under dos. their fix (for dos) is to change the 
line in config.sys to:

device=c:\aspi4dos.sys /N5 /F11

this changes the on and off ISA bus timings for the dos 
equivilent of aha1542.c (the host adapter driver) to off time 11/16 millisec
and on time 5/16 millisec. make the on time smaller than the off time.
page 73 pas16 install man.

If you know what you are doing, you should be able to 
go into aha1542.c, find and change the values for on time and off time.

Regards,
Ed Pendzik

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Major device number clash (iCS)
Date: 25 Jun 1994 22:03:26 +0200

In comp.os.linux.development, article <1994Jun24.121744.3447@dcs.warwick.ac.uk>,
  Nick.Holloway@dcs.warwick.ac.uk (Nick Holloway) writes:
> 
> On the other hand, two separate files with _just_ the major information,
> and without the headings would be simpler to deal with.  If you want fancy
> headings, run the program (c.f. "cat /proc/net/route", vs "netstat -r").

That was my primary reason.

Granted that it's rather easy to deal with the one fine; just use sed and
possibly awk if you want to separate the info. If nothing else, it makes
sense to report unknown devices to the user, and IMHO it's helpful to tell
them whether the device is a block or character thingie -- if all else
fails, create a device with minor number zero and see what happens.

NB: Maybe MAKEDEV should be able to call /etc/makedev/foo scripts if
    devices for the "foo" driver should be created.

> Agreed.  I think allocating top-down is a better solution.  I think
> this is going to be more important as more things become distributed as
> loadable modules.
> 
There are also some drivers, like the SCSI block drivers or the console
TTY drivers (we need them for booting, so it makes no sense at all to move
them) which are hardcoded for a reason. Dynamically allocating a different
device in their place and thus killing the boot process is a no-no.

Most drivers, however, are not, and the only reason they hardcode their
number is the nonexistence of a MAKEDEV which guarantees that their device
entries are where they are supposed to be in case a new kernel with a
different configuration is booted.

> One modification that needs to be done to MAKEDEV would be to _remove_
> devices.  Otherwise, you could load a module and create world accesable
> devices for it, the later the same device major number could be re-used,
> allowing unprotected access.  Thus, there will be "MAKEDEV -d device".
> 
Good point.

> One piece of information that I am woefully short of is the names
> currently used to register drivers.  If you are the developer of a driver,
> please let me know so it can be added to MAKEDEV.
> 
So, everybody type "cat /proc/devices|mail Nick.Holloway@dcs.warwick.ac.uk".
 ;-)

-- 
We are not a loved organization, but we are a respected one.
               --John Fisher
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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


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