Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest112
2024-02-19 00:24:15 -05:00

672 lines
23 KiB
Plaintext
Raw Blame History

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, 3 Sep 94 12:13:05 EDT
Subject: Linux-Development Digest #112
Linux-Development Digest #112, Volume #2 Sat, 3 Sep 94 12:13:05 EDT
Contents:
Re: mmap( ..., PROT_WRITE, MAP_SHARED, ... ) WHY NOT? (David Miller)
[Q] Multi-session PhotoCD & SCSI (Thomas Quinot)
sb_dsp_operations undeclared 1.1.46 (Sam Gentile)
Re: tar to st0 (Exabyte tape) causes kernel panic (Rob Janssen)
Re: Write-protect floppy hassles (Rob Janssen)
Re: MSDOS FS dates off by 5 days! (Slackware 2.0 bug?) (nozomi@glaucomys.seino.tsukuba.ac.jp)
Re: Future of linux -- the sequel (Bill Broadley)
Re: XFree & CDROM slow down transfer rate (root)
Re: XFree & CDROM slow down transfer rate ("Simon P Allen")
IDE Performance enhancement (Patrick Doyle)
Re: Linux - my first impressions (Kees J. Bot)
Status: PAS16 SCSI driver (Lenny Turetsky)
Re: Which kernel should I get for PPP (Al Longyear)
Re: ext2fs floppy/82077 corruption with 1.1.49 (Chris Smith)
Re: Future of linux -- the sequel (Orc)
dlfcn; dynamic loading (Richard L. Goerwitz)
----------------------------------------------------------------------------
From: davem@er4.rutgers.edu (David Miller)
Subject: Re: mmap( ..., PROT_WRITE, MAP_SHARED, ... ) WHY NOT?
Date: 1 Sep 1994 21:20:02 -0400
Russell Leighton (rrl@access3.digex.net) wrote:
: Writing to mmap'd files does not seem to be supported under Linux:
: mmap( ..., PROT_WRITE, MAP_SHARED, ... )
Correct, this is not implemented as of yet (1.1.pre50 kernel).
Due to some of the bogus parts of the i386 memory management
facilities, an implementation of this is very difficult. Nevertheless
this one of the projects in line for post-1.2.0 kernels, so stay
tuned. Actually if you are somewhat proficient with kernel hacking,
you can take out the checks for this particular situation and what you
are left with almost works! Much of the necessary code is already
there but sanity checked out...
There are ways around this. In particular, right now I am
almost getting and emacs build to work under elf libraries. The first
big problem I ran into was this particular mmap() thing you speak of.
Basically as a work around I did the following.
The origional statement is:
new_base = mmap (0, new_file_size, PROT_READ | PROT_WRITE, MAP_SHARED,
new_file, 0);
I changed that to...
new_base = mmap (0, new_file_size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
new_file, 0);
Then, right before the file descriptor gets closed I do a:
Mailbox is '/usr/spool/mail/davem' with 0 messages [ELM
2.4 PL23]
Mailbox is '/usr/spool/mail/davem' with 0 messages [ELM
2.4 PL23]
Subject: Re: mmap( ..., PROT_WRITE, MAP_SHARED, ... ) WHY NOT?
Newsgroups: comp.os.linux.development
References: <345b07$ari@access3.digex.net>
Distribution:
Russell Leighton (rrl@access3.digex.net) wrote:
: Writing to mmap'd files does not seem to be supported under Linux:
: mmap( ..., PROT_WRITE, MAP_SHARED, ... )
Correct, this is not implemented as of yet (1.1.pre50 kernel).
Due to some of the bogus parts of the i386 memory management
facilities, an implementation of this is very difficult. Nevertheless
this one of the projects in line for post-1.2.0 kernels, so stay
tuned. Actually if you are somewhat proficient with kernel hacking,
you can take out the checks for this particular situation and what you
are left with almost works! Much of the necessary code is already
there but sanity checked out...
There are ways around this. In particular, right now I am
almost getting and emacs build to work under elf libraries. The first
big problem I ran into was this particular mmap() thing you speak of.
Basically as a work around I did the following.
The origional statement is:
new_base = mmap (0, new_file_size, PROT_READ | PROT_WRITE,
MAP_SHARED,
new_file, 0);
I changed that to...
new_base = mmap (0, new_file_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE,
new_file, 0);
Then, right before the file descriptor gets closed I do a:
write(new_file, (char *) (new_file_h), new_file_size);
Yuck! Yes, I know, but you can get the same effect you are looking for
in most cases. And this is precisely my point. :-)
Later,
David S. Miller
davem@eden.rutgers.edu
davem@remus.rutgers.edu
davem@usacs.rutgers.edu
davem@bazooka.rutgers.edu
davem@linux.helsinki.fi
: This seems to be a MAJOR limitation, since I am new to Linux, is this
: right? If so, how to fix it?
: Russ
: --
: Russell Leighton
: Taylor Computing
: russ@taylor.digex.net taylor@world.std.com
: http://taylor.digex.net http://www.digex.net/~rrl/Welcome.html
------------------------------
From: thomas@melchior.frmug.fr.net (Thomas Quinot)
Subject: [Q] Multi-session PhotoCD & SCSI
Date: 2 Sep 1994 02:22:36 +0200
Is there a way of reading multi-session Kodak Photo-CD disks with an
Apple CD300 (no flames please :-)) ) SCSI CD-Rom drive ?
The adapter is an Adaptec 1540B, and the kernel is 1.1.49.
AdvTHANKSance for any advice.
--
Thomas QUINOT | "Un roi sans divertissement est un
<thomas@melchior.frmug.fr.net> | homme plein de mis<69>re."
Linux - choice of a GNU generation | Jean GIONO
------------------------------
From: owlmed@mv.mv.com (Sam Gentile)
Subject: sb_dsp_operations undeclared 1.1.46
Date: Sat, 3 Sep 1994 13:02:07 GMT
I am trying to build 1.1.46 and got the following problem:
sb_dsp.c: In function 'sb_dsp_init':
sb_dsp.c:815: 'sb_dsp_operations'undeclared
followed by a series of warnings. I also had this problem trying to build
1.1.36. I have not been able to build any kernel after 1.0. I have entered
notes here that have gone un-answered. Please help me. I have a
non-functional system and I can't resolve this myself.
Thanks,
Sam
--
============================================================================
Sam Gentile Mitakuye Oyasin - All My Relations
owlmed@pub.mv.com Live in balance with Mother Earth and
owlmed@iss1.com all of Creation
=============================================================================
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: tar to st0 (Exabyte tape) causes kernel panic
Reply-To: pe1chl@rabo.nl
Date: Fri, 2 Sep 1994 20:38:59 GMT
In <345b6r$b1i@access3.digex.net> rrl@access3.digex.net (Russell Leighton) writes:
>I am able to read from st0 (Exabyte 8200) but
>when I write, the kernel panics...is this a known bug? ...
>what to do? (I am new to Linux ~1day experience).
The first thing you are normally supposed to do is to include the
details of the panic...
Preferably also find out in which function it happened. See the
README file in /usr/src/linux for some detail.
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: Write-protect floppy hassles
Reply-To: pe1chl@rabo.nl
Date: Fri, 2 Sep 1994 20:50:16 GMT
In <3469pq$ppt@news.cs.tulane.edu> butler@cs.tulane.edu (Larry Butler) writes:
>In article <345tju$poj@nntp.ucs.ubc.ca>, Andrew Daviel <advax@triumf.ca> wrote:
>>
>>I would like to see some checking done at mount time, so that mount
>>would only mount a write-protected device readonly. Then I'd get a message
>>on stderr when I tried to write to it.
>>
>There has been much discussion about this and the exact same conclusion has
>been reached by many other people. I don't understand why this problem
>hasn't been addressed.
But it *has* been addressed! With the new kernels you *do get* an error
message when mounting!
(no version numbers were specified so probably both of you were running
1.0.x kernels)
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: nozomi@glaucomys.seino.tsukuba.ac.jp
Subject: Re: MSDOS FS dates off by 5 days! (Slackware 2.0 bug?)
Date: 1 Sep 94 23:59:02 GMT
In article <33uv4m$5fm@senator-bedfellow.MIT.EDU>
a.vignani@CRFV3.CRF.IT (Alberto Vignani) writes:
> In fs/msdos/misc.c, line 232 (for 1.1.48):
> secs += sys_tz.tz_minuteswest*60;
> was the source of the trouble: minuteswest holded a larger value
> (EET difference+5 days).
Not +5 days, but EET diff * 60 seconds.
sys_tz.tz_minuteswest sustains not minute, but seconds!
Try
secs += sys_tz.tz_minuteswest;
It works at least in Japan :-P
Of course, its better to set tz_minute in munute....
--
NoZomi Ytow
nozomi@glaucomys.seino.tsukuba.ac.jp
------------------------------
From: broadley@turing.ucdavis.edu (Bill Broadley)
Subject: Re: Future of linux -- the sequel
Date: Fri, 2 Sep 1994 01:30:06 GMT
: What? I was unaware that any company was still making such slow
: machines. You can get a VL bus motherboard with MIPS R4600 processor
: that makes Pentium look like a 4.77 8086. Why waste money on such
: a junky architecture as Intel when there are good processors available.
Heh. Have some numbers to back this up?
Lets look at spec:
SGI IndyPC R4600 50/100 16/16 62.8 49.9 May94 SGI anno
SGI IndySC R4600 66/133 512+16/16 93.7 72.9 Aug94 SGI anno
Micrnics M4P 80486DX4 33/100 256+16 51.4 26.6 Mar94 comp.arch(Intel)
SNI PCE5S Pentium 60 256+8/8 60.6 55.1 Sep93 SPEC newsletter
SNI PCE5S Pentium 90 256+8/8 86.3 72.7 Jul94 comp.benchmarks
SNI PCE5S Pentium 100 256+8/8 96.2 81.2 Jul94 comp.benchmarks
Intel XPRESS Pent815 100 512+8/8 100.0 80.6 Mar94 comp.arch(Intel)
Hmm indy 4600 doen't make the pentium look like a 8086 to me...
: Compare the price/performance of processors and Intel comes out to
: make the worst processors in existence. PowerPC chips provide twice
Do end users care about price performance of the chip or the system?
Can you buy a motherboard thats faster and cheaper then
the numerous p-90/100 pci motherboards out there? Does it run unix/linux?
: the performance of Pentium at half the cost. That means they are
: 4 times as good. PowerPC is considered slow compared to some other
: processors on the market. For myself, I am just trying to decide
: which non-Intel motherboard to get. They do not cost anywhere near
: $10K.
Hmm so theres a 200 specint 160 specfp $500 chip thats shipping today?
Available in systems?
--
Bill Broadley Broadley@math.ucdavis.edu UCD Math Sys-Admin
Linux is great. Bike to live, live to bike. PGP-ok
------------------------------
From: root@blake.wadham.ox.ac.uk (root)
Subject: Re: XFree & CDROM slow down transfer rate
Date: Sat, 3 Sep 94 14:34:05 BST
Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <CvJ4y6.9B6@news.tudelft.nl> stock@dutsh7.tudelft.nl (Robert Stockmann) writes:
: >When running XFree and using a cdrom device I notice
: >that the transfer rate of my scsi disk slows down.
: >When not running XFree no decrease in transferrate can be observed.
: >If however XFree (openwin) is started the transfer rate is slowed 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..
: 5.6 Mbyte/sec on a CDROM?? You must be kidding...
: Even 500 to 700 Kbyte/s is top-of-the-bill, and not achievable with the
: drive you specify.
: Rob
I think if you read what he wrote he is saying that the transfer rate on his
scsi HARD DISK drops when he accesses his scsi CDROM.
Paul Murray
<root@blake.wadham.ox.ac.uk>
<Paul.Murray@Wadham.Oxford.ac.uk>
------------------------------
From: simonallen@cix.compulink.co.uk ("Simon P Allen")
Subject: Re: XFree & CDROM slow down transfer rate
Date: Sat, 3 Sep 1994 14:25:02 GMT
What you are likely seeing is the buffer cache in action. I could beleive
that you *seem* to get something like 5.6Mb/s but your only reading from
system RAM at that speed. When X is loaded some of the buffers get
tossed out and Linux has to go to the real hardware for data. This
almost *has* to be the explaination because like the gentleman said, 'The
CD-ROM you got aint gonna do that speed'.
Cheers & beers, Simon.
------------------------------
From: wdoyle@hilbert.coe.northeastern.edu (Patrick Doyle)
Subject: IDE Performance enhancement
Date: 3 Sep 1994 14:36:29 GMT
I was wondering if anybody has had a similar experience. I have
installed 1.1.49 and tried recompiling one module of the kernel with
hdparm enhancements disabled and then with them enabled. There was no
appreciable difference in performance. The details are as follows:
33 MHz 386DX w/ 8M RAM
240MD Maxtor IDE hard drive (hdb -- hda is a 120 MB Maxtor w/ DOS)
-- Buffsize=64Kb, MaxMultSect=32
w/o hdparm enhancments, time make zImage yielded:
150.73 user
23.67 system
3:24.44 elapsed
85% CPU
w/ hdparm -m 16 -u1 /dev/hdb, time make zImage (after touching
sbpcd.c)
152.xx user
25.xx system
3:27.xx elapsed
85% CPU
Note, I tend to recompile the kernel while running in an X window, so
there is certainly some amount of swapping being performed (onto /dev/hdb).
One thing I have noticed is that the load average when compiling is
around 1.5 to 3.0. Does this imply that my compiles are CPU-bound, so
regardless of what I do to improve the I/O, it's not going to make
much of a difference?
I saw similar performance (lack of) differences with a previous
version of the kernel (1.1.whatever was distributed by Yggdrasil) as
well as with compiling the Mach kernel (these are the two benchmarks
that mean the most to me).
------------------------------
From: kjb@cs.vu.nl (Kees J. Bot)
Subject: Re: Linux - my first impressions
Date: Sat, 3 Sep 1994 15:16:08 GMT
rob@pe1chl.ampr.org (Rob Janssen) writes:
>In <CvI5oG.1n0@cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes:
>>Under SunOS the installboot(8) program installs the bootstrap and the
>>addresses to /boot into the boot block. This only needs to be done
>>once, because /boot never changes.
>>The LILO method is rather crude.
>I don't think so...
>- LILO does not require the boot image to be on contiguous sectors
No requirement of any other loader I know.
>- LILO can boot many different kernels and also other operating systems
Many different kernels *if* all of them have been mapped. They must be
carefully mapped whenever a new kernel is installed. That's what I mean
with crude.
Booting other operating systems is trivial. It is not something that
makes LILO stand out.
>I think it is a good program, and running its installer after building
>the kernel is not a problem at all. It is even done in the same
>"make zlilo" command.
Inflexible.
I like to hack code on one system, copy the resulting kernel image to
another system with a simple 'rcp' command, and test the new kernel on
this other system. Both systems are running Minix-386vm, with a
bootstrap system written by myself that understands Minix filesystems.
--
Kees J. Bot (kjb@cs.vu.nl)
Systems Programmer, Vrije Universiteit Amsterdam
------------------------------
From: lturetsk@minerva.cis.yale.edu (Lenny Turetsky)
Subject: Status: PAS16 SCSI driver
Date: 2 Sep 1994 01:47:30 GMT
Can anyone tell me the status on the PAS16 SCSI driver?
I currently use the kernel supplied by Summer '94 Yggdrasil (1.1.0 ?) to
access my single-speed CD-ROM, and the driver seems to be really CPU
intensive.
What version (with what kernel) works well?
Thanx,
LT
--
_____________________________________________________________________
/| |
| | There are only two organizations that I know of that send armed |
| | men in dark suits and sunglasses to take money they haven't earned: |
| | the mafia and the government. -- Lenny Turetsky |
| | |
| | Lenny Turetsky (aka) lturetsk@minerva.cis.yale.edu |
| |_____________________________________________________________________|
|/_____________________________________________________________________/
------------------------------
From: longyear@netcom.com (Al Longyear)
Subject: Re: Which kernel should I get for PPP
Date: Sat, 3 Sep 1994 14:54:07 GMT
rene@renux.frmug.fr.net (Rene COUGNENC) writes:
>Ce brave rxr401 ecrit:
>> The FTP throughput depends on many things, e.g. distance from the server,
>> modems, etc. With 1.1.45 kernel (with its own ppp.c driver), I was
>> getting 1.4k to 1.6k per second. I tried the beta PPP drivers (available
>> from ftp://ftp.netcom.com/pub/longyear/prerelease/) but found them to
>> be slower. Perhaps Longyear would like to shed some light on this issue.
I usually try to stay out of debates about "which transfers faster?".
>I am using the beta PPP driver, and I don't notice any speed difference
>compared to the standard one: I get 1.4k to 1.6k per second whatever
>version I use; and this is on a 386/25... go figure :-)
I have been playing with ttcp, netperf, and nettest. My 486 DX50, and
ZyXEL modem (in V.42bis), and talking to a Sun Sparc system with
Morningstar PPP, I now get 1.83K bytes/second with the ttcp data
during the "off hours" on the Sparc. I must do more testing to
evaluate the speed before I will be happy with publishing the results.
The reason that I said that "it seems to be faster" is that I was
getting only a 1.0 K byte/second transfer over the same configuration
to the same system with the previous software.
There is a saying in the automobile commercials in the U.S.A. "Your
mileage may vary."
FTP transfer times have too many variables to be meaningful. They will
vary depending upon the data being sent, the speed of your local disk,
the speed of the remote disk, the process loading on your system and
the remote, etc.
If you wanted to believe in just ftp transfer speeds, then I have
transferred files over my PPP link with 3.8K bytes/second. (The file
was a small, text document.)
As with any other scientific measurement, the experiment must be
recreateable at other sites to be verifiable. Using ftp is just too
variable.
I must admit that I haven't heard about 5 K bytes per minute. Are you
sure that you are not using a AT&T 103 modem (300 Bits/second)? Also
don't try to do a FTP transfer to a PC's diskette drive. Another
possibility is that you do not have flow control enabled and are
overruning the modem's buffer area which corrupts the TCP frames and
requires that they be re-sent. The flow control needs to be enabled at
both ends.
--
Al Longyear longyear@netcom.com
------------------------------
From: csmith@convex.com (Chris Smith)
Subject: Re: ext2fs floppy/82077 corruption with 1.1.49
Date: 1 Sep 1994 21:13:00 -0500
From: ddelsig@uoft02.utoledo.edu
Date: Thu, 1 Sep 1994 04:14:02 GMT
>1) mke2fs a floppy
>2) mount it and copy a big (~500k) file to it (or several files)
>3) unmount it but _don't_ eject it
>4) run "e2fsck -vrf /dev/fd0" --- it will come up clean (reading the cache)
>5) eject it and immediately stick it back in (set disk change flag)
>6) Repeat step 4 -- you will get most of the blocks in the above file(s)
> being marked as "not in use".
>
>Paul.
I've got a Compaq Concerto with an 82077 on it, running kernel
1.1.49. I followed your instructions on how to screw up my
floppies, and was not able to generate any errors.
It reproduces for me, with 1.1.48. The floppy controller's on an AHA1742.
Tried minixfs too, no complaints from fsck then.
------------------------------
From: orc@pell.com (Orc)
Subject: Re: Future of linux -- the sequel
Date: Fri, 2 Sep 1994 21:10:40 GMT
In article <3456g5$1ekr@yuma.acns.colostate.edu>,
Larry Pyeatt <pyeatt@CS.ColoState.EDU> wrote:
>What? I was unaware that any company was still making such slow
>machines. You can get a VL bus motherboard with MIPS R4600 processor
>that makes Pentium look like a 4.77 8086.
I find it hard to believe that a R4600 is 50(*) times faster
than a 586, even if you compare it to the slowest 586 on the market.
And if it's running off local bus, I'd not exactly boast about that.
>Why waste money on such
>a junky architecture as Intel when there are good processors available.
Because (a) Intel boxes are cheap, and (b) I don't see the
architecture from the operating system. For the $2000 difference
between, say, a Sparc Classic and a cheap 486/99 box you can do a
lot. Of course you don't get the Sparc bus, which is much better
than the current crop of PC busses (except, perhaps, PCI, which I
have no experience with), but for a low number of users, seeing
1mbyte/sec across the bus is not appreciably different than
3mbyte/sec.
But if you're doing mainly floating point, I agree with you
completely. Intel floating-point sucks dead bunnies through a
straw.
>Compare the price/performance of processors and Intel comes out to
>make the worst processors in existence.
*sigh* Were that that were true. I keep reading about these
other processors, like the PPC and the various MIPS chips, which
are quoted at much less than their counterpart from Intel, but
when it gets down to the marketplace, the cheapest I've seen for
a motherboard (unless you're looking for a Sparc motherboard) is
around $4k for a R3000. Now, considering that with a little bit of
shopping I could get a pair of 586/60 _boxes_ for this, where is
the advantage of getting that R3000 board?
____
david parsons \bi/ Who clung to his Atari ST because of architectural
\/ superiority, but gave up when part replacement got
more expensive than buying Intel boxes.
------------------------------
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
Subject: dlfcn; dynamic loading
Reply-To: goer@midway.uchicago.edu
Date: Sat, 3 Sep 1994 00:45:10 GMT
Has anyone considered implementing dynamic loading of functions,
like what we find in OSF and SunOS (dlfcn)? Just how complicated
would this be?
--
-Richard L. Goerwitz goer%midway@uchicago.bitnet
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer
------------------------------
** 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
******************************