At 05:47 PM 19-10-97 -0400, you wrote:
>
>linux-kernel-digest Sunday, 19 October 1997 Volume 01 : Number
1235
>
>In this issue:
>
> Re: Compilation Problem (2.0.31)
> Multiple kernelds
> OS wars - offtopic
> Sys V message problems
> Re: Compiling the kernel with EGCS.
> Re: serial input overrun(s) using ide-cd
> Re: Fix for icmp.c for firewalling rules that return PORT_UNREACH
> PLIP Performance.
> 2.1.59 compile probs (module symbols for _everything_ :-)
> Re: Patch for Spellcast ISDN driver in 2.1.59
> Clustering
> Re: Kernel compiles with egcs
> Re: serial input overrun(s) using ide-cd
> Serial Console and X11 ?
> problem with exec() and clone(CLONE_SIGHAND)
> Re: A new tree?
> Re: Fix for icmp.c for firewalling rules that return PORT_UNREACH
> Re: Patch for Spellcast ISDN driver in 2.1.59
> Re: Patch for Spellcast ISDN driver in 2.1.59
> 2.0.31: compile error for arch/i386/boot/compressed/misc.c
> Re: ULTRA DMA HDD
> Re: Linux 2.0.31 (de4x5 driver failure)
> Re: Serial Console and X11 ?
> Re: UPDATE: GP in proc_lookupfd with pre-patch-2.0.31-10
> Re: Linux 2.0.31 (de4x5 driver failure)
> Re: Patch for Spellcast ISDN driver in 2.1.59
> Re: PLIP Performance.
> Re: pread/pwrite patch
> 2.0.30 and badblocks on IDE disks
> Re: laptop + 2.1.57 resetting before printing "Uncompressing Linux"
> registers in proc filesystem?
> Re: pread/pwrite patch
> 2.0.31 kernel question
> Re: pread/pwrite patch
> IP masquerade
> is raid0 stable in 2.0.31?
> Problems compiling 2.0.31
>
>See the end of the digest for information on subscribing to the linux-kernel
>or linux-kernel-digest mailing lists.
>
>----------------------------------------------------------------------
>
>From: Doug Ledford <dledford@dialnet.net>
>Date: Sun, 19 Oct 1997 03:43:55 -0500 (CDT)
>Subject: Re: Compilation Problem (2.0.31)
>
>On 18 Oct 1997, Miquel van Smoorenburg wrote:
>
>> >> gcc -D__KERNEL__ -I/usr/src/linux-2.0.27/include -Wall
-Wstrict-prototypes
>> >> -O2 -fomit-frame-pointer -fno-strength-reduce -D__SMP__ -D__SMP_PROF__
>> >> -pipe -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
-DCPU=586
>> >> -D__SMP__ -c -o sd_ioctl.o sd_ioctl.c
>> >> gcc -I/usr/src/linux-2.0.27/include -o aic7xxx_asm aic7xxx_asm.c
>>
>> The patch leaves empty aic7xxx_asm.{c,h} files if you don't give the
>> -E option to the patch program. The scripts/patch-kernel script does
>> it right, btw.
>
>Note the differing compile lines for the different files. This would
>indicate that his drivers/scsi/Makefile still includes the rules for the
>aic7xxx_asm executeable. This was the problem Iw as referring to. I've
>had those empty files laying around in my own source tree for some time.
>They don't really create any problems (other than clutter). It's the
>rules in his Makefile that will cause a problem. Methinks it's time to
>check the 2..0.31 tree out (I haven't had a chance since the announcement
>as my machine has been off-line the whole time due to hard disk low level
>formatting and re-installation).
>
>Doug Ledford
>
>
>
>------------------------------
>
>From: Pavel Machek <pavel@Elf.mj.gts.cz>
>Date: Sat, 18 Oct 1997 23:34:49 +0200
>Subject: Multiple kernelds
>
>Hi!
>
>I just would like to ask: Why might you want to have multiple
>kernelds? I see that code is quite complicated just because this.
>
>Only possibility I see is that you might have so much requests that
>one kerneld could not handle that? Well, but if kerneld is _really_
>overloaded (it does not matter how many of them are out there), then
>requests are going to dissappear, anyway (i.e. it will not work), so
>why trying?
>
> Pavel
>
>- --
>I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
>Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
>
>------------------------------
>
>From: jpl@friko.onet.pl
>Date: Sun, 19 Oct 1997 11:54:35 +0200
>Subject: OS wars - offtopic
>
>From: Vince Weaver <weave@eng.umd.edu>
>
>[I wrote this today, frustrated as usual with the idiots in Redmond
> sorry for any innacurarcies in the parallel; I only have knowledge
> of the second trilogy; the rest is second hand from my girlfriend
> who has read all the books. Apologies to George Lucas
> -- Vince Weaver, weave@eng.umd.edu]
>
> The OS Wars Trilogy: A preview
>
>A long time ago, in a galaxy not unlike this one, the microprocessor was
>invented. There was much rejoicing over this discovery; no longer must
>computers be controlled by a mystic priest-hood. Computers can be used by
>all as useful tools!
>The knights of hackerdom, hereafter referred to as hackers, used and
>developed and promoted and in general considered this new breed of computer
>a Good Thing. These magical devices could lead to wonders never before seen
>in the galaxy. So these hackers, a strange group to begin with, devoted
>their lives to the development of this technology.
>
>For a while peace and prosperity filled the galaxy. This was the age of
>Apple II's and Commodore 64's, Atari's and TRS-80's. A renewed sense of
>learning and cooperation-operation filled all the lands. There was
comfort in
>knowing that for all the programs being used the source was flowing freely.
>When one had the source code, happiness and well-being flowed.
>Unfortunately during this time there was a rumbling in the source. One of
>the first systems, the Altair system, had a BASIC interpreter crafted by a
>young hacker named Bill. Bill, however, did not want the source of his
>creation flowing freely. He enjoyed subverting the source for his own
>purposes, mainly for monetary benefit. The use of proprietary code is the
>dark side of the source.
>This new age of joy and prosperity had to come to an end sooner or later.
>An old Imperial Power, IBM, decided to try to control this new way of life.
>It released its PC, thus beginning the clone wars. With IBM clones flooding
>the market, backed by the old Empire, up-starts had little chance. The ix86
>architecture was enforced. This was a chaotic time, and IBM made one
>mistake. Needing an Operating System to be the life-source of their new
>product, IBM chose young Bill to obtain one.
>
>About this time the dark side of the source became too much and young hacker
>Bill became Darth Gates. Obtaining an inferior 8-bit OS, he made this the
>mainstay of the IBM world. In just a few short years Darth Gates controlled
>the OS, managing to leave the old Imperial IBM far behind. While Gates
>could have used his powers for good, instead he chose to strive for evil.
>While all this was happening, rebel groups attempted to bring down the
>evil stronghold. Apple, Amiga, and Unix factions fought valiantly, as did
>some direct competitors in Darth Gates' market. Alas, to no avail. And as
>the evil OS moved from version 1.0 through version 6.0 the future looked dim.
>To make matters worse, Darth Gates hatched a sinister plan to counter-act
>the minimal success of the rebels; steal their technology. Thus the
>DeathOS was devised. The first half-working version was DeathOS3.1, and it
>could destroy the usefulness of even the most powerful 386. While the
>rebels learned to fight off this beast, the new DeathOS's, 95 and NT were
>developed that could even bring down mighty Pentium systems. The future
>looks grim, can no one stop this plague?
>
>Unbeknowned to Darth Gates, on the planet Finlandia a young hacker named
>Linus has a vision. He decided that a 386 could be made to do something
>useful after all. And out of this vision came >>Linux<<!!! Drawing from
>the mystic Unix religion, this new OS was developed. Strong in the free
>side of the source, >>Linux<< only grew more and more powerful every day.
>Improved by hackers throughout the galaxy, and aided by strong flightless
>waterfowl the OS became a major fighting tool of the rebels. Hackers, which
>had been a dying breed, rallied behind >>Linux<< and the GNU project. ALL
>IS NOT LOST! THE GALAXY CHAFING UNDER DARTH GATES WILL RISE AGAIN!! THE
>BATTLE HAS BEGUN!!!!!! WHO WILL WIN??????
>
>To find out, watch for the upcoming OS Wars Trilogy, appearing soon in a
>theater near you.
>
>And, as always, MAY THE SOURCE BE WITH YOU.
>
>- --
>Jack
>
>------------------------------
>
>From: Pavel Machek <pavel@Elf.mj.gts.cz>
>Date: Sat, 18 Oct 1997 23:22:44 +0200
>Subject: Sys V message problems
>
>Hi!
>
>Kerneld_exit() is being called from exit.c. So far so good. But under
>some circumstances, it calls sys_msgctl() which in turn does
>lock_kernel(). Does not seem healthy to me. (What do you think?)
>
>Ayee: It seems to me like sys_msgctl( RMID ) may, and WILL sleep. I do
>not think it is healthy for kill -9-ed process to sleep. (Or is it
>acceptable to sleep? If so it will make my life easier).
>
> Pavel
>- --
>I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
>Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
>
>------------------------------
>
>From: a.giordano@flashnet.it
>Date: Sun, 19 Oct 1997 14:29:58 +0200 (MET DST)
>Subject: Re: Compiling the kernel with EGCS.
>
>Sorry!
>who is pgcc 971008 ?
>my E-mail is:
>a.giordano@flashnet.it
>
>On 18-Oct-97 Chris Powell wrote:
>>> Hi,
>>> I was just wondering if Bad Things(tm) would happen if I compiled the
>>> kernel with egcs and some high optimization level (Say for example, -O6,
>>> though I don't think there's any difference after -O3). I'm using the
very
>>> latest EGCS. Hmm, so, any comments?
>>
>>I compiled my kernel with pgcc 971008 -- a relative to egcs -- using -06
>>-mpentiumpro. My Byte Benchmark went from 45.7 to 49.3, with the most
>>significant shanges in pipe-based context switching and execl throughput.
>> I did this on the recommendation of the pgcc FAQ author; that is, the
>>author indicated that he was running an -O6 kernel with no problems.
>>
>>So far I have not seen any indication of bad things happening, and if I
>>did, I'm not certain I'd be able to distinguish a compiler error from a
>>2.1.x error. However, since this is on a machine I've designated as
>>experimental, it's not too critical.
>>
>>Regards,
>>Chris Powell
>>--
>>Christopher Powell Brick and Ivy Corporate Consulting
>>powell@brickandivy.com http://www.brickandivy.com/
>> -= A PGP key is available and gladly shared =-
>
>- ----------------------------------
>E-Mail: a.giordano@flashnet.it
>Date: 19-Oct-97
>Time: 14:29:58
>
>This message was sent by XFMail
>- ----------------------------------
>
>------------------------------
>
>From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
>Date: Sun, 19 Oct 1997 10:29:47 +0200 (MET DST)
>Subject: Re: serial input overrun(s) using ide-cd
>
>Albert D. Cahalan wrote:
>>
>> > Someone else replied that if we changed the default to enable
>> > interrupts during PIO, we would trash the filesystems of at
>> > least 10 users, reasoning that such a change would be very bad.
>> >
>> > 10 users??? TRASH THEM!!!
>> >
>> > Come on, people, if Linux has 5 million users like you folks claim,
>> > the cries of a few users who complain about trashed filesystems will
>> > be go unheard in the roar of approval from the large crowd thrilled
>> > with the fact that they no longer get serial overruns.
>>
>> Correct, but nobody wants to be responsible for trashed filesystems.
>>
>> If the IDE chipset is PCI, interrupts should be enabled.
>> PCI chipsets can be identified, which means we can have
>> a blacklist if needed.
>>
>> This issue makes FreeBSD look better in benchmarks.
>> Many benchmarkers will test an out-of-the box configuration.
>> The Apache web server was changed a bit to look better
>> when benchmarkers test that way. The same applies here.
>>
>> Linux 2.1 is an experimental series. People have been
>> warned about disk corruption. Kernel 2.1.44 was special...
>> If the default for PCI chipsets changes now, there is
>> enough time to construct a complete blacklist before 2.2.
>
>The answer is "user level" (I'm just reiterating Linus' remarks).
>
>Lets start with
>
>
>#!/bin/sh
>#
># Shell script to enable interrupts during PCI PIO transfers
># by R.E.Wolff@BitWizard.nl .
># With the appropriate wrapper, this can be run at boot-time.
># (for example if you have a runlevel editor, you could "cut the crap"
># and enable/disable this through the runlevel editor.)
>#
># Legalese: GPL. No Warranty. Please keep the attributions.
>#
>#
># Enable interrupts during the PIO transfer on PCI machines.
>#
>BLACKLIST=""
>#
>if grep -q IDE /proc/pci
> then
> bad=false
> for i in $BLACKLIST
> do
> if grep -q $i /proc/pci
> then
> bad=true
> fi
> done
> if [ $bad != true ]
> then
> for i in a b c d
> do
> hdparm -u 1 /dev/hd$i
> done
> fi
>fi
>#
>#
># People with non-pci IDE disks or a blacklisted device may enable
># interrupts by setting $I_KNOW_I_MIGHT_THRASH_MY_HARDDISK to "yes".
>#
>if [ "$I_KNOW_I_MIGHT_THRASH_MY_HARDDISK" = "yes" ]
> then
> for i in a b c d
> do
> hdparm -u 1 /dev/hd$i
> done
>fi
>
> Roger.
>
>
>- --
>** R.E.Wolff@BitWizard.nl ** +31-15-2137555 ** http://www.BitWizard.nl/ **
>Florida -- A 39 year old construction worker woke up this morning when a
>109-car freight train drove over him. According to the police the man was
>drunk. The man himself claims he slipped while walking the dog. 080897
>
>------------------------------
>
>From: Blu3Viper <david@127-0-0-1.kalifornia.com>
>Date: Sun, 19 Oct 1997 04:57:31 -0700 (PDT)
>Subject: Re: Fix for icmp.c for firewalling rules that return PORT_UNREACH
>
>On Sat, 18 Oct 1997, Alan Cox wrote:
>[snip]
>> Ok.. I agree there is an argument for being able to return various things.
>> Anyone care to contribute a "what icmp to return" sysctl.
>> Alan
>
>Alan, if I may..
>
> I feel this should be implemented as an optional flag for a firewall
>rule. I think it is important that people be given the capability to 'do
>the right thing' with their firewalls. It could simplify debugging a
>network jumble.
>
> Do the 'right thing' in the kernel by default but give the user the
>capability of tuning the response. Eventually old systems will be gone
>and the need to cooperate with them will be gone. Hardwiring code extends
>the life of such a situation.
>
> 2.1.x gives the opportunity to make such a change to the code and give
>people time to migrate to it of their own choice.
>
> Just my thoughts.
> -d
>
>[reply to: david@127-0-0-1.kalifornia.com without the 127-0-0-1.]
>*** *** Flames will go to /dev/null
>** WARNING ** SPAM mail will be returned to you at a
>*** *** minimum rate of 50,000 copies per email
>
>
>------------------------------
>
>From: Matthew Kirkwood <matthew.kirkwood@lmh.ox.ac.uk>
>Date: Sun, 19 Oct 1997 14:27:34 +0100 (BST)
>Subject: PLIP Performance.
>
>Hi,
>
>Having spent a few curious hours throwing together enough bits to boot
>a linux box and playing with PLIP/routing/IP masquerading/transparent
>proxying, etc, it became apparent that the performance of the PLIP link
>that was used to connect the odd box to our local subnet via another,
>ethernet/PLIP box, is surprisingly poor.
>
>Box A (with ethernet and plip) has been tried on 2.0.31 and 2.1.59 with
>all of the natty new parport stuff. It's a 430HX mobo (TMA?) and under
>2.1.59 is happy (or so it says) to use DMA for parport stuff.
>
>Box B (plip only) has an older mobo, not capable of dma, and hasn't yet
>been tried with 2.1.x kernels. Both of the combinations that have been
>tried have given about 30k/sec maximum ftp transfer rate, and have used
>around 20% CPU on both machines. (A == P120, B == P100).
>
>Similar hardware (and the same cable!) has been seen to achieve around
>100k/sec under Win95 DCC, so it seems certain that this isn't a hardware
>limitation.
>
>Reducing the MTU for the plip interfaces from 1500 reduced the CPU load,
>but only by reducing the plip throughput.
>
>Any ideas on this one gratefully received,
>Matthew.
>
>- --
>Matthew Kirkwood | Mail: matthew.kirkwood@lmh.ox.ac.uk
>LMH JCR, | Web: http://www-jcr.lmh.ox.ac.uk/~weejock/
>Oxford OX2 6QA, | PGP: finger weejock@ferret.lmh.ox.ac.uk
>England. |
>
>
>------------------------------
>
>From: Matthew Kirkwood <matthew.kirkwood@lmh.ox.ac.uk>
>Date: Sun, 19 Oct 1997 14:55:04 +0100 (BST)
>Subject: 2.1.59 compile probs (module symbols for _everything_ :-)
>
>Hi,
>
>After posting the last message, I ftp'd linux-2.1.59.tar.gz over to
>machine B (the plip only box) and compiled it all up, with suitable
>options. B has an IDE disk with RH4.2 installed, but is usually a
>second disk, so I ran "make zdisk". (lilo complained about boot
>signatures, and I didn't want to risk the partition table :-)
>
>Rebooting with this, I found that all modules are thoroughly and
>unutterably broken:
>
>[root@pc23 linux]# insmod parport
>kernel_version needed, but can't be found
>[root@pc23 linux]# insmod -f parport
>__this_module undefined
>kernel_version needed, but can't be found
>
>further investigations with other modules lead to:
>[root@pc23 linux]# insmod 8390
>kernel_version needed, but can't be found
>[root@pc23 linux]# insmod -f 8390
>create_module: Unknown error 1040154624
>[root@pc23 linux]# lsmod
>Module: #pages: Used by:
>8390 (uninitialised)
>[root@pc23 linux]# insmod parport
>Kernel symbol problem
>[root@pc23 linux]# insmod -f parport
>Kernel symbol problem
>[root@pc23 linux]# rmmod 8390
>[root@pc23 linux]# lsmod
>Module: #pages: Used by:
>[root@pc23 linux]#
>
>At this stage I become glad that paranoia led me to compile floppy support
>statically.
>
>I guess that it must be because make zdisk is somehow screwy, but I
>wouldn't like to bet on it.
>
>Ideas?
>
>Matthew
>
>- --
>Matthew Kirkwood | Mail: matthew.kirkwood@lmh.ox.ac.uk
>LMH JCR, | Web: http://www-jcr.lmh.ox.ac.uk/~weejock/
>Oxford OX2 6QA, | PGP: finger weejock@ferret.lmh.ox.ac.uk
>England. |
>
>
>
>------------------------------
>
>From: "Patrick St. Jean" <psj@cgmlarson.com>
>Date: Sun, 19 Oct 1997 09:49:43 -0500 (CDT)
>Subject: Re: Patch for Spellcast ISDN driver in 2.1.59
>
>On Sun, 19 Oct 1997, Russell Coker - mailing lists account wrote:
>
>> The following patch makes the Spellcast ISDN driver compile in 2.1.59.
>> I don't have the hardware to test this, but the patch shouldn't do any harm
>> as it makes no functional changes.
>>
>
>Y'all might just want to forget about the spellcaster driver. Erik is
>writing a new one called "babylon" that obsoletes this one... I'm beta
>testing it right now.
>
>Pat
>
>- --
>+--------------------------------------------------------------------------
--+
>| Patrick St. Jean '97 XLH 883
psj@cgmlarson.com |
>| Programmer & Systems Administrator +1 713-977-4177
x106 |
>| Larson Software Technology
http://www.cgmlarson.com |
>+--------------------------------------------------------------------------
--+
>
>
>
>------------------------------
>
>From: nm <nmanisca@vt.edu>
>Date: Sun, 19 Oct 1997 10:55:07 -0500
>Subject: Clustering
>
>does any clustering software exist for linux?
>or for any other free unices for that matter?
>
>anyone have an idea on how much work would be
>involved in adding clustering support here?
>
>thanks
>nick
>
>------------------------------
>
>From: linux kernel account <linker@nightshade.z.ml.org>
>Date: Sun, 19 Oct 1997 11:05:49 -0400 (EDT)
>Subject: Re: Kernel compiles with egcs
>
>On Sun, 19 Oct 1997, Henrik Storner wrote:
>
>> Don't know. I (obviously) haven't tried it on an SMP system. But yes, your
>> numbers do seem to be rather slow - we are comparing the unixbench 4.0.1
>> numbers ? Not the older BYTE benchmarks.
>
>That would be it then.. Mind telling me where I can get unixbench?? It
>would be nice if the benchmarks gave differnt looking scores..
>
>
>------------------------------
>
>From: linux kernel account <linker@nightshade.z.ml.org>
>Date: Sun, 19 Oct 1997 11:08:48 -0400 (EDT)
>Subject: Re: serial input overrun(s) using ide-cd
>
>On Sun, 19 Oct 1997, Rogier Wolff wrote:
>
>> The answer is "user level" (I'm just reiterating Linus' remarks).
>>
>> Lets start with
>[Snip neat script]
>
>Ohhh.. Ahhhhh.. Eeee.. Ohhhh...
>
>That was cool.. I'm sold.
>
>
>------------------------------
>
>From: Peter Enderborg <pme@ufh.se>
>Date: Sun, 19 Oct 1997 17:25:47 +0200
>Subject: Serial Console and X11 ?
>
>Im trying to get my linux system to run with the console on terminal.
>(A other Linux, and pick up Oops output and put it to a file.)
>But when I compile linux with
>
>#
># Character devices
>#
>CONFIG_VT=y
># CONFIG_VT_CONSOLE is not set
>CONFIG_SERIAL=y
>CONFIG_SERIAL_EXTENDED=y
># CONFIG_SERIAL_MANY_PORTS is not set
>CONFIG_SERIAL_SHARE_IRQ=y
># CONFIG_SERIAL_MULTIPORT is not set
># CONFIG_HUB6 is not set
>CONFIG_SERIAL_CONSOLE=y
># CONFIG_SERIAL_NONSTANDARD is not set
>CONFIG_MOUSE=y
># CONFIG_ATIXL_BUSMOUSE is not set
># CONFIG_BUSMOUSE is not set
># CONFIG_MS_BUSMOUSE is not set
>CONFIG_PSMOUSE=y
># CONFIG_82C710_MOUSE is not set
># CONFIG_PC110_PAD is not set
># CONFIG_QIC02_TAPE is not set
># CONFIG_FTAPE is not set
># CONFIG_APM is not set
># CONFIG_WATCHDOG is not set
>CONFIG_RTC=y
># CONFIG_NVRAM is not set
># CONFIG_JOYSTICK is not set
>
>I cant start X with the error message that it can't find any free VT.
>System:
>Kernel 2.1.57 on a intel pentium and millenium graphics.
>
>- --
>foo!
>
>------------------------------
>
>From: Xavier Leroy <Xavier.Leroy@inria.fr>
>Date: Sun, 19 Oct 1997 17:28:37 +0200 (MET DST)
>Subject: problem with exec() and clone(CLONE_SIGHAND)
>
>I'm resending below an updated version of a patch I submitted to this
>list a few months ago.
>
>The patch fixes a nasty problem with execve() when the calling process
>is sharing its signal handlers with other processes, via the
>CLONE_SIGHAND option to clone(). Namely, the signal handler table
>remains shared even after the process that calls execve() has started
>to execute the new program.
>
>This has plenty of amusing consequences. For instance, if the new
>program installs a signal handler, then the same signal handler will
>be installed in other processes *that are not running the same code*.
>Nice crash when one of the other processes receives the signal and
>tries to call a function at a code adress meaningless in that process.
>
>The patch below fixes the problem by making a private copy of the
>signal handler table at execve() time in case it's shared.
>
>It also turns the "oom" in exec_mmap into a regular ENOMEM error which
>is then reported to the caller of execve() as it should. That was
>marked as a "FIXME" in the kernel sources.
>
>The patch is against 2.1.58. The unsharing of signal handlers has
>been tested relatively well, but the oom()/ENOMEM error hasn't (it's kind of
>hard to cause the error!).
>
>The problem with execve() described in this message is really serious
>for any program that uses clone() with the CLONE_SIGHAND option,
>e.g. all programs using my LinuxThreads library, since it makes it
>essentially impossible to do execve() in these programs reliably.
>I therefore hope that this problem will be fixed in the 2.2 series.
>
>- - Xavier Leroy
>
>diff -u -r linux-2.1.58-orig/arch/mips/kernel/irixelf.c
linux-2.1.58/arch/mips/kernel/irixelf.c
>- --- linux-2.1.58-orig/arch/mips/kernel/irixelf.c Thu Jul 31 22:09:17 1997
>+++ linux-2.1.58/arch/mips/kernel/irixelf.c Sat Oct 18 14:24:05 1997
>@@ -683,9 +683,12 @@
> }
> }
>
>- - /* OK, This is the point of no return. */
>- - flush_old_exec(bprm);
>+ /* Flush all traces of the currently running executable */
>+ retval = flush_old_exec(bprm);
>+ if (retval)
>+ return retval;
>
>+ /* OK, This is the point of no return */
> current->mm->end_data = 0;
> current->mm->end_code = 0;
> current->mm->start_mmap = ELF_START_MMAP;
>diff -u -r linux-2.1.58-orig/arch/sparc64/kernel/binfmt_aout32.c
linux-2.1.58/arch/sparc64/kernel/binfmt_aout32.c
>- --- linux-2.1.58-orig/arch/sparc64/kernel/binfmt_aout32.c Thu Jul 17
04:22:50 1997
>+++ linux-2.1.58/arch/sparc64/kernel/binfmt_aout32.c Sat Oct 18 14:24:05 1997
>@@ -256,6 +256,7 @@
> unsigned long p = bprm->p;
> unsigned long fd_offset;
> unsigned long rlim;
>+ int retval;
>
> ex = *((struct exec *) bprm->buf); /* exec-header */
> if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != OMAGIC &&
>@@ -278,8 +279,12 @@
> if (ex.a_data + ex.a_bss > rlim)
> return -ENOMEM;
>
>+ /* Flush all traces of the currently running executable */
>+ retval = flush_old_exec(bprm);
>+ if (retval)
>+ return retval;
>+
> /* OK, This is the point of no return */
>- - flush_old_exec(bprm);
> memcpy(¤t->tss.core_exec, &ex, sizeof(struct exec));
>
> current->mm->end_code = ex.a_text +
>diff -u -r linux-2.1.58-orig/fs/binfmt_aout.c linux-2.1.58/fs/binfmt_aout.c
>- --- linux-2.1.58-orig/fs/binfmt_aout.c Sat Oct 18 13:56:17 1997
>+++ linux-2.1.58/fs/binfmt_aout.c Sat Oct 18 14:24:05 1997
>@@ -306,6 +306,7 @@
> unsigned long p = bprm->p;
> unsigned long fd_offset;
> unsigned long rlim;
>+ int retval;
>
> ex = *((struct exec *) bprm->buf); /* exec-header */
> if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != OMAGIC &&
>@@ -341,8 +342,12 @@
> if (ex.a_data + ex.a_bss > rlim)
> return -ENOMEM;
>
>+ /* Flush all traces of the currently running executable */
>+ retval = flush_old_exec(bprm);
>+ if (retval)
>+ return retval;
>+
> /* OK, This is the point of no return */
>- - flush_old_exec(bprm);
> #ifdef __sparc__
> memcpy(¤t->tss.core_exec, &ex, sizeof(struct exec));
> #endif
>diff -u -r linux-2.1.58-orig/fs/binfmt_elf.c linux-2.1.58/fs/binfmt_elf.c
>- --- linux-2.1.58-orig/fs/binfmt_elf.c Sat Oct 18 13:56:17 1997
>+++ linux-2.1.58/fs/binfmt_elf.c Sat Oct 18 14:24:05 1997
>@@ -584,9 +584,12 @@
> }
> }
>
>- - /* OK, This is the point of no return */
>- - flush_old_exec(bprm);
>+ /* Flush all traces of the currently running executable */
>+ retval = flush_old_exec(bprm);
>+ if (retval)
>+ return retval;
>
>+ /* OK, This is the point of no return */
> current->mm->end_data = 0;
> current->mm->end_code = 0;
> current->mm->start_mmap = ELF_START_MMAP;
>diff -u -r linux-2.1.58-orig/fs/exec.c linux-2.1.58/fs/exec.c
>- --- linux-2.1.58-orig/fs/exec.c Sat Oct 18 13:56:17 1997
>+++ linux-2.1.58/fs/exec.c Sat Oct 18 16:41:40 1997
>@@ -427,16 +427,34 @@
> current->mm = old_mm;
> mmput(mm);
>
>- - /*
>- - * N.B. binfmt_xxx needs to handle the error instead of oom()
>- - */
> fail_nomem:
>- - /* this is wrong, I think. */
>- - oom(current);
> return retval;
> }
>
> /*
>+ * This function makes sure the current process has its own signal table,
>+ * so that flush_old_signals can later reset the signals without disturbing
>+ * other processes. (Other processes might share the signal table via
>+ * the CLONE_SIGHAND option to clone().)
>+ */
>+
>+static inline int make_private_signals(void)
>+{
>+ struct signal_struct * newsig;
>+
>+ if (atomic_read(¤t->sig->count) <= 1)
>+ return 0;
>+ newsig = kmalloc(sizeof(*newsig), GFP_KERNEL);
>+ if (newsig == NULL)
>+ return -ENOMEM;
>+ spin_lock_init(&newsig->siglock);
>+ atomic_set(&newsig->count, 1);
>+ memcpy(newsig->action, current->sig->action, sizeof(newsig->action));
>+ current->sig = newsig;
>+ return 0;
>+}
>+
>+/*
> * These functions flushes out all traces of the currently running
executable
> * so that a new one can be started
> */
>@@ -476,18 +494,24 @@
> }
> }
>
>- -void flush_old_exec(struct linux_binprm * bprm)
>+int flush_old_exec(struct linux_binprm * bprm)
> {
> char * name;
> int i, ch, retval;
>+ struct signal_struct * oldsig;
>+
>+ /*
>+ * Make sure we have a private signal table
>+ */
>+ oldsig = current->sig;
>+ retval = make_private_signals();
>+ if (retval) goto flush_failed;
>
> /*
>- - * Release all of the old mmap stuff ... do this first
>- - * so we can bail out on failure.
>+ * Release all of the old mmap stuff
> */
> retval = exec_mmap();
>- - if (retval)
>- - goto out;
>+ if (retval) goto flush_failed;
>
> if (current->euid == current->uid && current->egid == current->gid)
> current->dumpable = 1;
>@@ -509,8 +533,12 @@
>
> flush_old_signals(current->sig);
> flush_old_files(current->files);
>- -out:
>- - return; /* retval; FIXME. */
>+
>+ return 0;
>+
>+flush_failed:
>+ current->sig = oldsig;
>+ return retval;
> }
>
> /*
>diff -u -r linux-2.1.58-orig/include/linux/binfmts.h
linux-2.1.58/include/linux/binfmts.h
>- --- linux-2.1.58-orig/include/linux/binfmts.h Wed Oct 15 03:29:27 1997
>+++ linux-2.1.58/include/linux/binfmts.h Sat Oct 18 14:12:54 1997
>@@ -58,7 +58,7 @@
> extern int prepare_binprm(struct linux_binprm *);
> extern void remove_arg_zero(struct linux_binprm *);
> extern int search_binary_handler(struct linux_binprm *,struct pt_regs *);
>- -extern void flush_old_exec(struct linux_binprm * bprm);
>+extern int flush_old_exec(struct linux_binprm * bprm);
> extern unsigned long setup_arg_pages(unsigned long p, struct linux_binprm
* bprm);
> extern unsigned long copy_strings(int argc,char ** argv,unsigned long *page,
> unsigned long p, int from_kmem);
>
>------------------------------
>
>From: James Mastros <root@jennifer-unix.dyn.ml.org>
>Date: Sun, 19 Oct 1997 11:51:30 -0400 (EDT)
>Subject: Re: A new tree?
>
>On 19 Oct 1997, Bruce Murphy wrote:
>> linux kernel account <linker@nightshade.z.ml.org> writes:
>> > On Sat, 18 Oct 1997, John Kelly wrote:
>> > > The day Linus GPLed the code, he abdicated ownership of it. Since the
>> > > code is GPL freely available, any group of developers unhappy with the
>> > > status quo can branch off and start their own movement, calling it
>> > > Xunil or whatever they prefer, as long as they don't infringe upon the
>> > > "Linux" trademark Linus recently won.
>> >
>> > Is this correct? Does Linus have a trademark? If so, is then some
>> > paperwork that says that he is only holding it to prevent others, or can
>> > he decide to put all the linux compaines out of bussiness should bill
>> > gates posses his soul.. I dont know Linus personally, but from what I've
>> > seen here and read, I do trust him 100%, but this might not give some
>> > people a good feeling as they havn't seen what a cool guy Linus
happens to
>> > be...
>>
>> I point out that we could always go back to Lignux if that did happen.
>> I'm sure Stallman wouldn't smirk *too* much...
>>
>> Packrat (BSc/BE;COSO;Wombat II Designer)
>
>Naha... "The OS Formerly Known as Linux", AKA Tofkl!
>
> -=- James Mastros
>
>Getting more off-topic by the bit.
>- ---
>Now that Compaq has bought Tandem, are they going to call the company Tampaq
>or Comdem?
>
>
>------------------------------
>
>From: R.E.Wolff@bitwizard.nl (Rogier Wolff)
>Date: Sun, 19 Oct 1997 17:46:17 +0200 (MET DST)
>Subject: Re: Fix for icmp.c for firewalling rules that return PORT_UNREACH
>
>Mail Delivery Subsystem wrote:
>>From MAILER-DAEMON@dutecai.et.tudelft.nl Sun Oct 19 17:30:15 1997
>X-POP3-Rcpt: t757607@helium
>Date: Sun, 19 Oct 1997 04:06:38 -0700
>From: Mail Delivery Subsystem <MAILER-DAEMON@transmeta.com>
>Message-Id: <199710191106.EAA23277@neon.transmeta.com>
>To: <wolff@bitwizard.nl>
>Mime-Version: 1.0
>Content-Type: multipart/report; report-type=delivery-status;
> boundary="EAA23277.877259198/neon.transmeta.com"
>Subject: Returned mail: User unknown
>Auto-Submitted: auto-generated (failure)
>
>This is a MIME-encapsulated message
>
>- --EAA23277.877259198/neon.transmeta.com
>
>The original message was received at Sun, 19 Oct 1997 04:06:37 -0700
>from root@neosilicon.transmeta.com [206.184.214.14]
>
> ----- The following addresses had permanent fatal errors -----
><submit-linux-dev-kernel@transmeta.com>
>
> ----- Transcript of session follows -----
>... while talking to [10.1.1.79]:
>>>> RCPT To:<submit-linux-dev-kernel@transmeta.com>
><<< 550 <submit-linux-dev-kernel@transmeta.com>... User unknown
>550 <submit-linux-dev-kernel@transmeta.com>... User unknown
>
>- --EAA23277.877259198/neon.transmeta.com
>Content-Type: message/delivery-status
>
>Reporting-MTA: dns; neon.transmeta.com
>Received-From-MTA: DNS; neosilicon.transmeta.com
>Arrival-Date: Sun, 19 Oct 1997 04:06:37 -0700
>
>Final-Recipient: RFC822; submit-linux-dev-kernel@transmeta.com
>Action: failed
>Status: 5.1.1
>Remote-MTA: DNS; [10.1.1.79]
>Diagnostic-Code: SMTP; 550 <submit-linux-dev-kernel@transmeta.com>... User
unknown
>Last-Attempt-Date: Sun, 19 Oct 1997 04:06:38 -0700
>
>- --EAA23277.877259198/neon.transmeta.com
>Content-Type: message/rfc822
>
>Return-Path: <wolff@BitWizard.nl>
>Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com
[206.184.214.14])
> by neon.transmeta.com (8.8.5/8.8.4) with ESMTP
> id EAA23275; Sun, 19 Oct 1997 04:06:37 -0700
>Received: from rosie.BitWizard.nl (rotterdam-049.std.pop.tip.nl
[195.18.72.51])
> by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id EAA06145;
> Sun, 19 Oct 1997 04:00:55 -0700
>Received: from cave.BitWizard.nl (wolff@cave.BitWizard.nl [130.161.127.248])
> by rosie.BitWizard.nl (8.8.5/8.8.5) with ESMTP id KAA13670;
> Sun, 19 Oct 1997 10:32:46 +0200
>Received: (from wolff@localhost) by cave.BitWizard.nl (8.8.5/8.7.3) id
KAA01079; Sun, 19 Oct 1997 10:42:25 +0200
>Message-Id: <199710190842.KAA01079@cave.BitWizard.nl>
>Subject: Re: Fix for icmp.c for firewalling rules that return PORT_UNREACH
>To: hpa@transmeta.com
>Date: Sun, 19 Oct 1997 10:42:25 +0200 (MET DST)
>Cc: submit-linux-dev-kernel@transmeta.com
>In-Reply-To: <62ba3q$2pb$1@palladium.transmeta.com> from "H. Peter Anvin"
at Oct 18, 97 09:35:54 pm
>From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
>Content-Type: text
>
>H. Peter Anvin wrote:
>>
>> Followup to:
<Pine.LNX.3.96.971017175956.11682f-100000@kinison.healthway.net>
>> By author: Evan Harris <eharris@puremagic.com>
>> In newsgroup: linux.dev.kernel
>> >
>> > Personally, I'd rather return PORT_UNREACH and fake the senders
address to
>> > look like it comes from the original destination machine, because then it
>> > is not readily apparent that there even _is_ a firewall, instead it just
>> > looks like the machine isn't listening for traffic on that port.
>> >
>>
>> This seems like the Right Thing[TM], to do, as in effect the firewall
>> is responding _in_lieu_ of the host. There is no functional
>
>You would also have to delay the result and change the ttl counters
>to reflect the missing hops. Otherwise you're just obfuscating
>the issue.
>
>The fact that there IS a firewall is not something that is easily
>hidden. "whois" allows me to find out how many IP numbers they have
>reserved. If services like "FTP", "echo", "telnet" and many others for
>a great many IP numbers inside the known range get the same response,
>it is easy to conclude that there is a firewall.
>
>I'd say that simply doing what the RFCs intended (sending
>"adminstratively prohibited") is the "right thing".
>
>
> Roger.
>
>- --
>** R.E.Wolff@BitWizard.nl ** +31-15-2137555 ** http://www.BitWizard.nl/ **
>Florida -- A 39 year old construction worker woke up this morning when a
>109-car freight train drove over him. According to the police the man was
>drunk. The man himself claims he slipped while walking the dog. 080897
>
>- --EAA23277.877259198/neon.transmeta.com--
>
>
>
>
>- --
>** R.E.Wolff@BitWizard.nl ** +31-15-2137555 ** http://www.BitWizard.nl/ **
>Florida -- A 39 year old construction worker woke up this morning when a
>109-car freight train drove over him. According to the police the man was
>drunk. The man himself claims he slipped while walking the dog. 080897
>
>------------------------------
>
>From: "Russell Coker - mailing lists account" <bofh@snoopy.virtual.net.au>
>Date: Mon, 20 Oct 97 02:02:14 +1100
>Subject: Re: Patch for Spellcast ISDN driver in 2.1.59
>
>>> The following patch makes the Spellcast ISDN driver compile in 2.1.59.
>>> I don't have the hardware to test this, but the patch shouldn't do any
harm
>>> as it makes no functional changes.
>>>
>
>>Y'all might just want to forget about the spellcaster driver. Erik is
>>writing a new one called "babylon" that obsoletes this one... I'm beta
>>testing it right now.
>
> Maybe, but as long as it's in the kernel then it should work to some
>degree IMHO.
>
> How long until babylon becomes one of the seven wonders of the Linux
>world?
>
>- --
>- -----------------------------------------------------------
>In return for "mailbag contention" errors from buggy Exchange
>servers I'll set my mail server to refuse mail from your domain.
>The same response applies when a message to a postmaster
>account bounces.
>"Russell Coker - mailing lists account" <bofh@snoopy.virtual.net.au>
>- -----------------------------------------------------------
>
>
>------------------------------
>
>From: "Patrick St. Jean" <psj@cgmlarson.com>
>Date: Sun, 19 Oct 1997 11:24:06 -0500 (CDT)
>Subject: Re: Patch for Spellcast ISDN driver in 2.1.59
>
>On Mon, 20 Oct 1997, Russell Coker - mailing lists account wrote:
>> Maybe, but as long as it's in the kernel then it should work to some
>> degree IMHO.
>>
>> How long until babylon becomes one of the seven wonders of the Linux
>> world?
>>
>
>I'm not really sure, but it's getting there. I'm having a little trouble
>with it. When I go to dial out it locks the machine hard, but Erik and I
>are working on it... Should be seeing that go away in a couple days. The
>babylon driver is out of alpha and is now in public beta. If you've got a
>spellcaster card, give it a try!
>
> Pat
>
>- --
>+--------------------------------------------------------------------------
--+
>| Patrick St. Jean '97 XLH 883
psj@cgmlarson.com |
>| Programmer & Systems Administrator +1 713-977-4177
x106 |
>| Larson Software Technology
http://www.cgmlarson.com |
>+--------------------------------------------------------------------------
--+
>
>
>------------------------------
>
>From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
>Date: 19 Oct 1997 18:29:55 +0200
>Subject: 2.0.31: compile error for arch/i386/boot/compressed/misc.c
>
>Compiling 2.0.31 with a recent glibc 2.1 snapshot I got the following error:
>gcc -D__KERNEL__ -I/usr/src/linux-2.0.31/include -O2 -DSTDC_HEADERS -c
misc.c -o misc.o
>misc.c:215: parse error before `__extension__'
>misc.c:215: parse error before `size_t'
>misc.c:215: conflicting types for `__bzero'
>/usr/include/string.h:205: previous declaration of `__bzero'
>misc.c:215: warning: data definition has no type or storage class
>misc.c:215: warning: data definition has no type or storage class
>misc.c:215: parse error before `}'
>misc.c:218: `s' undeclared here (not in a function)
>misc.c:220: parse error before `for'
>
>The problem seems to be that misc.c includes <string.h>[1] - and since
>the recent glibc 2.1 snapshot now has inline functions, misc.c doesn't
>compile.:-(
>
>I think that misc.c in 2.0.x should be changed similiar to the way it
>has been changed in 2.1.x (remove #include <string.h>, change __ptr_t
>to void *, see patch below).
>
>I would advise everybody making a _distribution_ to change this,
>otherwise you've get lot's of complains when glibc 2.1 will be out.
>
>Andreas
>
>Footnotes:
>[1] What are user-level defines doing in kernel files?:-(.
>
>- --- linux-2.0.30/arch/i386/boot/compressed/misc.c Mon Jul 15 12:47:39 1996
>+++ linux-2.0.31/arch/i386/boot/compressed/misc.c Sun Oct 19 18:28:01 1997
>@@ -9,10 +9,9 @@
> * High loaded stuff by Hans Lermen & Werner Almesberger, Feb. 1996
> */
>
>- -#include <string.h>
>- -
> #include <asm/segment.h>
> #include <asm/io.h>
>+#include <linux/types.h>
>
> /*
> * gzip declarations
>@@ -21,8 +20,13 @@
> #define OF(args) args
> #define STATIC static
>
>+void* memset(void* s, int c, size_t n);
>+void* memcpy(void* __dest, __const void* __src,
>+ size_t __n);
>+
> #define memzero(s, n) memset ((s), 0, (n))
>
>+
> typedef unsigned char uch;
> typedef unsigned short ush;
> typedef unsigned long ulg;
>@@ -113,7 +117,6 @@
> static void gzip_mark(void **);
> static void gzip_release(void **);
>
>- -#ifndef STANDALONE_DEBUG
> static void puts(const char *);
>
> extern int end;
>@@ -212,7 +215,7 @@
> outb_p(0xff & (pos >> 1), vidport+1);
> }
>
>- -__ptr_t memset(__ptr_t s, int c, size_t n)
>+void* memset(void* s, int c, size_t n)
> {
> int i;
> char *ss = (char*)s;
>@@ -220,7 +223,7 @@
> for (i=0;i<n;i++) ss[i] = c;
> }
>
>- -__ptr_t memcpy(__ptr_t __dest, __const __ptr_t __src,
>+void* memcpy(void* __dest, __const void* __src,
> size_t __n)
> {
> int i;
>@@ -228,7 +231,6 @@
>
> for (i=0;i<__n;i++) d[i] = s[i];
> }
>- -#endif
>
> /*
===========================================================================
> * Fill the input buffer. This is called only when the buffer is empty
>@@ -308,33 +310,6 @@
> short b;
> } stack_start = { & user_stack [STACK_SIZE] , KERNEL_DS };
>
>- -#ifdef STANDALONE_DEBUG
>- -
>- -static void gzip_mark(void **ptr)
>- -{
>- -}
>- -
>- -static void gzip_release(void **ptr)
>- -{
>- -}
>- -
>- -char output_buffer[1024 * 800];
>- -
>- -int
>- -main(argc, argv)
>- - int argc;
>- - char **argv;
>- -{
>- - output_data = output_buffer;
>- -
>- - makecrc();
>- - puts("Uncompressing Linux...");
>- - gunzip();
>- - puts("done.\n");
>- - return 0;
>- -}
>- -
>- -#else
>
> void setup_normal_output_buffer()
> {
>@@ -396,8 +371,3 @@
> if (high_loaded) close_output_buffer_if_we_run_high(mv);
> return high_loaded;
> }
>- -#endif
>- -
>- -
>- -
>- -
>
>- --
> Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
> for pgp-key finger ajaeger@alma.student.uni-kl.de
> http://www.student.uni-kl.de/~ajaeger/
>
>------------------------------
>
>From: Camerlingo Gianluca <luccam@inopera.it>
>Date: Tue, 14 Oct 1997 20:59:05 +0000
>Subject: Re: ULTRA DMA HDD
>
>- ----------
>> From: Eirik Mikkelsen <eirikmik@stud.ntnu.no>
>> To: "Nicholas J. Leon" <nicholas@slac.com>
>> CC: Tim Hawes <thawes@dma.org>, Boris
><boris@oakton.edu>,linux-kernel@vger.rutgers.edu,
>linux-config@vger.rutgers.edu
>> Subject: Re: ULTRA DMA HDD
>> Date: Sat, 4 Oct 1997 17:25:21 +0200 (MET DST)
>>
>>On Sat, 4 Oct 1997, Nicholas J. Leon wrote:
>>
>>> >Your Linux swap partition should not be any larger than 16 MB. You can
>set
>>> >up two swap partitions for Linux, or more if you feel you will need
>them.
>>> >I think the limit is 8 swap partitions.
>>>
>>> Why? (why no larger than 16) ?
>>
>>This is not true anymore (hasn't been for a looong while). Very old
>>kernels only supported 16 Mb SWAP, but now it supports up to 128 MB (and
>>16 of those - 2Gb should be enough for most people).
>>
>>
>>Eirik Mikkelsen - eirikmik@stud.ntnu.no
>>
>hello ereybody I would like to know wich kernels ?
>luca camerlingo- italiy -luccam@inopera.it -www.inopera.it/~luccam/
>
>------------------------------
>
>From: Robin Cutshaw <robin@intercore.com>
>Date: Sun, 19 Oct 1997 13:18:54 -0400
>Subject: Re: Linux 2.0.31 (de4x5 driver failure)
>
>On Fri, Oct 17, 1997 at 03:29:58PM -0700, Linus Torvalds wrote:
>>
>> Ok, enought beating about the bush, it's up there now.
>>
>
>...and it doesn't work with the dec DE500-XA pci ethernet adapter
>in 100Mb/s mode. 2.0.30 works fine.
>
>robin
>- --
>- ----
>Robin Cutshaw internet: robin@interlabs.com robin@intercore.com
>Internet Labs, Inc. BellNet: 404-817-9787 robin@XFree86.Org
>
> "Time is just one damn thing after another" -- PBS/Nova
>- ----
>- --
>
>------------------------------
>
>From: miquels@cistron.nl (Miquel van Smoorenburg)
>Date: 19 Oct 1997 19:26:32 +0200
>Subject: Re: Serial Console and X11 ?
>
>In article <344A267B.763D69F7@ufh.se>, Peter Enderborg <pme@ufh.se> wrote:
>>Im trying to get my linux system to run with the console on terminal.
>>(A other Linux, and pick up Oops output and put it to a file.)
>>
>>I cant start X with the error message that it can't find any free VT.
>>System:
>>Kernel 2.1.57 on a intel pentium and millenium graphics.
>
>That's because /dev/tty0 and /dev/console are the same at the moment. If
>you turn on the serial console, /dev/console is not the VT console anymore.
>
>My serial console patch solves this by seperating /dev/console and /dev/tty0.
>The X server should use /dev/tty0, obviously. See
>ftp://ftp.cistron.nl/pub/people/miquels/kernel/ for the patch. It is
>for 2.1.44, but the README there tells you where to get a patch for
>current 2.1.x kernels.
>
>Mike.
>- --
> Miquel van | Cistron Internet Services -- Alphen aan den Rijn.
> Smoorenburg, | mailto:info@cistron.nl http://www.cistron.nl/
>miquels@cistron.nl | PTT's Het Net: Surfen in de gootsteen!
>
>------------------------------
>
>From: Tomasz Motylewski <motyl@stan.chemie.unibas.ch>
>Date: Sun, 19 Oct 1997 20:22:48 +0200 (MET DST)
>Subject: Re: UPDATE: GP in proc_lookupfd with pre-patch-2.0.31-10
>
>On Tue, 14 Oct 1997, Gordon Oliver wrote:
>
>> you should try the patch I just sent to the list... It should fix an
OOPS in lookup_fd
>> in the proc code. From the OOPS you sent, it looks like the spot.
>>
>
>Yes, it has fixed the problem. It looks like your patch is not included in
>2.0.31. I have sent it to Russell Berry <russ@berrex.com>, who has reported
>GP in xamixer, and it has also fixed that. What is strange, I have tried his
>xamixer here (RedHat 4.2 with upgrades, libc.so.5.4.23) and clean 2.0.31
>kernel and did not get the GP. May be it is also library problem (the machine
>I was running the fuser and got GP had some older libc.so.5).
>
>- --
>Tomasz Motylewski
>
>
>------------------------------
>
>From: "Roy P. Turner" <ecstasy@dopamine.com>
>Date: Sun, 19 Oct 1997 13:25:05 -0500
>Subject: Re: Linux 2.0.31 (de4x5 driver failure)
>
>In message <19971019131854.18987@num1sun.intercore.com>, Robin Cutshaw
writes:
>> On Fri, Oct 17, 1997 at 03:29:58PM -0700, Linus Torvalds wrote:
>> >
>> > Ok, enought beating about the bush, it's up there now.
>> >
>>
>> ...and it doesn't work with the dec DE500-XA pci ethernet adapter
>> in 100Mb/s mode. 2.0.30 works fine.
>>
>
>Same here and I also concur that 2.0.30 works fine.
>
>Roy
>
>------------------------------
>
>From: "Patrick St. Jean" <psj@cgmlarson.com>
>Date: Sun, 19 Oct 1997 13:58:23 -0500 (CDT)
>Subject: Re: Patch for Spellcast ISDN driver in 2.1.59
>
>On Mon, 20 Oct 1997, Russell Coker - mailing lists account wrote:
>> I don't have a Spellcaster card so I can't test it, however it probably
>> would have been handy if you'd included some info on how to download it for
>> those who do.
>>
>
>Duh! It's the weekend and I'm wishing I was on my Harley instead of
>working...
>
>ftp://ftp.spellcast.com/pub/babylon
>
>I'll shut up now!
> Pat
>
>- --
>+--------------------------------------------------------------------------
--+
>| Patrick St. Jean '97 XLH 883
psj@cgmlarson.com |
>| Programmer & Systems Administrator +1 713-977-4177
x106 |
>| Larson Software Technology
http://www.cgmlarson.com |
>+--------------------------------------------------------------------------
--+
>
>
>
>------------------------------
>
>From: thospel@mail.dma.be
>Date: 19 Oct 1997 19:10:43 -0000
>Subject: Re: PLIP Performance.
>
>In article <Pine.LNX.3.95.971019135737.10802C-100000@ferret.lmh.ox.ac.uk>,
> "Matthew Kirkwood" <matthew.kirkwood@lmh.ox.ac.uk> writes:
>> Hi,
>>
>> Having spent a few curious hours throwing together enough bits to boot
>> a linux box and playing with PLIP/routing/IP masquerading/transparent
>> proxying, etc, it became apparent that the performance of the PLIP link
>> that was used to connect the odd box to our local subnet via another,
>> ethernet/PLIP box, is surprisingly poor.
>>
>> Box A (with ethernet and plip) has been tried on 2.0.31 and 2.1.59 with
>> all of the natty new parport stuff. It's a 430HX mobo (TMA?) and under
>> 2.1.59 is happy (or so it says) to use DMA for parport stuff.
>>
>> Box B (plip only) has an older mobo, not capable of dma, and hasn't yet
>> been tried with 2.1.x kernels. Both of the combinations that have been
>> tried have given about 30k/sec maximum ftp transfer rate, and have used
>> around 20% CPU on both machines. (A == P120, B == P100).
>>
>> Similar hardware (and the same cable!) has been seen to achieve around
>> 100k/sec under Win95 DCC, so it seems certain that this isn't a hardware
>> limitation.
>>
>> Reducing the MTU for the plip interfaces from 1500 reduced the CPU load,
>> but only by reducing the plip throughput.
>>
>> Any ideas on this one gratefully received,
>> Matthew.
>>
>go to the file /drivers/net/plip.c, and edit the functions plip_receive
>and plip_send by removing the
> udelay(PLIP_DELAY_UNIT);
>lines. They are completely useless and just slow things down (there is just
>a little influence on interrupt latency, since interrupts will tend to
come in
>during a (slow) IO instruction, not during a (fast) nop). If you have a
BIOS on
>which you can set the IO-speed, it's worth setting that as high as
possible too
>(as long as everything keeps working of course. In my experience it's
>usually the floppy drive that determines how fast you can set the IO-speed).
>
>This should give you an easy 100K/sec
>
>You can even get more speed by optimising for the case that consecutive
>nibbles are the same since you don't have to change these bits then. A next
>step is unrolling some loops and using assembler so the port address
>doesn't get loaded each time. This can gain you another 15%, but you have
>to change the code of plip.c quite a bit to get that.
>
> Ton
>.
>
>
>------------------------------
>
>From: Pavel Machek <pavel@Elf.mj.gts.cz>
>Date: Sun, 19 Oct 1997 12:19:52 +0200
>Subject: Re: pread/pwrite patch
>
>Hi!
>
>> Appended is a patch off of DaveM's most recent snapshot with the
>> VFS changes needed to implement Single Unix's pread and pwrite.
>>
>> I've done probably 3/4 of the full changes that are needed, that
>> is, the most common drivers, and all the filesystems that would
>> build before the patch (so umsdos and sysv are out).
>>
>> Potential problem areas lie in the handling of e.g. tape devices
>> that it is possible to seek on, but are not random access. I
>> don't really know if the proper thing to do is to error, or to
>> do the seek. At present I do neither, with a FIXME where one or
>> the other action should go.
>>
>> "It works for me", but I would appreciate notes if I messed up
>> some device or filesystem doring in the conversion.
>
>I just wonder: What would be bad with converting sys_pread into
>sys_lseek and sys_read? Well, it would be a bit of performacne
>loose. But I don't think sys_pread-s are going to be _that_ common in
>next few years.
>
> Pavel
>- --
>I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
>Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
>
>------------------------------
>
>From: "Marty Leisner" <leisner@sdsp.mc.xerox.com>
>Date: Sun, 19 Oct 1997 13:37:14 PDT
>Subject: 2.0.30 and badblocks on IDE disks
>
>I have a Seagate ST36450 disk (6.4 gig?)
>hda: ST36450A, 6149MB w/448kB Cache, LBA, CHS=13328/15/63
>
>I'm running 2.0.30.
>I have:
>
> total used free shared buffers cached
>Mem: 94804 93236 1568 23080 29100 45292
>- -/+ buffers: 18844 75960
>Swap: 102496 2140 100356
>
>I have the first 5 gig used (and have had no problems).
>
>But I just tried to make a partition at the end of the disk
>(high sectors) and when I run
> badblocks -w
>The machines locks up for a while (can type) and then it frees up with
>Oct 17 08:35:29 dw kernel: Couldn't get a free page.....
>Oct 17 08:35:45 dw kernel: Couldn't get a free page.....
>Oct 17 08:37:55 dw kernel: Couldn't get a free page.....
>in the log...
>This is pretty consistent...
>
>It doesn't have a problem with readonly badblocks.
>
>I figured it might be a problem with the last track, so I cut down
>the number a little and it didn't help.
>
>The machine seems to be working OK...but the lockups for a minute
>or so are really annoying...
>
>I understand there are no raw devices...maybe there should be for
>these types of uses...
>
>marty leisner@sdsp.mc.xerox.com
>Don't confuse education with schooling.
> Milton Friedman to Yogi Berra
>
>------------------------------
>
>From: Jens Maurer <jmaurer@menuett.rhein-main.de>
>Date: Sun, 19 Oct 1997 22:05:40 +0200
>Subject: Re: laptop + 2.1.57 resetting before printing "Uncompressing Linux"
>
>This is a multi-part message in MIME format.
>
>- --------------26A8304059B7983E477DA522
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Alan Cox wrote:
>> If the patch was rewritten to use the cache flushing instructions
recommended
>> by the intel manuals instead of a "read and pray" approach [which I grant
>> works very well in some cases] it would probsbly work for more.
>
>Ok, here's a version of the patch (against 2.1.58) implementing your
>proposal. It works fine for me on a i386 and PPro, but unfortunately,
>I no longer have access to a machine exhibiting the A20/cache problems.
>
>Folks, could you please apply the patch to a vanilla 2.1.58, compile
>your kernel as bzImage and see if it boots? Please report to me (not
>the list) failure as well as success.
>
>Of course, I'm most interested in reports from people having a laptop
>with bzImage problems as well as those few owning a computer where my
>previous "read and pray" patch rendered the system unbootable due to
>unknown reasons.
>
>Thanks,
>Jens
>
>- --------------26A8304059B7983E477DA522
>Content-Type: text/plain; charset=us-ascii; name="a20.patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline; filename="a20.patch"
>
>diff -urN linux-2.1.58.orig/arch/i386/boot/setup.S
linux/arch/i386/boot/setup.S
>- --- linux-2.1.58.orig/arch/i386/boot/setup.S Sat Jul 26 03:52:51 1997
>+++ linux/arch/i386/boot/setup.S Sun Oct 19 21:30:30 1997
>@@ -30,6 +30,8 @@
> ! Extended memory detection scheme retwiddled by orc@pell.chi.il.us (david
> ! parsons) to avoid loadlin confusion, July 1997
> !
>+! Fix for A20 cache interaction problems by Jens Maurer, October 1997
>+! <jmaurer@menuett.rhein-main.de>
>
> #define __ASSEMBLY__
> #include <linux/config.h>
>@@ -516,10 +518,50 @@
> ! now we are at the right place
> end_move_self:
>
>- - lidt idt_48 ! load idt with 0,0
>- - lgdt gdt_48 ! load gdt with whatever appropriate
>
>- -! that was painless, now we enable A20
>+! Now we enable A20.
>+!
>+! On some machines (for example, Toshiba Tecra 710CDT laptops), there are
>+! cache coherency problems regarding the A20 gate and memory locations
>+! above 0x100000.
>+! With the A20 gate disabled, address 0x100000 is an alias for 0x000000.
>+! After enabling the A20 gate, this is no longer the case, but on the
>+! problem machines, invalid data is returned for reads from address
>+! 0x100000 due to caches not reflecting the new situation.
>+! As per Alan Cox' suggestion, the code flushes and disables all caches
>+! for the A20 gate enable. [Jens Maurer]
>+
>+#ifdef __BIG_KERNEL__
>+
>+! i386 processors don't have the "wbinvd" and "invd" instructions for cache
>+! invalidations. Check for an i386. (copied from arch/i386/kernel/head.S)
>+ pushfd ! push EFLAGS
>+ pop eax ! get EFLAGS
>+ mov ecx, eax ! save original EFLAGS
>+ xor eax, #0x40000 ! flip AC bit in EFLAGS
>+ push eax ! copy to EFLAGS
>+ popfd ! set EFLAGS
>+ pushfd ! get new EFLAGS
>+ pop eax ! put it in eax
>+ xor eax,ecx ! change in flags
>+ and eax, #0x40000 ! check if AC bit changed
>+ mov edx, eax ! save for later use
>+ je a20_toggle ! it's a 386: skip cache stuff
>+
>+! turn off the caches
>+! Pentium Pro Family Developer's Manual Volume 3:
>+! Operating System Writer's Guide, order number 242692
>+! section 11.5.2
>+
>+ wbinvd ! write back and invalidate caches
>+ mov eax, cr0
>+ or eax, #0x60000000 ! set CD and NW bits
>+ mov cr0, eax ! disable caches
>+! Since A20 problems have only been reported with Pentiums so far, we
refrain
>+! from changing the PPro's and PII's MTRRs to "UC" (uncached).
>+
>+a20_toggle:
>+#endif /* __BIG_KERNEL__ */
>
> call empty_8042
> mov al,#0xD1 ! command write
>@@ -528,6 +570,22 @@
> mov al,#0xDF ! A20 on
> out #0x60,al
> call empty_8042
>+
>+#ifdef __BIG_KERNEL__
>+ and edx, edx
>+ je end_a20 ! it's a 386: skip cache stuff
>+
>+! turn the caches back on
>+ mov eax, cr0
>+ and eax, #0x9fffffff ! clear CD and NW bits
>+ mov cr0, eax ! enable caches
>+ invd ! invalidate cache entries
>+end_a20:
>+#endif /* __BIG_KERNEL__ */
>+
>+! setup descriptor tables
>+ lidt idt_48 ! load idt with 0,0
>+ lgdt gdt_48 ! load gdt with whatever appropriate
>
> ! make sure any possible coprocessor is properly reset..
>
>
>- --------------26A8304059B7983E477DA522--
>
>
>
>------------------------------
>
>From: "Marty Leisner" <leisner@sdsp.mc.xerox.com>
>Date: Sun, 19 Oct 1997 13:48:36 PDT
>Subject: registers in proc filesystem?
>
>Is it possible to get at the process registers (in the proc file
>system)? I didn't see them.
>
>I don't want to attach gdb to it...or use ptrace...
>
>Would it be useful to put the registers in the proc file system (and maybe
>more entries of the u_area)?
>
>marty leisner@sdsp.mc.xerox.com
>Don't confuse education with schooling.
> Milton Friedman to Yogi Berra
>
>------------------------------
>
>From: "David S. Miller" <davem@jenolan.rutgers.edu>
>Date: Sun, 19 Oct 1997 17:00:13 -0400
>Subject: Re: pread/pwrite patch
>
> Date: Sun, 19 Oct 1997 12:19:52 +0200
> From: Pavel Machek <pavel@Elf.mj.gts.cz>
>
> I just wonder: What would be bad with converting sys_pread into
> sys_lseek and sys_read? Well, it would be a bit of performacne
> loose. But I don't think sys_pread-s are going to be _that_ common
> in next few years.
>
>Not really, the problem is that pread/pwrite must perform the seek and
>the actual read atomically.
>
>Later,
>David "Sparc" Miller
>davem@caip.rutgers.edu
>
>------------------------------
>
>From: "Seth M. Landsman" <seth@job.cs.brandeis.edu>
>Date: Sun, 19 Oct 1997 17:12:09 -0400 (EDT)
>Subject: 2.0.31 kernel question
>
> Is there any particular reason why the 2.0.31 kernel now
>"defaults" to SMP? i.e., the top level Makefile has SMP=1 defined, while
>the 2.0.30 kernel does not. Was this decision consciously made? And if
>so, why?
>
>- -Seth
>
>- --
>"It is by will alone I set my mind in motion"
>
>
>------------------------------
>
>From: Andi Kleen <ak@muc.de>
>Date: 19 Oct 1997 22:10:23 +0200
>Subject: Re: pread/pwrite patch
>
>Pavel Machek <pavel@Elf.mj.gts.cz> writes:
>
>> Hi!
>>
>> > Appended is a patch off of DaveM's most recent snapshot with the
>> > VFS changes needed to implement Single Unix's pread and pwrite.
>> >
>> > I've done probably 3/4 of the full changes that are needed, that
>> > is, the most common drivers, and all the filesystems that would
>> > build before the patch (so umsdos and sysv are out).
>> >
>> > Potential problem areas lie in the handling of e.g. tape devices
>> > that it is possible to seek on, but are not random access. I
>> > don't really know if the proper thing to do is to error, or to
>> > do the seek. At present I do neither, with a FIXME where one or
>> > the other action should go.
>> >
>> > "It works for me", but I would appreciate notes if I messed up
>> > some device or filesystem doring in the conversion.
>>
>> I just wonder: What would be bad with converting sys_pread into
>> sys_lseek and sys_read? Well, it would be a bit of performacne
>> loose. But I don't think sys_pread-s are going to be _that_ common in
>> next few years.
>
>When the standard 'LinuxAIO' POSIX asynchronous IO library uses it they
>might be very common. And pread is destined for stuff like user mode AIO
>support using clone().
>
>- -Andi
>
>------------------------------
>
>From: Magnus Hiie <mgn@ekspress.ee>
>Date: Mon, 20 Oct 1997 00:17:54 +0300
>Subject: IP masquerade
>
>Hi all!
>
>Could anybody please tell me what would I need to change in
>the kernel so that packets that go through
>ip_fw_masquerade() would appear in packet listeners
>(recvfrom ETH_P_ALL, promisc mode) in the original (not yet
>masqueraded) form?
>
>I need this for packet accounting (No, I can't use kernel's
>accounting) of machines behind the firewall.
>
>Thanx,
>Magnus
>
>P.S. Please include me in CC.
>
>
>------------------------------
>
>From: Egor Egorov <egor@fastware.kiev.ua>
>Date: Sun, 19 Oct 1997 19:28:23 +0000 (GMT)
>Subject: is raid0 stable in 2.0.31?
>
>I'm going to use kernel 2.0.31 (release) and raid0 personality in two scsi
>disks - Quantum PD1222s and PD7??s (one is 1169 mb, second is 696 mb). And
>I did raid0 on two this disks.
>
>So, the question is: is it stable ? May I trust it on a production server?
>
>
> Egor Egorov, lost soul.
>
>
>
>
>------------------------------
>
>From: "Seth M. Landsman" <seth@job.cs.brandeis.edu>
>Date: Sun, 19 Oct 1997 17:31:04 -0400 (EDT)
>Subject: Problems compiling 2.0.31
>
> This is a fresh copy of 2.0.31, in compiling it I get the
>following messages. I'll poke at it once my next shipment of round tuits
>comes in, but that might not be for several months at this rate ... :)
>
>- -Seth
>
>- -- ugly messages follow --
>
>make[1]: Leaving directory `/usr/src/linux-2.0.31/arch/i386/lib'
>ld -m elf_i386 -Ttext 0xC0100000 -e stext arch/i386/kernel/head.o
>init/main.o init/version.o \
> arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
>mm/mm.o fs/fs.o ipc/ipc.o net/network.a \
> fs/filesystems.a \
> drivers/block/block.a drivers/char/char.a drivers/net/net.a
>drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/sound/sound.a
>drivers/pci/pci.a \
> /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
>/usr/src/linux/arch/i386/lib/lib.a \
> -o vmlinux
>drivers/scsi/scsi.a(scsi.o): In function `allocate_device':
>scsi.o(.text+0xeb0): undefined reference to `local_irq_count'
>drivers/scsi/scsi.a(scsi.o): In function `internal_cmnd':
>scsi.o(.text+0x11f7): undefined reference to `local_irq_count'
>scsi.o(.text+0x1226): undefined reference to `local_irq_count'
>drivers/scsi/scsi.a(scsi.o): In function `scsi_request_sense':
>scsi.o(.text+0x1353): undefined reference to `local_irq_count'
>scsi.o(.text+0x1382): undefined reference to `local_irq_count'
>drivers/scsi/scsi.a(scsi.o)(.text+0x14eb): more undefined references to
>`local_irq_count' follow
>make: *** [vmlinux] Error 1
>
>- -- Config follows --
>
>#
># Automatically generated make config: don't edit
>#
>
>#
># Code maturity level options
>#
>CONFIG_EXPERIMENTAL=y
>
>#
># Loadable module support
>#
># CONFIG_MODULES is not set
>
>#
># General setup
>#
># CONFIG_MATH_EMULATION is not set
>CONFIG_NET=y
>CONFIG_PCI=y
>CONFIG_PCI_OPTIMIZE=y
># CONFIG_MCA is not set
>CONFIG_SYSVIPC=y
>CONFIG_BINFMT_AOUT=y
>CONFIG_BINFMT_ELF=y
># CONFIG_BINFMT_JAVA is not set
>CONFIG_M686=y
># CONFIG_VIDEO_SELECT is not set
>
>#
># Floppy, IDE, and other block devices
>#
>CONFIG_BLK_DEV_FD=y
>CONFIG_BLK_DEV_IDE=y
>
>#
># Please see Documentation/ide.txt for help/info on IDE drives
>#
># CONFIG_BLK_DEV_HD_IDE is not set
>CONFIG_BLK_DEV_IDEDISK=y
>CONFIG_BLK_DEV_IDECD=y
># CONFIG_BLK_DEV_IDETAPE is not set
># CONFIG_BLK_DEV_IDEFLOPPY is not set
># CONFIG_BLK_DEV_IDESCSI is not set
>CONFIG_BLK_DEV_CMD640=y
># CONFIG_BLK_DEV_CMD640_ENHANCED is not set
>CONFIG_BLK_DEV_RZ1000=y
>CONFIG_BLK_DEV_TRITON=y
># CONFIG_IDE_CHIPSETS is not set
>
>#
># Additional Block Devices
>#
>CONFIG_BLK_DEV_LOOP=y
># CONFIG_BLK_DEV_MD is not set
># CONFIG_BLK_DEV_RAM is not set
># CONFIG_BLK_DEV_XD is not set
># CONFIG_BLK_DEV_EZ is not set
># CONFIG_BLK_DEV_HD is not set
>
>#
># Networking options
>#
># CONFIG_NETLINK is not set
># CONFIG_FIREWALL is not set
># CONFIG_NET_ALIAS is not set
>CONFIG_INET=y
># CONFIG_IP_MULTICAST is not set
>CONFIG_IP_ACCT=y
># CONFIG_IP_ROUTER is not set
># CONFIG_NET_IPIP is not set
>
>#
># (it is safe to leave these untouched)
>#
># CONFIG_INET_PCTCP is not set
># CONFIG_INET_RARP is not set
>CONFIG_PATH_MTU_DISCOVERY=y
>CONFIG_IP_NOSR=y
>CONFIG_SKB_LARGE=y
># CONFIG_IPV6 is not set
>
>#
>#
>#
># CONFIG_IPX is not set
># CONFIG_ATALK is not set
># CONFIG_AX25 is not set
># CONFIG_X25 is not set
># CONFIG_LAPB is not set
># CONFIG_BRIDGE is not set
># CONFIG_LLC is not set
># CONFIG_WAN_ROUTER is not set
>
>#
># SCSI support
>#
>CONFIG_SCSI=y
>
>#
># SCSI support type (disk, tape, CD-ROM)
>#
>CONFIG_BLK_DEV_SD=y
># CONFIG_CHR_DEV_ST is not set
># CONFIG_BLK_DEV_SR is not set
>CONFIG_CHR_DEV_SG=y
>
>#
># Some SCSI devices (e.g. CD jukebox) support multiple LUNs
>#
>CONFIG_SCSI_MULTI_LUN=y
>CONFIG_SCSI_CONSTANTS=y
>
>#
># SCSI low-level drivers
>#
># CONFIG_SCSI_7000FASST is not set
># CONFIG_SCSI_AHA152X is not set
># CONFIG_SCSI_AHA1542 is not set
># CONFIG_SCSI_AHA1740 is not set
>CONFIG_SCSI_AIC7XXX=y
># CONFIG_SCSI_ADVANSYS is not set
># CONFIG_SCSI_IN2000 is not set
># CONFIG_SCSI_AM53C974 is not set
># CONFIG_SCSI_BUSLOGIC is not set
># CONFIG_SCSI_DTC3280 is not set
># CONFIG_SCSI_EATA_DMA is not set
># CONFIG_SCSI_EATA_PIO is not set
># CONFIG_SCSI_EATA is not set
># CONFIG_SCSI_FUTURE_DOMAIN is not set
># CONFIG_SCSI_GENERIC_NCR5380 is not set
># CONFIG_SCSI_NCR53C406A is not set
># CONFIG_SCSI_NCR53C7xx is not set
># CONFIG_SCSI_NCR53C8XX is not set
>CONFIG_SCSI_PPA=y
># CONFIG_SCSI_PAS16 is not set
># CONFIG_SCSI_QLOGIC_FAS is not set
># CONFIG_SCSI_QLOGIC_ISP is not set
># CONFIG_SCSI_SEAGATE is not set
># CONFIG_SCSI_T128 is not set
># CONFIG_SCSI_U14_34F is not set
># CONFIG_SCSI_ULTRASTOR is not set
>
>#
># Network device support
>#
>CONFIG_NETDEVICES=y
># CONFIG_ARCNET is not set
># CONFIG_DUMMY is not set
># CONFIG_EQUALIZER is not set
>CONFIG_NET_ETHERNET=y
># CONFIG_NET_VENDOR_3COM is not set
># CONFIG_LANCE is not set
># CONFIG_NET_VENDOR_SMC is not set
>CONFIG_NET_ISA=y
># CONFIG_AT1700 is not set
># CONFIG_E2100 is not set
># CONFIG_DEPCA is not set
># CONFIG_EWRK3 is not set
># CONFIG_EEXPRESS is not set
># CONFIG_EEXPRESS_PRO is not set
># CONFIG_FMV18X is not set
># CONFIG_HPLAN_PLUS is not set
># CONFIG_HPLAN is not set
># CONFIG_HP100 is not set
># CONFIG_ETH16I is not set
>CONFIG_NE2000=y
># CONFIG_NI52 is not set
># CONFIG_NI65 is not set
># CONFIG_SEEQ8005 is not set
># CONFIG_SK_G16 is not set
># CONFIG_NET_EISA is not set
># CONFIG_NET_POCKET is not set
># CONFIG_FDDI is not set
># CONFIG_DLCI is not set
># CONFIG_PLIP is not set
># CONFIG_PPP is not set
># CONFIG_NET_RADIO is not set
># CONFIG_SLIP is not set
># CONFIG_TR is not set
># CONFIG_SHAPER is not set
>
>#
># ISDN subsystem
>#
># CONFIG_ISDN is not set
>
>#
># CD-ROM drivers (not for SCSI or IDE/ATAPI drives)
>#
># CONFIG_CD_NO_IDESCSI is not set
>
>#
># Filesystems
>#
># CONFIG_QUOTA is not set
>CONFIG_MINIX_FS=y
>CONFIG_EXT2_FS=y
>CONFIG_FAT_FS=y
>CONFIG_MSDOS_FS=y
>CONFIG_VFAT_FS=y
># CONFIG_UMSDOS_FS is not set
>CONFIG_PROC_FS=y
>CONFIG_NFS_FS=y
># CONFIG_ROOT_NFS is not set
># CONFIG_SMB_FS is not set
>CONFIG_ISO9660_FS=y
># CONFIG_HPFS_FS is not set
># CONFIG_SYSV_FS is not set
># CONFIG_AFFS_FS is not set
># CONFIG_ROMFS_FS is not set
># CONFIG_AUTOFS_FS is not set
># CONFIG_UFS_FS is not set
>
>#
># Character devices
>#
>CONFIG_VT=y
>CONFIG_VT_CONSOLE=y
>CONFIG_SERIAL=y
># CONFIG_SERIAL_EXTENDED is not set
># CONFIG_SERIAL_NONSTANDARD is not set
># CONFIG_PRINTER is not set
>CONFIG_MOUSE=y
># CONFIG_ATIXL_BUSMOUSE is not set
># CONFIG_BUSMOUSE is not set
># CONFIG_MS_BUSMOUSE is not set
>CONFIG_PSMOUSE=y
># CONFIG_82C710_MOUSE is not set
># CONFIG_QIC02_TAPE is not set
># CONFIG_FTAPE is not set
># CONFIG_APM is not set
># CONFIG_WATCHDOG is not set
># CONFIG_RTC is not set
>
>#
># Sound
>#
>CONFIG_SOUND=y
># CONFIG_PAS is not set
>CONFIG_SB=y
># CONFIG_ADLIB is not set
># CONFIG_GUS is not set
># CONFIG_MPU401 is not set
># CONFIG_PSS is not set
># CONFIG_GUS16 is not set
># CONFIG_GUSMAX is not set
># CONFIG_MSS is not set
># CONFIG_SSCAPE is not set
># CONFIG_TRIX is not set
># CONFIG_MAD16 is not set
># CONFIG_CS4232 is not set
># CONFIG_MAUI is not set
># CONFIG_YM3812 is not set
>SBC_BASE=240
>SBC_IRQ=5
>SBC_DMA=0
>SB_DMA2=5
>SB_MPU_BASE=300
>
>#
># MPU401 IRQ is only required with Jazz16, SM Wave and ESS1688.
>#
>
>#
># Enter -1 to the following question if you have something else such as
SB16/32.
>#
>SB_MPU_IRQ=-1
># CONFIG_LOWLEVEL_SOUND is not set
>
>#
># Kernel hacking
>#
># CONFIG_PROFILE is not set
>
>
>------------------------------
>
>End of linux-kernel-digest V1 #1235
>***********************************
>
>To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
>in the body of a message to "Majordomo@Majordomo.vger.rutgers.edu". If
you want
>to subscribe something other than the account the mail is coming from,
>such as a local redistribution list, then append that address to the
>"subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
>A non-digest (direct mail) version of this list is also available; to
>subscribe to that instead, replace all instances of "linux-kernel-digest"
>in the commands above with "linux-kernel".
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu