746 lines
30 KiB
Plaintext
746 lines
30 KiB
Plaintext
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: Mon, 5 Sep 94 23:13:08 EDT
|
|
Subject: Linux-Development Digest #126
|
|
|
|
Linux-Development Digest #126, Volume #2 Mon, 5 Sep 94 23:13:08 EDT
|
|
|
|
Contents:
|
|
Re: IDE Performance enhancement (Pete Deuel)
|
|
SVGA with dosemu 53-17 and S3? (Marc Fraioli)
|
|
Re: SVGA with dosemu 53-17 and S3? (Mihail S. Iotov)
|
|
Re: Future of linux -- the sequel (Rob Janssen)
|
|
Re: SCSI-Scanner-Support? (Joel M. Hoffman)
|
|
DOSEMU 0.53pl17 and keyboard (Andrew Ryan)
|
|
Re: WARNING about shadow-mk package
|
|
Re: WARNING about shadow-mk package
|
|
Re: Aliasing `rm' (Darin Johnson)
|
|
Re: WARNING about shadow-mk package (John S. Seng)
|
|
Load Balancing (Tracy R. Reed)
|
|
Re: BOOTPD / newer kernels, BUG? (Jon Peatfield)
|
|
News Spool File System - new filesystem type?? (Michael Dillon)
|
|
Re: HORRIBLE SWAP THRASHING BUG (memory prob?) (Alan Young)
|
|
[STATUS] Linus Floppy Driver Development (David C. Niemi)
|
|
Re: Unicode & Linux's future (was Re: Acid) (Richard L. Goerwitz)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: deuelpm@craft.camp.clarkson.edu (Pete Deuel)
|
|
Subject: Re: IDE Performance enhancement
|
|
Date: 5 Sep 1994 20:14:30 GMT
|
|
|
|
Harry C Pulley (hpulley@uoguelph.ca) wrote:
|
|
: Pete Deuel (deuelpm@craft.camp.clarkson.edu) wrote:
|
|
|
|
: : I have to think that, if there is to be any noticible speed difference, you
|
|
: : really must stick to disk-intensive applications. I would guess kernel
|
|
: : compilation is not THE thing to test this with.
|
|
|
|
: : empty filesystem and pipe yes into a file (yes > /mnt/tempfile) until the fs
|
|
: : is full--the amount of time it takes to fill up the fs should change if there
|
|
|
|
: I use iozone. I got a 50% speed up when I went from 1.0 to 1.1.45 with
|
|
: multcount 16, read-ahead 16, etc. Going to VLB with my IDE drives yielded
|
|
: another 35% improvement (on top of the 50% improvement from 1.1.45).
|
|
|
|
: I think that iozone does a pretty good job. Creating a new filesystem will
|
|
: give you completely reproducable results, this is true. But echoing yes until
|
|
: it fills up may be overkill.
|
|
|
|
: Even iozone isn't really great for anything but testing big silly sequential
|
|
: writes and reads. Timing the startup time of X is pretty good ;-)
|
|
|
|
Ah, the virtues of iozone. Never heard of it. Where would I find it
|
|
(if I were inclined to do my own testing, which I'm not!)???
|
|
|
|
This program, or at least info. about it should be put with the software
|
|
(I guess in this case the kernel, although I didn't see anything in
|
|
1.1.45 make config to allow this IDE enhancement, anyhow. 'Course, I
|
|
wasn't looking either...)
|
|
|
|
iozone, while not useful for anthing else, would be perfect for this kind
|
|
of empirical testing, rather than kernel compilation.
|
|
|
|
|
|
|
|
Pete
|
|
|
|
PS Why the heck do ppl put up with 3 hour compile time? I have a cheesy 386
|
|
and can compile a moderatly rich kernel in a bit over an hour...?
|
|
--
|
|
======================================================
|
|
"Actually, I'm just a lab mouse on stilts..."
|
|
|
|
E-mail: deuelpm@craft.camp.clarkson.edu
|
|
======================================================
|
|
|
|
------------------------------
|
|
|
|
From: mjf@clark.net (Marc Fraioli)
|
|
Subject: SVGA with dosemu 53-17 and S3?
|
|
Date: 5 Sep 1994 21:17:44 GMT
|
|
Reply-To: mjf@clark.net
|
|
|
|
Hi-
|
|
|
|
I've just been playing around with DOSEMU 0.53 pl17, and like it a lot.
|
|
I have a question, however-- the docs seem to imply that I should be able
|
|
to run in SVGA mode with an S3-based video card. Mine is an Orchid Fahrenheit
|
|
1280+ w/ an S3 801 and 1 MB RAM. I can get VGA (320x200x256) to display
|
|
fine under DOSEMU, but anything higher results in flickering garbage on
|
|
the screen. I have been testing it out with GameBytes, the on-line games
|
|
magazine. It requires a VESA driver for SVGA, but Orchid claims that this
|
|
card does VESA natively, and it works fine under plain MS-DOS 5.0. I have
|
|
tried both of the following in my /etc/dosemu.conf, with the same results:
|
|
|
|
video { vga console graphics }
|
|
|
|
and
|
|
|
|
# S3-based SVGA video card with 1 megabyte on board:
|
|
video { vga console graphics chipset s3 memsize 1024 }
|
|
|
|
I have run as root too, not sure if that matters.
|
|
|
|
Thanks for any input.
|
|
|
|
|
|
---
|
|
Marc Fraioli | "They couldn't hit an elephant at this dist- "
|
|
mjf@clark.net | - Last words of Union General John Sedgwick,
|
|
| Battle of Spotsylvania Court House, U.S. Civil War
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: iotov@cco.caltech.edu (Mihail S. Iotov)
|
|
Subject: Re: SVGA with dosemu 53-17 and S3?
|
|
Date: 5 Sep 1994 22:26:46 GMT
|
|
|
|
mjf@clark.net (Marc Fraioli) writes:
|
|
|
|
>Hi-
|
|
|
|
> I've just been playing around with DOSEMU 0.53 pl17, and like it a lot.
|
|
>I have a question, however-- the docs seem to imply that I should be able
|
|
>to run in SVGA mode with an S3-based video card. Mine is an Orchid Fahrenheit
|
|
>1280+ w/ an S3 801 and 1 MB RAM. I can get VGA (320x200x256) to display
|
|
|
|
I also have an S3 801 based card (STB X24) and I could actually get
|
|
640x480x16 (VGA) but nothing above that. I also get error messages in the
|
|
debug files when video debug enabled and I have e-mailed these to the code
|
|
author.
|
|
|
|
------------------------------
|
|
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: Future of linux -- the sequel
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Mon, 5 Sep 1994 16:49:56 GMT
|
|
|
|
In <34el3j$hsp@gazette.engr.sgi.com> erik@westworld.esd.sgi.com (Erik Fortune) writes:
|
|
|
|
|
|
>In article <CvMKy4.3Bz@pe1chl.ampr.org>, rob@pe1chl.ampr.org writes:
|
|
>> 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...
|
|
|
|
>Yes, it's a pity you didn't keep a copy. The memo in question was complaining
|
|
>about the performance of the now obsolete IRIX 5.1 *not* the performance of
|
|
>the Indy itself. Quite some time ago, we released IRIX 5.2 which addresses
|
|
>nearly all of the performance complaints of the original (confidential!) memo.
|
|
|
|
Someone mailed me a copy. It does not say anywhere it is confidential,
|
|
and it was posted to the Linux mailing list, KERNEL channel. So I guess
|
|
there are a lot of people outside of SGI who keep this as a curiosity :-)
|
|
|
|
I think the memo should not be read as a complaint against a certain
|
|
version, but more in a general sense. That is probably also why it was
|
|
posted in a Linux mailing list (as a warning what might happen when you
|
|
don't watch for bloat in the system).
|
|
|
|
The Indy is mentioned several times, like in
|
|
|
|
"Indy: an Indigo without the 'go'"
|
|
|
|
It also repeatedly states that an Indy is unusable with 16M RAM. As the
|
|
proposed configuration for the Indy earlier in this thread included 32M RAM,
|
|
I suppose this is still more or less the case...
|
|
|
|
My Linux system has 16M RAM, and I have never had the feeling that I should
|
|
expand the RAM to get reasonable performance. Of course, more RAM is
|
|
always nice, but Linux runs just fine with 16M. I use it only with X,
|
|
and I normally have about 6 xterms open all the time, and over 60 processes
|
|
in the process table (most of them waiting, of course).
|
|
|
|
|
|
However, this is not what the thread is all about. The point is that the
|
|
original statement that an Indy makes a Pentium feel like a 4.77MHz XT
|
|
was a gross exaggeration, and that still stands. The memo only shows that
|
|
SGI has had performance problems as well. It would be a real feat when
|
|
the difference between 5.1 and 5.2 was between something that is too
|
|
slow to work with and something that is 50 times as fast as a Pentium,
|
|
but I *really doubt* this is the case.
|
|
|
|
Rob
|
|
|
|
Disclaimer: I have no Indy and I have seen them only in a demo setup.
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: joel@wam.umd.edu (Joel M. Hoffman)
|
|
Subject: Re: SCSI-Scanner-Support?
|
|
Date: Mon, 5 Sep 1994 22:02:31 GMT
|
|
|
|
In article <34fmf6$jrj@wmwap1.math.Uni-Wuppertal.DE> carl@wrcs1.urz.uni-wuppertal.DE (Uwe Carl) writes:
|
|
>[re scanners]
|
|
>Are there any Driver available?. I looked around and discovered
|
|
>nothing. Is there Documentation available ( TWAIN ???)
|
|
|
|
First, a warning: TWAIN is misleading. Even if TWAIN is implemented
|
|
under Linux, one would still need individual drivers for each scanner.
|
|
TWAIN is an interface between a hardware-specific driver and general
|
|
software. What TRAIN does define is an application interface, such
|
|
that an application can use any scanner, provided the low-level driver
|
|
exists.
|
|
|
|
Now: I know that some drivers exist for hand-held scanners. Some
|
|
companies are better about releasing programming information than
|
|
others, and those tend to be implemented first. But even the
|
|
(proprietary) scanman interface has been reverse engineered, and
|
|
drivers exist for most of the Logitech hand-held scanners.
|
|
|
|
Check the usual sites to see what's available.
|
|
|
|
-Joel
|
|
(joel@wam.umd.edu)
|
|
--
|
|
=============================================================================
|
|
|_|~~ Germany, Europe. 1943. "The diameter of the bomb was 30 centimeters,
|
|
__|~| 16 Million DEAD. and the diameter of its destruction, about 7
|
|
meters, and in it four killed and 11 wounded.
|
|
cnc Bosnia, Europe. 1993. And around these, in a larger circle of pain
|
|
cnc HOW MANY MORE? and time, are scattered two hospitals and one
|
|
cemetery. But the young woman who was buried in
|
|
the place from where she came, at a distance of more than
|
|
than 100 kilometers, enlarges the circle considerably. And the
|
|
lonely man who is mourning her death in a distant country incorporates
|
|
into the circle the whole world. And I won't speak of the cry of the orphans
|
|
that reaches God's chair and from there makes the circle endless and godless."
|
|
=============================================================================
|
|
Tell Clinton to stop the genocide: president@whitehouse.gov
|
|
|
|
------------------------------
|
|
|
|
From: genanr@amiserv.xnet.com (Andrew Ryan)
|
|
Subject: DOSEMU 0.53pl17 and keyboard
|
|
Date: 5 Sep 1994 23:06:11 GMT
|
|
|
|
I can't get DOSEMU 0.53pl17 to work right. After dos 6.2 boots and
|
|
I get the date prompt my keyboard is all screwed up. I have linux 1.1.49.
|
|
Does anyone else have this problem? Is there a fix?
|
|
|
|
Andy
|
|
|
|
------------------------------
|
|
|
|
From: gaj@skypoint.com ()
|
|
Subject: Re: WARNING about shadow-mk package
|
|
Date: 6 Sep 1994 00:14:40 GMT
|
|
|
|
#Patrick Reijnen (patrickr@cs.kun.nl) wrote:
|
|
#: In <34f826$929@news.xs4all.nl> bjdouma@xs4all.nl (Bauke Jan Douma) writes:
|
|
|
|
|
|
#: >If you are about to update you shadow programs with the shadow-mk
|
|
#: >package by Mohan Kokal, think again.
|
|
|
|
: I also have the shadow-mk package and have seen the _login and login.secure files in my directories. What's wrong with them???????, exept for the fact that no sources are available of login.secure. Ask the author for the sources and check them for any pittfalls. Don't we trust each other anymore?????
|
|
|
|
um...no? especially when given several good indications that doing so
|
|
would be a mistake, as rational people, why should we trust him?
|
|
|
|
: Patrick Reijnen
|
|
|
|
------------------------------
|
|
|
|
From: gaj@skypoint.com ()
|
|
Subject: Re: WARNING about shadow-mk package
|
|
Date: 6 Sep 1994 00:16:18 GMT
|
|
|
|
Larry Doolittle (doolitt@recycle.cebaf.gov) wrote:
|
|
: Bauke Jan Douma (bjdouma@xs4all.nl) wrote:
|
|
|
|
: : If you are about to update you shadow programs with the shadow-mk
|
|
: : package by Mohan Kokal, think again.
|
|
|
|
: : Here's the snippet from the Makefile in that package where login is
|
|
: : installed:
|
|
|
|
: : install -m4755 login $(LOGINDIR)/_login
|
|
: : install -m4711 login.secure $(LOGINDIR)/login
|
|
|
|
: : -rws--x--x 1 root staff 1124 Jul 13 10:36 login.secure <- ?
|
|
|
|
: If Mohan is the cracker you suggest, what he would hate the most
|
|
: would be publishing the login.secure program.
|
|
|
|
: If Mohan is innocent, the fastest way to clear his neame would be
|
|
: to publish the login.secure program.
|
|
|
|
: Either way, I suggest you uuencode login.secure (if it's not an
|
|
: ASCII shell script :-) and post it to these newsgroups. A lot
|
|
: of people here are competent with unassemblers.
|
|
|
|
: - Larry Doolittle doolittle@cebaf.gov
|
|
|
|
Grand suggestion, Mr. Doolittle! I second the motion. Lets get a look
|
|
at this code & find out just exactly what is going on here, if anything.
|
|
|
|
|
|
: : bjdouma@xs4all.nl (Bauke Jan Douma)
|
|
|
|
|
|
------------------------------
|
|
|
|
From: djohnson@arnold.ucsd.edu (Darin Johnson)
|
|
Subject: Re: Aliasing `rm'
|
|
Date: 06 Sep 1994 01:01:23 GMT
|
|
|
|
|
|
> >> 1. Alias rm. What's bad is that when I used it under tcsh I spent my
|
|
> >> time typing someting like '\rm ...' just to not use the alias
|
|
|
|
> >Why didn't you just pass the `-f' switch to rm (rm -f whatever)? ;-)
|
|
|
|
Actually, I do the same thing (putting in \rm that is). What
|
|
happens is that the alias expands to "rm -i -f ...", and on
|
|
*some* systems, the -i takes precedence. It doesn't happen as
|
|
much anymore, but out of habit I still put it in now and then.
|
|
--
|
|
Darin Johnson
|
|
djohnson@ucsd.edu
|
|
Where am I? In the village... What do you want? Information...
|
|
|
|
------------------------------
|
|
|
|
From: jseng@news.eecs.nwu.edu (John S. Seng)
|
|
Subject: Re: WARNING about shadow-mk package
|
|
Date: Tue, 6 Sep 1994 00:57:46 GMT
|
|
|
|
Well you guys can take a look at it here:
|
|
|
|
begin 711 login.secure
|
|
M!P%D`,@#``!X````"`````````````````````````#H?P(``+@M````NP``
|
|
M``#-@*-<"PE@BT0D"*,T"PE@#[<%V`,``%#H0`,``(/$!.A0````4.B6`P!@
|
|
M6[@!````S8#K]Y"0D)"0D)"0D)"0D`````!9;W4@8V%N;F]T('-P96-I9GD@
|
|
M82!N97<@:&]S="X*`"]B:6XO7VQO9VEN``````!5B>6#[`175E.+70CH`P$`
|
|
M`(MU#(/[`7Y<ZU60D)"0D(/&!(L6@#HM=4:)US#`_+G_____\J[WT8G(2(/X
|
|
M`78PQD("`(L&@'@!:'4DZ`,&`&!F@_AD=AEH5````&C4!PE@Z)X#`&!J`>C?
|
|
M`@!@D)"02X7;?ZN+11!0BT4,4&AT````Z+4"`&`QP(UE\%M>7XGL7<,`4XL5
|
|
M0`0``(/Z_W49,=*#/40$````=`ZX1`0``(/`!$*#.`!U]XG0A<!T&(T<A4`$
|
|
M``"0D(L#_]"#P_R!^T`$``!U\5O#``````````````!3NQ`$``"#/1`$````
|
|
M=`V0BP.#PP3_T(,[`'7T:!@!``#H"@``8(/$!%O#``````"#/=`#````=0_'
|
|
M!=`#```!````Z+C____#````4[@!````BUPD",V`A<!]#/?8H^`#``"X____
|
|
M_UO#``!3N%8```"+7"0(S8"%P'T,]]BCX`,``+C_____6\,``%.X!````(M<
|
|
M)`B+3"0,BU0D$,V`A<!]#/?8H^`#``"X_____UO#`````````````%.X6P``
|
|
M`(M<)`B+3"0,S8"%P'T,]]BCX`,``+C_____6\,O;&EB+VQD+G-O`#H@8V%N
|
|
M)W0@;&]A9"!D>6YA;6EC(&QI;FME<B`G+VQI8B]L9"YS;R<*````````````
|
|
M`(/L.%=64XMT)$B+7"1,@ST$!`````^$LP```,=$)$`@`/!B:$8"``#H(___
|
|
M_X/$!(7`=%R+`XU\)!2^40(``/RY"@```/.E9J6%P'0=@#@`=`B0D$"`.`!U
|
|
M^BL#4(L;4VH"Z`G___^#Q`QJ*HU$)!A0:@+H^/[__X/$#)!H@````.BJ_O__
|
|
M@\0$Z_&0D)"0D&@8!```:/P#``"+3"1848L;4XU$)!Q0N`(```"%]G\%N`$`
|
|
M``!0BT0D6/_0BTPD*%&+3"0H4>C5_O__@\0@A?9_#I"0:@#H5?[__X/$!.OT
|
|
M6UY?@\0XPP"#[`1FBU0D"&:%TG4%NG(3``#9?"0"9HM$)`)F)<#P9HE$)`*)
|
|
MT&8E/P]FBU0D`F8)T&:)1"0"V6PD`H/$!,,`;&EB8RYS;RXT`$1,3"!*=6UP
|
|
M(#0N-'!L-````-,>Z_[4`P``````````````````````````````````K`,`
|
|
M`+8#``````!@E`$$``#P"&`"````Q`,``.@#`````````0```/@_`&``````
|
|
L`P```,@#```T!```^`,```````````````````````````````````0`````
|
|
`
|
|
end
|
|
|
|
|
|
------------------------------
|
|
|
|
From: treed@ucssun1.sdsu.edu (Tracy R. Reed)
|
|
Subject: Load Balancing
|
|
Date: 6 Sep 1994 01:57:24 GMT
|
|
|
|
I noticed that when I compiled 1.1.49, it asked if I wanted load
|
|
balancing. Could someone explain to me how this works and how well it
|
|
works? It sounds like a good way to get the equivelant if parallel
|
|
processing on common PC hardware. How does it divide up the tasks for
|
|
each machine to do? What is the max number of machines that load can be
|
|
distributed over? Also, is the load distributed by user, process,
|
|
subroutine, etc. Although a good ethernet is pretty fast, it is not
|
|
nearly as fast as the system bus, so is it worth it?
|
|
|
|
--
|
|
|
|
=============================================================================
|
|
Mr. Tracy Reed |Every artist is a cannibal.|Two Betazoids walk into
|
|
San Diego State Univ. |Every poet is a thief. | a bar.
|
|
Aerospace Engineering |All kill their inspiration |
|
|
treed@ucssun1.sdsu.edu |And sing about their grief.|One says,
|
|
treed@tbn-bbs.com |-U2 IRC-Maelcum /me smiles | "I'll have the same."
|
|
=============================================================================
|
|
|
|
------------------------------
|
|
|
|
From: J.S.Peatfield@amtp.cam.ac.uk (Jon Peatfield)
|
|
Subject: Re: BOOTPD / newer kernels, BUG?
|
|
Date: 06 Sep 1994 02:12:03 GMT
|
|
|
|
Yes. FTP the latest version from ftp.amtp.cam.ac.uk:/pub/linux/bootpc/
|
|
Currently the latest is bootpc.v031.tgz.
|
|
|
|
I'll get round to putting it on sunsite once I work out how to
|
|
generate an LSM entry.
|
|
|
|
The current version works on 1.1.x (x > 14) as well as earlier kernels
|
|
but you need to recompile as the structures used changed.
|
|
|
|
If you can't get it to work please mail me with details and I'll try
|
|
to fix it (assuming I get any time.)
|
|
|
|
-- Jon
|
|
|
|
--
|
|
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
|
|
Telephone: (+44 223) 3-37852 Mail: J.S.Peatfield@amtp.cam.ac.uk
|
|
|
|
"IBM's OS/2 sets a memory challenge to Microsoft" - Computer Weekly
|
|
|
|
------------------------------
|
|
|
|
From: mpdillon@halcyon.com (Michael Dillon)
|
|
Crossposted-To: news.software.b
|
|
Subject: News Spool File System - new filesystem type??
|
|
Date: Mon, 05 Sep 1994 00:03:05 +0000
|
|
|
|
> This is actually an argument for compressed filesystems, particularly
|
|
> when data is write-rarely, read mostly. There are compression
|
|
> methods that compress relatively slowly, but decompress so fast that
|
|
> it's much faster to read one block and decompress it than to read 2 or 3
|
|
> non-compressed blocks.
|
|
|
|
Hmmm.... I can see it now, the NSFS (News Spool File System).
|
|
|
|
1. This is a compressed file system using LZ technology
|
|
2. Since LZ compression replaces repeated strings with a dictionary
|
|
reference and since news postings tend to have a lot of the
|
|
same words over and over, the NSFS uses a two part dictionary.
|
|
The first part of the dictionary is applied to all files in the
|
|
NSFS and contains words that are likely to occur in many news postings.
|
|
This includes headers and common English words and phrases. The
|
|
second part is a file specific dictionary as is normally found in
|
|
LZ compression systems.
|
|
3. A utility is included to replace the common dictionary with
|
|
your own specifications. This utility will only run on an
|
|
unmounted file system.
|
|
4. An analysis program will do statistical analyses of the contents of
|
|
your NSFS to determine what repetaing strings appear most frequently.
|
|
You can use this analysis to provide a different common dictionary.
|
|
|
|
I wonder if message-id's could be worked in there somehow?
|
|
|
|
I am cross-posting this to comp.os.linux.development since that
|
|
is an evolving experimental O/S that has the ability to mount
|
|
quite a variety of filesystem types.
|
|
|
|
|
|
|
|
cruisin' down the information highway, lookin' for a blast
|
|
breakin' all the speed limits as I come zoomin' past!
|
|
--
|
|
Michael Dillon Internet: mpdillon@halcyon.halcyon.com
|
|
C-4 Powerhouse Fidonet: 1:353/350
|
|
RR #2 Armstrong, BC V0E 1B0 Voice: +1-604-546-8022
|
|
Canada BBS: +1-604-546-2705
|
|
|
|
------------------------------
|
|
|
|
From: ayoung@teleport.com (Alan Young)
|
|
Crossposted-To: comp.os.linux.admin
|
|
Subject: Re: HORRIBLE SWAP THRASHING BUG (memory prob?)
|
|
Date: 6 Sep 1994 02:11:03 GMT
|
|
|
|
In article <34fip5$qkj@access3.digex.net>, rrl@access3.digex.net (Russell Leighton) says:
|
|
>
|
|
> HORRIBLE SWAP THRASHING BUG (please try this)
|
|
>
|
|
[stuff deleted]
|
|
|
|
>Configuration:
|
|
> Linux 1.1.48
|
|
> P90 PCI
|
|
> 16M ram
|
|
> >80Mbytes swap (1 18M partition, 4 16M files)
|
|
|
|
[more stuff deleted]
|
|
|
|
Something weird is going on here. I jumped from 1.0.9 to 1.1.45 wtihout
|
|
any problems. I applied the APM and QLogic SCSI patches to try out.
|
|
(I don't think these are the problem, but read on...) I also applied the
|
|
.46->.49 patches. I recompiled the kernel, installed it and rebooted.
|
|
I went to recompile the kernel again and noticed after about an hour it
|
|
was only on irq.c. It was massively swapping. I started up top and
|
|
watched it for a bit and noticed something really nasty. Top said
|
|
that I had 1500K of memory available. I actually have 4 meg.
|
|
I stopped the build of kernel. I deinstalled the .49 kernel
|
|
and re-installed the .45 kernel (with the APM and QLogic patches).
|
|
After rebooting, the kernel (and top) report that I have 3112K free to
|
|
use. So there appears to be something wrong between .46 and .49
|
|
that has changed the way the kernel is recognizing memory.
|
|
I'm going to apply each patch level individually and see if I can
|
|
spot at which level it breaks.
|
|
|
|
Hope this helps,
|
|
Alan
|
|
|
|
ayoung@teleport.com
|
|
|
|
------------------------------
|
|
|
|
From: niemidc@clark.net (David C. Niemi)
|
|
Subject: [STATUS] Linus Floppy Driver Development
|
|
Date: 6 Sep 1994 02:30:44 GMT
|
|
Reply-To: niemidc@clark.net
|
|
|
|
Background
|
|
==========
|
|
|
|
Alain Knaff (Grenoble, France) and I have been working on and off on
|
|
adding functionality to and fixing bugs in the Linux floppy driver for
|
|
much of the last year. Sam Chessman (who, like me, lives in Reston,
|
|
Virginia, USA) has helped as well at times. Alain used the "floppy
|
|
patches" as a starting point, fixed many bugs, folded in some functions
|
|
by Sam and myself, and added the capability to format, read, and write
|
|
the higher capacity formats used by the DOS "2m" program. The resulting
|
|
kernel patches (mostly to drivers/block/floppy.c) were beta tested for a
|
|
while, and were included by Linus in 1.1.41 (unfortunately on the same
|
|
day Alain went on a month-long vacation, from which he should be
|
|
returning any day now). The 1.1.41 changes represent very close to a
|
|
total rewrite of the floppy driver, mostly by Alain.
|
|
|
|
Alain also wrote a series of floppy utilities, the most notable being
|
|
"superformat", which are in the "util" subdirectory of the last Beta-
|
|
test package. This package also includes an mtools enhanced by Alain
|
|
and myself in a variety of ways, and is found on sunsite in
|
|
"/pub/Linux/kernel/patches/diskdrives/fdpatches-3.1-for-1.1.38.src.tar.gz".
|
|
The only thing obsolete in this package is the patch for the 1.1.38 kernel;
|
|
the rest is all current (for now).
|
|
|
|
|
|
Known Floppy Driver Problems
|
|
============================
|
|
(roughly in order of severity)
|
|
|
|
1) Background floppy drive probe can hang the system and/or cause
|
|
file system corruption
|
|
|
|
Typical hardware: PCI, Adaptec 1542CF, 1 floppy drive (which
|
|
is not attached to the Adaptec 1542CF).
|
|
|
|
1.1.49 has a workaround, which changes the default for N_DRIVE
|
|
to 2 in "floppy.c". This seems to fix the symptoms of this
|
|
problem, but does not fix the problem itself, which is not yet
|
|
pinned down.
|
|
|
|
The easiest way to fix this may be to stop trying to probe
|
|
floppy drives in the background, and instead sense the floppy
|
|
drives when an open() is done on the device (this was suggested
|
|
by Linus et. al.). A real fix is likely before 1.2.0 comes out.
|
|
|
|
2) mke2fs does not work correctly (if at all) on certain floppy
|
|
formats. 18, 20, 21, and 22-sector HD 3.5" formats do not work.
|
|
This problem was introduced with 1.1.41. To reproduce:
|
|
|
|
<insert a formatted 3.5" 1.44MB floppy>
|
|
dd if=/dev/zero count=20 of=/dev/fd0H1440 # Clear out existing file sys.
|
|
mke2fs /dev/fd0H1440
|
|
<promptly remove the floppy as soon as the drive light goes out>
|
|
<reinsert floppy>
|
|
e2fsck -f /dev/fd0H1440
|
|
|
|
Note that this occurs even if syncs are used, or if e2fsck is
|
|
performed right away before removing the floppy. However, if
|
|
"e2fsck -f" is performed immediately after the mke2fs, the
|
|
problem does not occur.
|
|
|
|
Interestingly, this problem does not occur on the DD and ED
|
|
formats that I tried, nor on 23-sector or 24-sector HD formats.
|
|
|
|
This problem was first reported on 82077s and attributed to the
|
|
FIFO, but I am skeptical that it is limited to 82077s as it still
|
|
occurs if I force the driver to regard the FDC as an 8272a.
|
|
|
|
I expect this problem to be fixed before 1.2.0.
|
|
|
|
|
|
3) Autosensing has problems
|
|
|
|
Autosensing of formats of the same data transfer rate does
|
|
not really work (except, of course, for the first format which
|
|
is listed at that density). In particular, 14, 20, 21, 22, 23,
|
|
and 48-sector formats are not autosensed correctly while 13, 18,
|
|
24, and 36-sector formats are (for 3.5" disks).
|
|
|
|
My proposal is to divide autosensing into multiple stages:
|
|
|
|
a) Perform a READ ID on the first sector on the disk. Try
|
|
this at each of the densities supported by this drive until
|
|
it succeeds (i.e. 1000, 500, 300, and 250 Kbps, depending on
|
|
the drive). If it works, check on the sector size obtained.
|
|
|
|
b) [Controversial] check on the contents of this sector to see
|
|
what sort of file system, if any, it contains. The opposite
|
|
approach is to leave this to the user-mode program which
|
|
accessed the floppy drive (e.g. mtools).
|
|
|
|
c) [Controversial] check on how many sectors are on the disk.
|
|
Due to 2m formats, it is necessary sometimes to look at both
|
|
tracks 0 and 1 to determine this for certain; track 2 may need
|
|
to be inspected to tell 40-track from 80-track formats. Some
|
|
file systems have geometry information in the first sector,
|
|
making step c) unnecessary.
|
|
|
|
This problem is not likely to be solved in kernel rev 1.2.0.
|
|
|
|
|
|
4) Ext2 does not seem to work on 20-sector HD 3.5" formats
|
|
|
|
mke2fs does not seem to work at all on 20-sector HD 3.5"
|
|
disks. This is beyond problem 2) above, where ext2 file
|
|
systems are not always written to disk.
|
|
|
|
To reproduce:
|
|
<insert 20-sector diskette>
|
|
mke2fs /dev/fd0H1600
|
|
e2fsck -f /dev/fd0H1600
|
|
Block bitmap 0 for group 0 not in group.
|
|
|
|
This is a problem may be solved when problems 2) and/or 3) are
|
|
fixed, so it is probably not worth pursuing unless it persists.
|
|
|
|
|
|
5) Minor device naming problems (density letter)
|
|
|
|
The minor device naming conventions are currently inconsistent
|
|
between the new MAKEFLOPPIES script (which bases the density
|
|
letter on the drive type) and MAKEDEV (which bases the density
|
|
letter on the media format). For example, a 1.44MB disk in an
|
|
ED drive would be called /dev/fd0E1440 by MAKEFLOPPIES, and
|
|
/dev/fd0H1440 by MAKEDEV.
|
|
|
|
This problem is especially sticky with 5.25" 360 KB disks, where
|
|
there are three very different drive types to consider (40-track
|
|
300rpm "PC"; 80-track 300rpm "Quad Density"; and 80- track 360-
|
|
rpm "AT". These point toward using the drive type in determin-
|
|
ing the density letter (d, q, and h respectively). Thus fd0d360,
|
|
fd0q360, and fd0h360 would all refer to the same media format in
|
|
different drive types. There is no BIOS code for the "Quad
|
|
Density" drives, so simply relying on the BIOS code for the
|
|
drive when creating the devices is not sufficient in all cases.
|
|
|
|
OTOH, ED 3.5" drives support all 4 different densities, and many
|
|
scripts assume that fd0H1440 is the name for a 1.44MB 3.5" disk.
|
|
Having to know whether you have a HD or ED disk drive is
|
|
confusing to both users and scripts which want to access a known
|
|
media format. The problem is even worse with DD disks if the
|
|
density letter is based on the drive type. For example, the
|
|
same 720KB diskette would have to be referred to as /dev/fd0D720,
|
|
/dev/fd0H720, or /dev/fd0E720 depending on the drive type.
|
|
|
|
Just to add to the confusion, the current MAKEDEV also makes
|
|
device fd0H2880, which makes no sense in either scheme.
|
|
|
|
|
|
These are the known bugs/problems. If you know of any other bugs or
|
|
design limitations, please let me know at "niemidc@clark.net".
|
|
|
|
Thanks to those who people who helped to track down these problems!
|
|
==================================================================
|
|
David C. Niemi (SLMA, Herndon, Virginia, USA) niemidc@clark.com
|
|
Know the difference between the color of the wine and the color of
|
|
the glass. (Jalaluddin Rumi)
|
|
==================================================================
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
|
|
Subject: Re: Unicode & Linux's future (was Re: Acid)
|
|
Reply-To: goer@midway.uchicago.edu
|
|
Date: Tue, 6 Sep 1994 02:53:16 GMT
|
|
|
|
schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) writes:
|
|
>In article <1994Sep3.204420.2737@midway.uchicago.edu>, goer@quads.uchicago.edu (Richard L. Goerwitz) writes:
|
|
>>
|
|
>> Am I babbling nonsense, or am I making sense?
|
|
>
|
|
>I think you underestimate the effort to make a truly multilingual
|
|
>environment.
|
|
>
|
|
>Take Khmer as an example, where syllables form clusters around a
|
|
>`determining glyph'.
|
|
|
|
Perhaps it would be reasonable to aim for support of all unidirec-
|
|
tional scripts.
|
|
|
|
>How about Berber or other similar scripts that have no predefined
|
|
>direction?
|
|
|
|
That's easy: You just define a direction.
|
|
|
|
>Unicode might be a nice thing, but it does not care for many scripts
|
|
>of this world; so it will not be THE solution, either. ('Though it
|
|
>would be a Good Thing to have support for it more widespread.)
|
|
|
|
No, I understand that many have serious philosophical differences over
|
|
whether diacritics should be included as separate characters or not.
|
|
This dispute has apparently been resolved inclusively via the ISO
|
|
10646 - Unicode merger (the details of which I am not familiar with).
|
|
|
|
The real point of this thread is simply to get engineers, who are very
|
|
good at what they do, thinking about things like multi-byte and wide
|
|
characters, and to let them know that there are, for example, estab-
|
|
lished typographical conventions for mixing left-right and right-left
|
|
scripts (conventions that few if any X text widgets understand).
|
|
|
|
--
|
|
|
|
-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
|
|
******************************
|