Subject: Linux-Development Digest #119
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 4 Sep 94 19:13:07 EDT

Linux-Development Digest #119, Volume #2          Sun, 4 Sep 94 19:13:07 EDT

Contents:
  How to boot 1.1.49 ? (E. v. Pappenheim)
  Re: XFree & CDROM slow down transfer rate (Rob Janssen)
  Re: XFree & CDROM slow down transfer rate (Rob Janssen)
  Re: PRIORITY make an undelete command (Robert Murray - MARCO North American)
  Re: sb_dsp_operations undeclared 1.1.46 (Sam Gentile)
  Re: sb_dsp_operations undeclared 1.1.46 (Sam Gentile)
  Re: Acid (was: Simple acid test) (Richard L. Goerwitz)
  Re: Future of linux -- the sequel (Larry Pyeatt)
  Re: LMSI CDrom (Andrew Wilson)
  A patch to allow setting EGA/VGA screen border color (Lou Sortman)
  Problem in zBoot/misc.c with Kelvin 64 (Martin Oldfield)
  Re: PRIORITY make an undelete command (Bill C. Riemers)
  Re: Future of linux -- the sequel (Bill Broadley)
  Re: polled ports (Rob Janssen)
  Re: Future of linux -- the sequel (Rob Janssen)

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

From: [email-masked] (E. v. Pappenheim)
Subject: How to boot 1.1.49 ?
Date: Sat, 3 Sep 1994 18:42:38 GMT

Hi,

I tried to boot mye freshly compiled 1.1.49 kernel, and get a message
saying something like 

-- Unknown Compression --- 

System halted

My lilo is 0.14 and the lilo.conf lokks like this:

delay=50
install=/boot/boot.b
vga=normal
compact
root=/dev/hda2
read-only

image=/zLinux-1.1.49

image=/zLinux-1.1.47
  label = current

image=/zLinux-1.1.19
  label = stable

other=/dev/hda1
  label=dos

1.1.47 boots fine. What am I missing?

Thanks in advance,
Eckebrecht
-- 
================================================================================
   Eckebrecht von Pappenheim                    Email:     [email-masked]
   Eleonorenstr. 17                             Phone:     +49 511 443755
   30449 Hannover                               Modem/Fax: +49 511 444060
   Germany                                                             

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

From: [email-masked] (Rob Janssen)
Subject: Re: XFree & CDROM slow down transfer rate
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 11:05:16 GMT

In <[email-masked]> [email-masked] (Robert Stockmann) writes:

>BTW I test the transferrate by doing:
># time dd if=/dev/sda1 of=/dev/null bs=32k count=128

>Robert Stockmann

That is not a good test, and it explains your problem.
You should transfer more that the physical memory you have, to get
a realistic transfre rate.  Now that you transfer only 4M, you will
be measuring the speed of transferring from the cache.  Once you have
started X, there is less room for the cache and your rate decreases.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: XFree & CDROM slow down transfer rate
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 11:35:30 GMT

In <[email-masked]> [email-masked] (Rob Coursey) writes:

>Robert Stockmann ([email-masked]) wrote:
>: When running XFree and using a cdrom device I notice
>: that the transfer rate of my scsi disk slows down.
>: normally I get 5.6 Mbyte/sec but under X11 when /dev/sr0 is accessed
>: or has been accessed the transfer rate goes down to 500 to 700 kbyte/sec..
>: Is this normal? Is there a fix? (Hardware or Software?)
>          ------                   --------
>: my system:
>: HP 486 EISA 25 MHz
>: 12 Mb RAM, cache on 486 chip, memory burstmode is accessed
>: by external chip on moherboard (HP design)
>: Adaptec 1740 SCSI-II controller (enhanced mode)
>: FUJITSU Fast SCSI-II disk  Model: M2624F-512        Rev: 0405
>: TOSHIBA Fast SCSI-II cdrom Model: CD-ROM XM-3401TA  Rev: 0283 (external)
>: ESDI controller with Micropolis 150 Mb ESDI disk 
>: ATI Graphics Ultra PRO EISA (2Mb VRAM)

>actually the problem is not w/ the software, it's with the hardware...
>since the CD's run so much slower than the HD's the chatter on the line when
>using both together (installing from CD, or copying from CD to HD) will
>bring the overall performance (noticable on the HD activity since it is so
>much faster) down to the 5-6MB transfer rate.  The only solution I've come
>up w/ is to install a second SCSI controller to maintain 'other' devices
>like tapes and CD's while leaving the original controller to work the HD's.
>(it became very noticable when building and maintaining Novell servers for
>large corporations (which is what I do for a living :))

When your "slow devices" actually transfer the blocks of data reasonable
fast, and disconnect between the transfers of such blocks of data, there
should be no problem.  Of course, assumed that your SCSI controller and
all devices support disconnection, and the driver supports multiple
outstanding commands.  Maybe some of your equipment or software was not
in that category...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Robert Murray - MARCO North American)
Subject: Re: PRIORITY make an undelete command
Date: 4 Sep 1994 13:14:00 -0400

David Herron ([email-masked]) wrote:
: I'm going to toss out an idea that's been floating around my head
: for a few months.  Unfortunately it will require a file system
: change in order to implement.

: When you unlink(2) a file (the last time) one would change the action.
: Rather than free all the blocks and deallocate the inode the inode
: should be placed on a chain of freeable inodes.  When the file system

: The only downside I can think of is the file system might end up
: more fragmented than it is now.

:       David

 I don't see how this is much diff than moveing rm files to a temp dir.  Then
cleaning the dir with a cron command. Cron can also look for the file system
getting full and rm files from the trash dir. This work for me. Some care in
use of the rm command and mv the files to a tmp dir and I have not lost to many
important things. :-) 

  But I think a unrm command would be worth something.

 Just my $0.02

  Robert Murray
  [email-masked]

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

From: [email-masked] (Sam Gentile)
Subject: Re: sb_dsp_operations undeclared 1.1.46
Date: Sun, 4 Sep 1994 12:42:35 GMT

I did get the file originally from sunsite.unc.edu as 
linux-1.1.46.tar.gz. No patches. It should have included everything. I 
wonder if it has something to do with config (allthough I answered the 
sound questions I think correctly for sb pro).

Thanks,
sam

-- 
============================================================================
Sam Gentile                     Mitakuye Oyasin - All My Relations
[email-masked]               Live in balance with Mother Earth and
[email-masked]                 all of Creation
=============================================================================

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

From: [email-masked] (Sam Gentile)
Subject: Re: sb_dsp_operations undeclared 1.1.46
Date: Sun, 4 Sep 1994 12:48:17 GMT

Yes, that's it! It now asks me for the soundblaster settings. Thanks so 
much!!!

Sam

-- 
============================================================================
Sam Gentile                     Mitakuye Oyasin - All My Relations
[email-masked]               Live in balance with Mother Earth and
[email-masked]                 all of Creation
=============================================================================

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

From: [email-masked] (Richard L. Goerwitz)
Subject: Re: Acid (was: Simple acid test)
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 18:00:29 GMT

[email-masked] (Joachim Schrod) writes:

>Perhaps you should differentiate between multilingual (can work with
>many languages/scripts at once) and internationalized (can work with
>an arbitrary but fixed language/script at one given instantiation).
>
>In our work this distinction has shown to be very proficient. And the
>literature on I18N actually often mean the latter thing.

This really does make sense.  In my muddled way of thinking, though,
supporting multilingual features (e.g. wide or multi-byte characters,
multiple scripts/wordwrap directions, and so on) is one of the best
ways to lay a foundation for internationalization.

-- 

   -Richard L. Goerwitz              [email-masked]
   [email-masked]          rutgers!oddjob!ellis!goer

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

From: [email-masked] (Larry Pyeatt)
Subject: Re: Future of linux -- the sequel
Date: 4 Sep 1994 18:50:08 GMT

In article <[email-masked]>, [email-masked] (Donald Becker) writes:
|> >                                    $6400 minumum
|> 
|> That's just way more than a reasonable Linux box will cost.

Define "reasonable."  I defined reasonable to be "something similar to
SGI Indy.  You can't get that sort of performance with cheap parts.

|> That's true.  I think the new SGI full motion thumbnail video is a really
|> great toy, and their demo is amazing.  If I wanted to do that kind of video
|> work, I would get an SGI.  But for many other kinds of work the Linux system
|> would do as well or better, and be much less expensive.

If I wanted to do any floating point, I would also want the SGI, since
it puts Pentium to shame.  Which brings us back to my main point, which
is that a Linux system with a non-Intel processor would be a "good thing."

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

From: [email-masked] (Andrew Wilson)
Subject: Re: LMSI CDrom
Date: 4 Sep 1994 19:39:45 GMT
Reply-To: [email-masked] (Andrew Wilson)

   I've taken Kai Petzke's lmscd 0.3 driver and I'm adding audio support to
it. It still only works with the CM205/CM250 combination, but given enough
information about the CM206 and the CM205MS I may be able to adapt it.

   No, I don't know when any of this will be done -- hopefully within a
month. 

-- 
                   Andy Wilson -- [email-masked]
     "From the sublime to the ridiculous is but a step." -- Napoleon 
               "Ying tong iddle i po!" -- Spike Milligan
                     #include <std_disclaimer.h>

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

From: [email-masked] (Lou Sortman)
Subject: A patch to allow setting EGA/VGA screen border color
Date: 4 Sep 1994 19:33:35 GMT

I have written a patch to allow setting the color of the screen
border on EGA/VGA text displays.  Even though it is only ~3.5K
in size, I hesitate to post it here.  How should I go about
releasing it so as not to disturb kernel development much?
It would be nice to get it included in the official kernel.

Here are the comments from the patch:

# This is a patch to the Linux kernel console driver to add the capability of
# setting the border color on EGA or VGA displays.  I saw somewhere that seting
# the border color is an extension of setting the text foreground and
# background colors; ie: ^[[5xm instead of ^[[3xm and ^[[4xm.

# So it is implemented here.

# Resetting the terminal sets the border color to be the same as the text
# background color.  In order to be able to use this feature, you must
# put the entry ':rs=\Ec:' somewhere in /etc/termcap.  Then you will
# be able to set the border color to the background color by invoking
# the following command:
#    setterm -reset

# You can explicitly set the border color to the background color
# (without resetting the terminal) by using ^[[59m.
--
[email-masked] (Lou Sortman)       for(i=0; i<3; i++) puts(
                                                  "Janet!    Dr. Scott!   \n"
                                                  "Janet!    Brad!        \n"
Whoever dies with the most LEGO wins.             "Rocky!    <Uh!>        \n");

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

From: [email-masked] (Martin Oldfield)
Subject: Problem in zBoot/misc.c with Kelvin 64
Date: 04 Sep 1994 20:45:34 GMT

I've recently installed linux on a PCI machine with Neptune chipset
and Orchid Kelvin 64 PCI graphics card. The boot process hangs in the
puts & scroll subroutines from zBoot/misc.c which directly poke stuff
into the video-memory. Turning both subroutines into null-functions
i.e. inserting a 'return' at the top, disables the 'Uncompressing
linux...' message but lets the system boot.

Other diagnostics are unaffected.

This is probably a flaw in the card - similar crashes have been seen
with DOS's EDIT command.

Cheers,
--

Martin Oldfield, MRAO, Cavendish Labs, CAMBRIDGE, CB3 0HE
Work:  0223 337365 Fax: 0223 354599 Home: 0223 67940
Beelzebub had the devil for a sideboard. - Queen

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

From: [email-masked] (Bill C. Riemers)
Subject: Re: PRIORITY make an undelete command
Date: 1 Sep 94 03:34:57 GMT
Reply-To: [email-masked]

>>>>> "Mark" == Mark A Horton KA4YBR <[email-masked]> writes:

    Mark> John Henders ([email-masked]) wrote: : In
    Mark> <[email-masked]> [email-masked] (Rob
    Mark> Janssen) writes:

    Mark> : >Did you never erase a file later on the day that you
    Mark> : Isn't that what rcs is for?

    Mark>               BRAVO!
        
    Mark>       Yes, John... too bad most of the people screaming for
    Mark> an undelete function have never worked in a real software
    Mark> development environment that used rcs or sccs or some other
    Mark> package for revision control.  And before the flames start
    Mark> about uncessary complexity and being "too difficult to deal
    Mark> with," I say bull!  If set up properly, a revision control
    Mark> system is almost invisible to the end user (the programmer
    Mark> in this case!)  One should learn and explore the tools at
    Mark> hand before screaming for others "just like they're used
    Mark> to".... One has to wonder if these same people still use
    Mark> edlin under DOS or have taken the bold steps necessary to
    Mark> master the newer "edit" editor!

I agree, that one should learn about the tools available before 
worrying about something new.  But, as an rcs fan, I have to say
this is really a case of comparing apples seeds and oranges.  I for one
am always testing at least one ALPHA version program at any given
time, which occassionally bite by things like destroying files...
"rcs" is a high level program.  While I agree "rcs" is very usefull
it is no replacement for a low level recovery command.  Your
argument is equally absurd to the argument that NFS is uneccissary
because Ange-ftp works so beutifully.  Admittedly, I can get 95% of
the same functionality from Ange-ftp that I want, but that doesn't
mean it would be worth someones time to try to get NFS working over
term.

To be honest, I've already decided it would be worth my while to
write an "unrm" command, but I probably won't get around to it
for about a month or so.  In the mean time, maybe I'll luck out
and either some good ideas will come from this thread, or
even better someone will write a program before "unrm" makes it
to the top of my "ToDo" list.

                                 Bill

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

From: [email-masked] (Bill Broadley)
Subject: Re: Future of linux -- the sequel
Date: Sun, 4 Sep 1994 20:53:19 GMT

: If I wanted to do any floating point, I would also want the SGI, since
: it puts Pentium to shame.  Which brings us back to my main point, which
: is that a Linux system with a non-Intel processor would be a "good thing."

Hmm this hypothetical SGI indy with the same price/performance as a 
p-100 with 512k cache with 1.0 GB disk and 32 MB ram for about $5,000.

The only indy I've seen with better fp then a p-100 is:
SGI IndyR44  R4400     75/150 1M+16/16      88.1  96.6 Jan94 c.s.sgi.anno

I suspect it cost substantially more then a 32 MB ram, 17" color, 1.0 GB
p-100 system.

The sgi 4[046]00 at 100,133 mhz has less specfp then the p-100 which is 
probably the majority of indy's out there.

Since p-90 motherboards are getting cheaper by the day, as are the cpu's I 
suspect it will be tough to find a better price/performance motherboard for 
awhile.

But once there is a motherboard with > p-100 performance and costs less
and runs linux I'd imagine it will become very popular.

Not sure if that will be a 601-100, an alpha 200 mhz, a 4600-150, a 
4400-200, or 604 will be the first, but I'll be waiting.

--
Bill Broadley           [email-masked]           UCD Math Sys-Admin
Linux is great.         Bike to live, live to bike.                     PGP-ok

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

From: [email-masked] (Rob Janssen)
Subject: Re: polled ports
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 21:52:52 GMT

In <[email-masked]> [email-masked] (Harry C Pulley) writes:

>Thanks to people here I can now run with polled ports.  But, even with just a
>1200baud mouse connection it doesn't work very well.  Under X it is barely
>usable but under dosemu it is totally useless.

I told you that

>Are there any known improvements to the polling code?  1200 baud shouldn't be
>too fast...

It polls 100 times per second, the timer-interrupt rate.  So 1200 baud
is already slightly too fast for this mode.
It could be usable with 16550A chips, but they have other problems when
used with a mouse.  Therefore they are disabled below 2400.

It is better to listen to the rest of the world, and somehow move your
IRQs or use a board which can share IRQs.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: Future of linux -- the sequel
Reply-To: [email-masked]
Date: Sun, 4 Sep 1994 21:56:27 GMT

In <[email-masked]> [email-masked] (Larry Pyeatt) writes:

>In article <[email-masked]>, [email-masked] (Donald Becker) writes:
>|> >                                   $6400 minumum
>|> 
>|> That's just way more than a reasonable Linux box will cost.

>Define "reasonable."  I defined reasonable to be "something similar to
>SGI Indy.  You can't get that sort of performance with cheap parts.

Hey come on, he explained how all prices that added up to that $6400
were way above current street-price for PC parts.

When you thing SGI is the only way to go, why bother with a Linux
newsgroup?

BTW...  there was a nice inside-story from within SGI posted on a
Linux group some time ago.  It's unfortunate that I did not keep a copy...
It expressed quite a different opinion on the Indy...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

** 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: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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