lkml.org 
[lkml]   [1998]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-kernel-digest V1 #1608



owner-linux-kernel-digest@vger.rutgers.edu 작성함:

> linux-kernel-digest Thursday, 19 February 1998 Volume 01 : Number 1608
>
> In this issue:
>
> Re: mounting unpartitioned drives
> QNX scheduler idea
> Re: ctrl-alt-del not handicap accesable?
> PATCH for scsi-cdrom - use spin_locks.
> Re: compile all modules.
> Re: Linux scheduler (fwd)
> Re: Linux scheduler (fwd)
> Re: Mysterious 2.0.33 lockups
> Re: Mysterious 2.0.33 lockups
> RE: ctrl-alt-del not handicap accesable?
> Re: Mysterious 2.0.33 lockups
> Claimed 486/Pentium CPU "flaw"
> Re: ctrl-alt-del not handicap accesable?
> Re: ctrl-alt-del not handicap accesable?
> Re: Reproducible crash under 2.1.86 [solved and fixed]
> Re: LM79 kernel support(was Heat detector)
> Re: ctrl-alt-del not handicap accesable?
> Re: QNX scheduler idea
> Re: Linux scheduler (fwd)
> Re: VFS 64-bit clean?
> Re: Claimed 486/Pentium CPU "flaw"
> Re: ctrl-alt-del not handicap accesableL
> Re: ax.25 and bpq
> TCP Stall
> Re: ctrl-alt-del not handicap accesable?
> Linux on a NeXT ?
> unkillable processes created when calling scsi cdrom ioctls
> Re: ctrl-alt-del not handicap accesable?
> Re: ctrl-alt-del not handicap accesable?
> Re: Linux on a NeXT ?
> Routing and tunnel problem
> Re: `whoami` == "eric"
> Re: ctrl-alt-del not handicap accesable?
> Re: Claimed 486/Pentium CPU "flaw"
> Re: quake server / 2.1.8x / UDP?
> Re: VFS 64-bit clean
> Re: ctrl-alt-del not handicap accesable?
> 2.1.87 oopsen
>
> See the end of the digest for information on subscribing to the linux-kernel
> or linux-kernel-digest mailing lists.
>
> ----------------------------------------------------------------------
>
> From: "Grant R. Guenther" <grant@torque.net>
> Date: Wed, 18 Feb 1998 17:45:07 -0500 (EST)
> Subject: Re: mounting unpartitioned drives
>
> > > It might be worthwhile opening a debate about some method for telling a
> > > driver not to both with a partition scan. A boot option or /proc
> > > interface might do the trick:
> > Uh??
> > If the drive is removable (else why should you get "Media Changed") You
> > MUST do a partition scan.
>
> Says who ?
>
> > The requested partition is usually different on the new media and might
> > not exist at all.
>
> Precisely. The current algorithm _always_ does the partition scan - and
> can produce noise, or misleading results.
>
> > I know removable media is usually formatted as a single partition (You
> > can even make a filesystem on the raw device), but checking what's
> > actually on the media is (IMHO) an absolute "must".
>
> Why ? I have a hard time imagining a serious risk here. If the user has
> turned off partition checking and inserted a partitioned disk, it won't
> mount.
>
> That said, Itai's idea of a lazy partition scan seems sensible, and
> can probably be implemented in the individual drivers without too much fuss.
>
> - --------------------------------------------------------------------------
> Grant R. Guenther grant@torque.net
> - --------------------------------------------------------------------------
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Adam McKee <amckee@poboxes.com>
> Date: Wed, 18 Feb 1998 16:52:42 -0600 (CST)
> Subject: QNX scheduler idea
>
> how about being able to designate groups of run-queues and specify a
> *weight* with each group. For example:
>
> run-queues 0-7: 100
> run-queues 8-15: 50
> run-queues 16-31: 50
>
> Suppose there are tasks in each group that want to run. Then CPU time
> will be split amongst each group as follows:
>
> group 1: 50%
> group 2: 25%
> group 3: 25%
>
> Suppose there aren't any tasks in group 2 that want to run. Then the
> weighting would dictate the following distribution of CPU time:
>
> group 1: 66%
> group 3: 33%
>
> I don't want to beat it to death -- you get the idea. It's not a new idea
> either, but then neither was the QNX patch to begin with ;-) It might be
> nice to have more than 32 run-queues -- 64 perhaps.
>
> I plan to do this when 2.2 comes out (90-120 days?). I don't want to
> implement it in 2.0 *and* 2.2 - not much spare time these days.
>
> - -------------------------------------------------------------------------------
> Adam McKee phone: (306) 343-0881 (home)
> (306) 933-1544 (work)
> Programmer/Analyst (306) 956-4070 (voice-mail/pager)
> SED Systems, Inc. email: amckee@poboxes.com
> ===============================================================================
> Just say NO to IE 4.0. <http://www.sun.com/announcement/>
> ===============================================================================
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Rik van Riel <H.H.vanRiel@fys.ruu.nl>
> Date: Wed, 18 Feb 1998 22:03:58 +0100 (MET)
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> On Wed, 18 Feb 1998, Linux Mailing list account wrote:
>
> >
> > Recently, a friend of mine (who only has one arm) was complaining to me that
> > ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute to
> > realize that you must use the left control and alt keys -- the right ones
> > don't work. He now uses his nose to reboot his system, but complains to me
> > every time :)
> >
> > Is there any reason we are only allowing the left control and alt keys to be
> > used?
>
> Not specifically, but you _shouldn't_ use ctrl-alt-del
> to reboot your system. You should to a reboot or telinit 6
> (when under Linux or RedHat) to make a clean reboot.
>
> Rik.
> +-----------------------------+------------------------------+
> | For Linux mm-patches, go to | "I'm busy managing memory.." |
> | my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
> | ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
> +-----------------------------+------------------------------+
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Itai Nahshon <nahshon@actcom.co.il>
> Date: Thu, 19 Feb 1998 01:05:28 +0200
> Subject: PATCH for scsi-cdrom - use spin_locks.
>
> This is a multi-part message in MIME format.
> - --------------B5ECFA43961511BA1D3E5F7C
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> The coming patch fixes the Ughs and that hangs that I have had
> with ATAPI cdrom + ide-scsi + scsi cdrom driver. I use a single
> processor but have __SMP__ defined as a default.
> To use as a module you also need to export current_lock.
>
> However, I think there is one BAD thing about the scsi subsystem
> in a real SMP environment.
> All the low-level drivers are using save_flags+cli, the scsi-disk
> system is using spin_lock_irqsave and the scsi-cdrom is using (until the
> following patch) a bad mixture.
> According to Documentation/spinlocks.txt "they are NOT mutually
> exclusive".
>
> So, what is the spin_lock_irqsave in sd.c (and now in sr.c) protecting
> against?
> (is it just against interrupts on the local CPU?)
>
> Please also see my previous postings to linux-kernel with subject
> "Missing exports(patch) + Ugh".
>
> Itai
>
> - --
> Itai Nahshon nahshon@actcom.co.il
> Also nahshon@vnet.ibm.com
> - --------------B5ECFA43961511BA1D3E5F7C
> Content-Type: text/plain; charset=us-ascii; name="sr-patch"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline; filename="sr-patch"
>
> - --- linux-2.1.87-orig/drivers/scsi/sr.c Wed Feb 18 01:31:27 1998
> +++ linux-2.1.87/drivers/scsi/sr.c Thu Feb 19 00:19:52 1998
> @@ -432,10 +432,9 @@
> int flag = 0;
>
> while (1==1){
> - - save_flags(flags);
> - - cli();
> + spin_lock_irqsave(&current_lock, flags);
> if (CURRENT != NULL && CURRENT->rq_status == RQ_INACTIVE) {
> - - restore_flags(flags);
> + spin_unlock_irqrestore(&current_lock, flags);
> return;
> };
>
> @@ -451,6 +450,7 @@
> */
> if( SDev->host->in_recovery )
> {
> + spin_unlock_irqrestore(&current_lock, flags);
> return;
> }
>
> @@ -489,7 +489,7 @@
> SCpnt = scsi_allocate_device(&CURRENT,
> scsi_CDs[DEVICE_NR(CURRENT->rq_dev)].device, 0);
> else SCpnt = NULL;
> - - restore_flags(flags);
> + spin_unlock_irqrestore(&current_lock, flags);
>
> /* This is a performance enhancement. We dig down into the request list and
> * try to find a queueable request (i.e. device not busy, and host able to
> @@ -501,8 +501,7 @@
> if (!SCpnt && sr_template.nr_dev > 1){
> struct request *req1;
> req1 = NULL;
> - - save_flags(flags);
> - - cli();
> + spin_lock_irqsave(&current_lock, flags);
> req = CURRENT;
> while(req){
> SCpnt = scsi_request_queueable(req,
> @@ -517,7 +516,7 @@
> else
> req1->next = req->next;
> };
> - - restore_flags(flags);
> + spin_unlock_irqrestore(&current_lock, flags);
> };
>
> if (!SCpnt)
>
> - --------------B5ECFA43961511BA1D3E5F7C--
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Henrik Storner <storner@image.dk>
> Date: Wed, 18 Feb 1998 22:23:10 +0100
> Subject: Re: compile all modules.
>
> "Eric Mountain" <eric@minouche.demon.co.uk> writes:
>
> >I for one would hate this: I compile on a 486DX2 w/ 8Meg RAM.
> [cut]
> >I also don't fancy having to rm what I don't need. Waste of my time.
>
> I know it has been a long time, but in the old days (around 1.3.50 or so),
> the default behaviour was to build every single module. Took forever on
> a 486, and was a real PITA. Not to mention the not-so-unlikely event that
> one of the modules that you DON'T want has a bug in it that stops
> compilation before it gets to all of the modules that you DO want.
>
> >As it stands, the make process compiles what I need, nothing more, nothing
> >less. I vote to keep things this way.
>
> Agreed. The current behaviour is optimal. If someone wants to build every
> single module, they are free to configure their kernel that way. E.g. this
> is what the distribution builders do.
>
> - --
> Henrik Storner
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Keith Rohrer <kwrohrer@enteract.com>
> Date: Wed, 18 Feb 1998 17:26:56 -0600 (CST)
> Subject: Re: Linux scheduler (fwd)
>
> And lo, Adam McKee saith unto me:
> > The approach I am taking to prevent starvation is intentionally simple:
> > tasks can, due to starvation, be promoted beyond their "minimum"
> > run-queue, all the way to run-queue 0. Sooner or later, they will be
> > awarded a timeslice by the scheduler, and when that is used up, they will
> > be returned to their minimum run-queue.
> [snip]
> > > *NEW* Tasks get promoted above their maximum priority, when
> > > they suffer from starvation, but this is for one full timeslice
> > > only... OTOH, when it never finishes a timeslice, it might just
> > > remain in the high queue (so a +20 niced vi still get's good
> > > performance :-) For this the max-wait might be multiplied
> > > by the nice level the process is on.
> >
> > This is what I've done, but I immediately return the process to its
> > minimum run-queue regardless of whether or not it uses its entire slice.
> > The whole aim here is to allow the super-user to regain control of the
> > machine, and prevent processes on run-queues > 0 from being totally
> > starved.
> So in other words, every so often a starving process will get promoted
> to the top run queue, page fault (all its unshared pages having been
> swapped out minutes ago, in all likelyhood), and fall back down to
> the bottom queue again?
>
> > In writing and maintaining this patch, I've gained appreciation of two
> > things with respect to kernel scheduling algorithms:
> >
> > o it's easy to design beautiful solutions for specific scheduling
> > situations, but the real art is to come up with an algorithm
> > that achieves good all-around performance, and doesn't totally
> > break down in "un-anticipated" scheduling scenarios.
> You're aiming, I'm sure (as per stuff I probably snipped) at root doing
> stuff like ps and kill; these might work, but wouldn't likely get
> starved.
>
> Keith
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Rik van Riel <H.H.vanRiel@fys.ruu.nl>
> Date: Thu, 19 Feb 1998 00:23:15 +0100 (MET)
> Subject: Re: Linux scheduler (fwd)
>
> On Wed, 18 Feb 1998, Adam McKee wrote:
>
> > For example, if we allow processes to remain below their minimum run-queue
> > provided they don't ever use up an entire timeslice, then a malevolent
> > program could then intentionally try to always use 95% of its timeslice,
> > but not the whole thing so as to avoid ever being sent back to its minimum
> > run-queue. For a process like this, starvation could be the best thing
> > that ever happened to it... a one-way ticket to run-queue 0 :-)
>
> No it isn't. Starvation only occurs when there are other
> processes competing for CPU all the time, and these
> processes have a higher priority.
>
> I think I have another solution for the problem. We
> demote the problem to it's original minimum level when
> it uses the CPU slice completely, and we demote it two
> levels down when it doesn't completely finish it's CPU
> quantum.
>
> That way, a +20 niced vi will remain somewhat responsive,
> but a +20 niced CPU intensive process won't get anything
> more than it's share.
>
> Rik.
> +-----------------------------+------------------------------+
> | For Linux mm-patches, go to | "I'm busy managing memory.." |
> | my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
> | ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
> +-----------------------------+------------------------------+
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Dan Hollis <goemon@sasami.anime.net>
> Date: Wed, 18 Feb 1998 15:41:06 -0800 (PST)
> Subject: Re: Mysterious 2.0.33 lockups
>
> On Wed, 18 Feb 1998, Joe Konopka wrote:
> > > Did you try the right-alt + scroll-lock thing when it locked up?
> > Yes, tried that. No response at all.
>
> Sounds like hardware, is there anything you can swap out for a different
> type, e.g. ethernet card or scsi controller? It is still possible theres a
> bug in the kernel, and swapping hardware might give a clue into perhaps a
> buggy driver.
>
> - -Dan
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Dan Hollis <goemon@sasami.anime.net>
> Date: Wed, 18 Feb 1998 15:35:13 -0800 (PST)
> Subject: Re: Mysterious 2.0.33 lockups
>
> On Wed, 18 Feb 1998, Joe Konopka wrote:
> > I mounted the machine's nfs export from another linux box (2.0.30),
> > started the copy and left it unattended for awhile. Upon returning, the
> > 2.0.33 box was locked up solid -- no ctrl-alt-del, no switching VCs, no
> > network response at all. I have console blanking disabled, the console
> > was frozen as I left it, no errors, oopses or anything printed. Nothing
> > in the logs either.
>
> Did you try the right-alt + scroll-lock thing when it locked up?
>
> - -Dan
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: "Jordan Mendelson" <jordy@wserv.com>
> Date: Wed, 18 Feb 1998 18:38:36 -0500
> Subject: RE: ctrl-alt-del not handicap accesable?
>
> > On Wed, Feb 18, 1998 at 12:32:30PM -0700, Linux Mailing list account
> wrote:
> > Hi,
> > > Recently, a friend of mine (who only has one arm) was complaining to me
> that
> > > ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute
> to
> > > realize that you must use the left control and alt keys -- the right
> ones
> > > don't work. He now uses his nose to reboot his system, but complains to
> me
> > > every time :)
> > I would think that typing 'shutdown -r now' would be considerably easier
> > then hitting ALT with your nose :)
>
> You can hit ctrl-alt-del with your right hand (three fings, it's the way i
> do it, using the deliete above the arrows).
>
> I have also heard of a company that made keyboards for the handicapped which
> grouped keys and allowed easier access for people with only one hand.
> Unfortunatly, I don't remember the URL.
>
> Jordan
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Joe Konopka <jkonopka@darkstar.itol.com>
> Date: Wed, 18 Feb 1998 11:39:47 -0600 (CST)
> Subject: Re: Mysterious 2.0.33 lockups
>
> On Wed, 18 Feb 1998, Dan Hollis wrote:
>
> > On Wed, 18 Feb 1998, Joe Konopka wrote:
> > > I mounted the machine's nfs export from another linux box (2.0.30),
> > > started the copy and left it unattended for awhile. Upon returning, the
> > > 2.0.33 box was locked up solid -- no ctrl-alt-del, no switching VCs, no
> > > network response at all. I have console blanking disabled, the console
> > > was frozen as I left it, no errors, oopses or anything printed. Nothing
> > > in the logs either.
> >
> > Did you try the right-alt + scroll-lock thing when it locked up?
>
> Yes, tried that. No response at all.
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: David C Niemi <niemi@tux.org>
> Date: Wed, 18 Feb 1998 18:38:34 -0500 (EST)
> Subject: Claimed 486/Pentium CPU "flaw"
>
> There is an interesting article about underperformance of pre-Pro x86
> processors on:
> http://www.intelligentfirm.com/membench/index.shtml
>
> Any opinions on this? I am skeptical that it is such an important new
> discovery, or it should have shown up in benchmark results of the affected
> systems.
>
> - --- David C Niemi --- niemi@tux.org --- Reston, Virginia, USA ---
> "Well the lush separation unfolds you - and the products of wealth
> push you along on the bow wave of their spiritless undying selves."
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: miquels@cistron.nl (Miquel van Smoorenburg)
> Date: 19 Feb 1998 01:02:36 +0100
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> In article <Pine.LNX.3.95.980218123042.13802D-100000@titan.truedesign.com>,
> Linux Mailing list account <linuxmail@truedesign.com> wrote:
> >
> >Recently, a friend of mine (who only has one arm) was complaining to me that
> >ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute to
> >realize that you must use the left control and alt keys -- the right ones
> >don't work. He now uses his nose to reboot his system, but complains to me
> >every time :)
>
> Just define a new keymap ...
>
> Mike.
> - --
> Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed
> miquels@cistron.nl | awake all night wondering if there is a doG
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Trevor Johnson <trevor@jpj.net>
> Date: Wed, 18 Feb 1998 16:04:44 -0800 (PST)
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> > Is there any reason we are only allowing the left control and alt keys to be
> > used?
>
> Pressing the right alt and right ctrl keys, along with the del key in the
> group of keys above the inverted "T" on an AT-style keyboard works for me.
> I suspect there's something wonky in the keymap or init your friend is
> using. If he has trouble finding it, "su -c halt" or whatever should
> work. If he doesn't have root access, maybe he can get this installed
> (it's in /pub/Linux/Incoming on sunsite):
>
> Begin3
> Title: User-shutdown
> Version: 1.1
> Description: Allows selected users, controlled by a file in /etc, to
> shut down the system (without need for verification of
> identity, etc, or other complexities required by 'sudo')
> Keywords: User, shutdown, reboot, halt, admin tool
> Author: jules@earthcorp.com (Julian Hall)
> Maintained-by: jules@earthcorp.com (Julian Hall)
> Copying-policy: Public domain
> End
> ___
> Trevor Johnson
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Andrea Arcangeli <arcangeli@mbox.queen.it>
> Date: Wed, 18 Feb 1998 23:43:13 +0100 (CET)
> Subject: Re: Reproducible crash under 2.1.86 [solved and fixed]
>
> On Wed, 18 Feb 1998, Rik van Riel wrote:
>
> >I also have a 'peculiar' board, which hangs when the OS
> >tries to use multiple DMA channels at the same time.
> >This means that I can only use one DMA channel at once,
> >so no floppy & sound simultaneously... There goes the
> >most-favorite-demo :-(
>
> This is not my case. With my patches applyed mpg123 + superformat run
> fine.
>
> Andrea[s] Arcangeli
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Andrea Arcangeli <arcangeli@mbox.queen.it>
> Date: Thu, 19 Feb 1998 01:18:45 +0100 (CET)
> Subject: Re: LM79 kernel support(was Heat detector)
>
> On Sat, 14 Feb 1998, Steve Logue wrote:
>
> >http://cesdis.gsfc.nasa.gov/beowulf/software/lm78-0.1.tar.gz
>
> I tried the lm78 driver on my motherboard but seems to not work. It say:
>
> Feb 19 00:51:39 arca kernel: Didn't find an LM78 at address 0x290
>
> And if I try to use 0x80 as base address I get:
>
> Feb 19 00:45:25 arca kernel: Ports 0x85-0x86 are used by another driver.
>
> Probably my motherboard Epox P55VP3 don' t have that chipset.
>
> BTW, to try it I ported it to 2.1.86 but I never run it and it only
> compile as module (it don' t link with the kernel yet).
>
> Under the patch against 2.1.86.
>
> Andrea[s] Arcangeli
>
> Name: lm78-2.1.86.diff.gz
> lm78-2.1.86.diff.gz Type: GNU Zip Compressed Data (application/x-gzip)
> Encoding: x-uuencode
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Ken Jordan <kenjordan@massmedia.com>
> Date: Wed, 18 Feb 1998 17:07:46 -0800 (PST)
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> On Wed, 18 Feb 1998, Linux Mailing list account wrote:
>
> >
> > Recently, a friend of mine (who only has one arm) was complaining to me that
> > ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute to
> > realize that you must use the left control and alt keys -- the right ones
> > don't work. He now uses his nose to reboot his system, but complains to me
> > every time :)
> >
> > Is there any reason we are only allowing the left control and alt keys to be
> > used?
> >
>
> Being in the US and not needing AltGr I often modify the kernel key table
> so that left and right alt keys are the same (Alt). This is easily done
> (look at /usr/src/linux/drivers/char/defkeymap.map and "man loadkeys").
> You can also do this without modifying the kernel my just using loadkeys
> to load a new keymap.
>
> Take it easy,
> Ken Jordan
>
> P.S. You could also map ctrl-alt-delete to any other key combo you
> wanted.
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Rik van Riel <H.H.vanRiel@fys.ruu.nl>
> Date: Thu, 19 Feb 1998 01:11:23 +0100 (MET)
> Subject: Re: QNX scheduler idea
>
> On Wed, 18 Feb 1998, Adam McKee wrote:
>
> > how about being able to designate groups of run-queues and specify a
> > *weight* with each group. For example:
> >
> > run-queues 0-7: 100
> > run-queues 8-15: 50
> > run-queues 16-31: 50
>
> Maybe some more groups would be nice:
> 0- 3 128
> 4- 8 64
> 9-12 32
> 13-16 16
> 17-20 8
> 20-24 4
> 25-28 2
> 29-32 1
>
> Rik.
> +-----------------------------+------------------------------+
> | For Linux mm-patches, go to | "I'm busy managing memory.." |
> | my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
> | ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
> +-----------------------------+------------------------------+
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Adam McKee <amckee@poboxes.com>
> Date: Wed, 18 Feb 1998 18:47:22 -0600 (CST)
> Subject: Re: Linux scheduler (fwd)
>
> > > For example, if we allow processes to remain below their minimum run-queue
> > > provided they don't ever use up an entire timeslice, then a malevolent
> > > program could then intentionally try to always use 95% of its timeslice,
> > > but not the whole thing so as to avoid ever being sent back to its minimum
> > > run-queue. For a process like this, starvation could be the best thing
> > > that ever happened to it... a one-way ticket to run-queue 0 :-)
> >
> > No it isn't. Starvation only occurs when there are other
> > processes competing for CPU all the time, and these
> > processes have a higher priority.
>
> Perhaps you did not give adequate consideration to my argument. You might
> want to re-read it.
>
> > I think I have another solution for the problem. We
> > demote the problem to it's original minimum level when
> > it uses the CPU slice completely, and we demote it two
> > levels down when it doesn't completely finish it's CPU
> > quantum.
>
> I think this is open to abuse. Again, please reconsider my argument.
>
> I could be wrong, but I don't think you have effectively shot down my
> argument. A scheduling policy that is wide open to abuse is unacceptable.
>
> I appreciate the ideas and feedback, so I hope you don't get the
> impression that I don't.
>
> ttyl
>
> - -------------------------------------------------------------------------------
> Adam McKee phone: (306) 343-0881 (home)
> (306) 933-1544 (work)
> Programmer/Analyst (306) 956-4070 (voice-mail/pager)
> SED Systems, Inc. email: amckee@poboxes.com
> ===============================================================================
> Just say NO to IE 4.0. <http://www.sun.com/announcement/>
> ===============================================================================
>
> On Thu, 19 Feb 1998, Rik van Riel wrote:
>
> > Thanks for using NetForward!
> > http://www.netforward.com
> > v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
> >
> > On Wed, 18 Feb 1998, Adam McKee wrote:
> >
> > Rik.
> > +-----------------------------+------------------------------+
> > | For Linux mm-patches, go to | "I'm busy managing memory.." |
> > | my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
> > | ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
> > +-----------------------------+------------------------------+
> >
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Richard Henderson <rth@dot.cygnus.com>
> Date: Wed, 18 Feb 1998 17:17:32 -0800
> Subject: Re: VFS 64-bit clean?
>
> On Tue, Feb 17, 1998 at 11:21:58AM -0500, Albert D. Cahalan wrote:
> > It is not short-sightedness. The limit disappears on 64-bit hardware,
> > which will happen long before those 12 years are past. In 12 years,
> > the $300 PC will be 64-bit.
>
> Just so long as the on-disk structures allow all 64-bits to be
> recorded, its fine by me if you use less on intel in memory.
>
> > Performance _today_ really matters. Since terabyte-size files are
> > large enough and can be fast, signed sector numbers are good.
>
> And along those lines I'd rather not pay the price of the scaling
> on my Alpha.
>
> r~
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
> Date: Thu, 19 Feb 1998 02:33:56 +0100 (CET)
> Subject: Re: Claimed 486/Pentium CPU "flaw"
>
> On Wed, 18 Feb 1998, David C Niemi wrote:
>
> > There is an interesting article about underperformance of pre-Pro x86
> > processors on:
> > http://www.intelligentfirm.com/membench/index.shtml
>
> i suspect this is the same 'cache line access stall' thing observed &
> posted by Robert Collins to comp.sys.intel a few months ago? If you look
> at the Linux pentium FPU-memcpy patch, it's basically already optimized
> for such an access type, although the correct order of memory accesses was
> not found by analyzing the processor's (undocumented) behavior, it was
> found via experimentation (according to the author). This patch has been
> available for more than 2 years now AFAIR ...
>
> - -- mingo
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: "Garst R. Reese" <reese@isn.net>
> Date: Wed, 18 Feb 1998 21:32:35 -0400
> Subject: Re: ctrl-alt-del not handicap accesableL
>
> Jason wrote thusly:
> - --------------------------------------
> From: Linux Mailing list account <linuxmail@truedesign.com>
> Date: Wed, 18 Feb 1998 12:32:30 -0700 (MST)
> Subject: ctrl-alt-del not handicap accesable?
>
> Recently, a friend of mine (who only has one arm) was complaining to me
> that
> ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute
> to
> realize that you must use the left control and alt keys -- the right
> ones
> don't work. He now uses his nose to reboot his system, but complains to
> me
> every time :)
>
> Is there any reason we are only allowing the left control and alt keys
> to be
> used?
>
> Jason
> jsh@truedesign.com
> - ------------------------------------------------
> Check out xkeycaps. The whole keyboard is designed (badly IMHO) for
> people with ten fingers. It seems to me that some time spent on a
> complete redesign for one arm would be useful. Might also consider a
> foot-mouse. If you need further help, e-mail me and I will happily work
> on the problem. Tell me which arm so I know which one to tie behind my
> back :)
> - --
> Garst <reese@isn.net>
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Jason Duerstock <jasond@cdc.net>
> Date: Wed, 18 Feb 1998 20:48:05 -0500 (EST)
> Subject: Re: ax.25 and bpq
>
> As long as you have an ethernet card, you should be able to simply compile
> with bpq and ax.25 and be able to replicate the problem. I don't think
> I'm skilled enough to track this one down on my own. =/
>
> Jason
>
> On Wed, 18 Feb 1998, Alan Cox wrote:
>
> > > 2.1.8[67] bomb if you do the following:
> > >
> > > ifconfig bpq0 192.168.253.1
> > > ping 192.168.253.2
> > >
> > > (-blam-)
> > >
> > > I can't get any register dumps because the screen scrolls with:
> > >
> > > Scheduling in interrupt
> > >
> > > over and over.
> >
> > AX.25 and NetROM are broken in 2.1.7/8x. Im no longer running any amateur
> > radio equipment so I cant help much there
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: "Richard B. Johnson" <root@chaos.analogic.com>
> Date: Wed, 18 Feb 1998 20:50:57 -0500 (EST)
> Subject: TCP Stall
>
> Info:
> The TCP Stall is back in version 2.1.87. I don't know in which version
> it actually came back, but I just downloaded the kernel so I could
> upgrade one of my machines at home.
> - -rw-r--r-- 1 root root 10443268 Feb 17 13:16 linux-2.1.87.tar.gz
> This took 4 hours and 40 minutes on my 28.8, sometimes 56kb, link.
> <whew...>
>
> There were many minutes in which nothing was transmitted. I could ping
> freely during that time so connectivity was okay during the stalls.
>
> Cheers,
> Dick Johnson
> ***** FILE SYSTEM MODIFIED *****
> Penguin : Linux version 2.1.87 on an i586 machine (66.15 BogoMips).
> Warning : It's hard to remain at the trailing edge of technology.
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: James Mastros <root@jennifer-unix.dyn.ml.org>
> Date: Wed, 18 Feb 1998 20:58:48 -0500 (EST)
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> On Wed, 18 Feb 1998, Rik van Riel wrote:
> > On Wed, 18 Feb 1998, Linux Mailing list account wrote:
> > > Recently, a friend of mine (who only has one arm) was complaining to me that
> > > ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute to
> > > realize that you must use the left control and alt keys -- the right ones
> > > don't work. He now uses his nose to reboot his system, but complains to me
> > > every time :)
> > >
> > > Is there any reason we are only allowing the left control and alt keys to be
> > > used?
> >
> > Not specifically, but you _shouldn't_ use ctrl-alt-del
> > to reboot your system. You should to a reboot or telinit 6
> > (when under Linux or RedHat) to make a clean reboot.
> >
> > Rik.
>
> Except in odd situations (when first starting, and right before shutdown),
> ctrl-alt-del just sends a signal to init. (SIGINT, according to the
> ctrlaltdel (8) manpage.) In these situations, a hard reboot is probably a
> Good Thing, as nothing else would work.
>
> -=- James Mastros
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: "Andrew B. Cramer" <cramer@ns.falconweb.com>
> Date: Wed, 18 Feb 1998 20:39:28 -0600
> Subject: Linux on a NeXT ?
>
> Greetings,
> Sorry to post this here, but I don't know
> where else to. Is there support for my 68040 based
> NeXTstation?
>
> Thanks!
>
> Regards,
>
> Andy
>
> * The Linux Resource Exchange *
> http://www.falconweb.com/~linuxrx/
> cramer@falconweb.com
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: aaronp@ofb.net (Aaron Passey)
> Date: 19 Feb 1998 03:06:49 GMT
> Subject: unkillable processes created when calling scsi cdrom ioctls
>
> The following program hangs waiting for the first forked process to
> finish. After pressing ^C, the process created is unkillable and the cdrom is
> unusable since that process is holding the file descriptor open. The whole
> reason I even want to fork off a process is there are no non-blocking open and
> close cdrom ioctls, which I need. Sadly, this is the simplest program I could
> create that causes the unkillable process. Also, I couldn't find a test case
> that uses only one cdrom.
>
> Does anyone have any ideas as to what is happening? I'm not entirely
> sure where to start debugging this. I am willing to do any experiments to
> figure out the problem.
>
> As another data point, running this same program on a computer with an
> Adaptec 1542 causes repeated scsi bus resets until the whole computer grinds to
> a halt.
>
> This is with kernel 2.1.87. I also tried 2.1.86 (with the older
> Buslogic driver) and 2.1.72. I put a bunch of info from /proc at the bottom of
> the message.
>
> #include <sys/ioctl.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <linux/cdrom.h>
> #include <unistd.h>
> #include <sys/wait.h>
> #include <fcntl.h>
>
> #include <stdio.h>
>
> int main() {
> int fd1 = open("/dev/scd1", O_RDONLY | O_NONBLOCK);
> int fd3 = open("/dev/scd3", O_RDONLY | O_NONBLOCK);
> int pid1, pid3;
>
> printf("fd1 = %d, fd3 = %d\n", fd1, fd3);
>
> printf("non-forking close /dev/scd3\n");
> if(ioctl(fd3, CDROMCLOSETRAY) < 0) {
> perror("parent: Couldn't close cdrom tray");
> return -1;
> }
>
> printf("forking close /dev/scd1\n");
> if(!(pid1 = fork())) {
> if(ioctl(fd1, CDROMCLOSETRAY) < 0) {
> perror("child: Couldn't close cdrom tray");
> _exit(1);
> }
> _exit(0);
> }
> printf(" pid1 = %d\n", pid1);
>
> printf("forking close /dev/scd3\n");
> if(!(pid3 = fork())) {
> if(ioctl(fd3, CDROMCLOSETRAY) < 0) {
> perror("child: Couldn't close cdrom tray");
> _exit(1);
> }
> _exit(0);
> }
> printf(" pid3 = %d\n", pid3);
>
> printf("Waiting for /dev/scd1 to close pid1 = %d\n", pid1);
> waitpid(pid1, 0, 0);
>
> /* It crashes right here. waitpid() never returns. */
>
> printf("Waiting for /dev/scd3 to open pid3 = %d\n", pid3);
> waitpid(pid3, 0, 0);
>
> printf("Done!\n");
> return 0;
> }
>
> Here are the vital stats of my system:
>
> % cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
> Vendor: SEAGATE Model: ST32272N Rev: 0784
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: CyberDrv Model: SCSI CD-ROM 120S Rev: 1.30
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 02 Lun: 00
> Vendor: CyberDrv Model: SCSI CD-ROM 120S Rev: 1.30
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 03 Lun: 00
> Vendor: CyberDrv Model: SCSI CD-ROM 120S Rev: 1.30
> Type: CD-ROM ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 04 Lun: 00
> Vendor: CyberDrv Model: SCSI CD-ROM 120S Rev: 1.30
> Type: CD-ROM ANSI SCSI revision: 02
>
> % cat /proc/scsi/Buslogic/0
> ***** BusLogic SCSI Driver Version 2.0.11 of 31 January 1998 *****
> Copyright 1995 by Leonard N. Zubkoff <lnz@dandelion.com>
> Configuring BusLogic Model BT-930 PCI Ultra SCSI Host Adapter
> Firmware Version: 5.02, I/O Address: 0xD800, IRQ Channel: 11/Level
> PCI Bus: 0, Device: 10, Address: 0xE7000000, Host Adapter SCSI ID: 7
> Parity Checking: Enabled, Extended Translation: Enabled
> Synchronous Negotiation: Fast, Wide Negotiation: Disabled
> Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
> Driver Queue Depth: 255, Scatter/Gather Limit: 128 segments
> Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
> Error Recovery Strategy: Default, SCSI Bus Reset: Enabled
> SCSI Bus Termination: Disabled, SCAM: Disabled
> *** BusLogic BT-930 Initialized Successfully ***
>
> Target 0: Queue Depth 28, Synchronous at 10.0 MB/sec, offset 15
> Target 1: Queue Depth 3, Synchronous at 10.0 MB/sec, offset 8
> Target 2: Queue Depth 3, Synchronous at 10.0 MB/sec, offset 8
> Target 3: Queue Depth 3, Synchronous at 10.0 MB/sec, offset 8
> Target 4: Queue Depth 3, Synchronous at 10.0 MB/sec, offset 8
>
> Current Driver Queue Depth: 255
> Currently Allocated CCBs: 49
>
> DATA TRANSFER STATISTICS
>
> Target Tagged Queuing Queue Depth Active Attempted Completed
> ====== ============== =========== ====== ========= =========
> 0 Active 28 0 2842 2842
> 1 Not Supported 3 0 3 3
> 2 Not Supported 3 1 26 25
> 3 Not Supported 3 0 3 3
> 4 Not Supported 3 0 29 29
>
> Target Read Commands Write Commands Total Bytes Read Total Bytes Written
> ====== ============= ============== =================== ===================
> 0 1985 853 7194624 1252352
> 1 0 0 0 0
> 2 0 0 0 0
> 3 0 0 0 0
> 4 0 0 0 0
>
> Target Command 0-1KB 1-2KB 2-4KB 4-8KB 8-16KB
> ====== ======= ========= ========= ========= ========= =========
> 0 Read 0 1036 63 426 448
> 0 Write 0 661 142 40 10
> 1 Read 0 0 0 0 0
> 1 Write 0 0 0 0 0
> 2 Read 0 0 0 0 0
> 2 Write 0 0 0 0 0
> 3 Read 0 0 0 0 0
> 3 Write 0 0 0 0 0
> 4 Read 0 0 0 0 0
> 4 Write 0 0 0 0 0
>
> Target Command 16-32KB 32-64KB 64-128KB 128-256KB 256KB+
> ====== ======= ========= ========= ========= ========= =========
> 0 Read 4 6 2 0 0
> 0 Write 0 0 0 0 0
> 1 Read 0 0 0 0 0
> 1 Write 0 0 0 0 0
> 2 Read 0 0 0 0 0
> 2 Write 0 0 0 0 0
> 3 Read 0 0 0 0 0
> 3 Write 0 0 0 0 0
> 4 Read 0 0 0 0 0
> 4 Write 0 0 0 0 0
>
> ERROR RECOVERY STATISTICS
>
> Command Aborts Bus Device Resets Host Adapter Resets
> Target Requested Completed Requested Completed Requested Completed
> ID \\\\ Attempted //// \\\\ Attempted //// \\\\ Attempted ////
> ====== ===== ===== ===== ===== ===== ===== ===== ===== =====
> 0 0 0 0 0 0 0 0 0 0
> 1 0 0 0 0 0 0 0 0 0
> 2 0 0 0 0 0 0 0 0 0
> 3 0 0 0 0 0 0 0 0 0
> 4 0 0 0 0 0 0 0 0 0
>
> External Host Adapter Resets: 0
> Host Adapter Internal Errors: 0
>
> % cat /proc/cpuinfo
>
> processor : 0
> cpu family : 5
> model : Pentium MMX
> vendor_id : GenuineIntel
> stepping : 4
> fdiv_bug : no
> hlt_bug : no
> sep_bug : no
> f00f_bug : yes
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr mce cx8 mmx
> bogomips : 299.01
>
> Thanks for your help,
>
> Aaron
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Kevin Lentin <kevinl@cs.monash.edu.au>
> Date: Thu, 19 Feb 1998 14:40:19 +1100
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> On Wed, Feb 18, 1998 at 12:32:30PM -0700, Linux Mailing list account wrote:
> >
> > Recently, a friend of mine (who only has one arm) was complaining to me that
> > ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute to
> > realize that you must use the left control and alt keys -- the right ones
> > don't work. He now uses his nose to reboot his system, but complains to me
> > every time :)
>
> > Is there any reason we are only allowing the left control and alt keys to be
> > used?
>
> Just the default keymap. Look at man loadkeys.
>
> On my machine, I can reboot using the so-called three finger salute or
> vulcan nerve pinch, right-alt, right-ctrl, central-delete. BUT I can't use
> right-alt to switch VC's (I must fix that sometime).
>
> My /etc/default.keymap has:
> keycode 83 = KP_Period
> altgr control keycode 83 = Boot
> control alt keycode 83 = Boot
>
> To set reboots on the keypad delete. The 'altgr' is the right alt key.
>
> It also has
> keycode 100 = AltGr
> Which might be useful to change to
> keycode 100 = Alt
> (although I don't know that that will work, I can't see why it wouldn't
> turn the right alt key into a synonym for the left).
>
> I then have
> keycode 111 = Remove
> altgr control keycode 111 = Boot
> control alt keycode 111 = Boot
>
> I presume that your friend's machine either doesn't have this last entry
> with the reboot _or_ altgr isn't working or he just needs to map that key
> to Alt instead of Altgr.
>
> It's certainly possible for him to achieve what he wants. And much more.
>
> - --
> [======================================================================]
> [ Kevin Lentin Email: K.Lentin@cs.monash.edu.au ]
> [ finger kevinl@fangorn.cs.monash.edu.au for PGP public key block. ]
> [ KeyId: 06808EED FingerPrint: 6024308DE1F84314 811B511DBA6FD596 ]
> [======================================================================]
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Kevin Lentin <kevinl@cs.monash.edu.au>
> Date: Thu, 19 Feb 1998 14:41:30 +1100
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> On Wed, Feb 18, 1998 at 10:03:58PM +0100, Rik van Riel wrote:
> >
> > Not specifically, but you _shouldn't_ use ctrl-alt-del
> > to reboot your system. You should to a reboot or telinit 6
> > (when under Linux or RedHat) to make a clean reboot.
>
> 'Linux or RedHat' Not sure what that means.
>
> BUT what is wrong with using CAD to reboot? All it does is send a boot
> message to init as far as I can tell. My machine goes through exactly the
> same routine whether I press CAD or run telinit 6 or run reboot or shutdown
> - -r now. They're all equivalent.
>
> - --
> [======================================================================]
> [ Kevin Lentin Email: K.Lentin@cs.monash.edu.au ]
> [ finger kevinl@fangorn.cs.monash.edu.au for PGP public key block. ]
> [ KeyId: 06808EED FingerPrint: 6024308DE1F84314 811B511DBA6FD596 ]
> [======================================================================]
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Trevor Johnson <trevor@jpj.net>
> Date: Wed, 18 Feb 1998 22:45:07 -0500 (EST)
> Subject: Re: Linux on a NeXT ?
>
> > Sorry to post this here, but I don't know
> > where else to. Is there support for my 68040 based
> > NeXTstation?
>
> People are working on it, but it's nowhere near ready, because needed
> documentation isn't available. See http://www.black.linux-m68k.org/ for
> details.
> ___
> Trevor Johnson
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Gordon Chaffee <chaffee@cs.berkeley.edu>
> Date: Sun, 8 Feb 1998 12:11:40 -0800 (PST)
> Subject: Routing and tunnel problem
>
> I'm trying to use the IPIP tunnel device in 2.1.8x, and I'm having some
> trouble. Basically, it always tells me there is no route to the host.
> This doesn't seem to be a problem in 2.0.3x.
>
> Specifically, I'm trying to encapsulate the traffic for a single host
> through a tunnel.
>
> I create the tunnel and ifconfig it with
>
> ifconfig tunl0 169.229.40.76 netmask 255.255.255.255
>
> The trouble occurs when I try to route through tunl0:
>
> route add -host gallia.cs.berkeley.edu gw 169.229.40.35 tunl0
>
> This fails with a host unreachable error. I was able to workaround
> the problem by setting the mask on tunl0 to be 255.255.255.0.
> Then, I could do
>
> route add -net 169.229.40.0 tunl0
> route add -host gallia.cs.berkeley.edu gw 169.229.40.35 tunl0
> route del -net 169.229.40.0 netmask 255.255.255.0
> ifconfig tunl0 netmask 255.255.255.255
>
> Since I should be able to route to an arbitrary destination through a
> tunnel, it really shouldn't be checking if the destination is reachable
> using the normal logic. It checks to see if there is a path from tunl0
> to the destination host. This is incorrect because the packet passes
> through tunl0 onto eth0 and uses eth0's routing table. I do have a
> route from eth0 to 169.229.40.35.
>
> - - Gordon
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Eric Youngdale <eric@andante.jic.com>
> Date: Wed, 18 Feb 1998 23:38:04 -0500 (EST)
> Subject: Re: `whoami` == "eric"
>
> On Wed, 18 Feb 1998, Michael Elizabeth Chastain wrote:
> > Hi Eric,
> >
> > I found the following code in drivers/scsi/Config.in:
> >
> > if [ "`whoami`" = "eric" ]; then
> > dep_tristate 'SCSI debugging host adapter' CONFIG_SCSI_DEBUG $CONFIG_SCSI
> > fi
> >
> > I'm trying to get rid of the `...` constructions in Config.in files.
> > Also, I think it's a little tacky to test against a specific login name
> > in released code. Would it be all right with you if I changed this to:
>
> Perhaps it is tacky, but that 'host adapter' is essentially only
> used for fault tracing, running simulations (I have simulated several
> hundred disks recently, for example), and other such gunk. Nonetheless,
> your proposed change is reasonable :-).
>
> > if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
> > dep_tristate 'SCSI debugging host adapter' CONFIG_SCSI_DEBUG $CONFIG_SCSI
> > fi
>
> Please CC me on any follow-ups. I don't have time to read
> linux-kernel.
>
> - -Eric
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Sean Kelly <smkelly@zombie.org>
> Date: Wed, 18 Feb 1998 23:38:33 -0500 (EST)
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> On Thu, 19 Feb 1998, Kevin Lentin wrote:
>
> > On Wed, Feb 18, 1998 at 10:03:58PM +0100, Rik van Riel wrote:
> > >
> > > Not specifically, but you _shouldn't_ use ctrl-alt-del
> > > to reboot your system. You should to a reboot or telinit 6
> > > (when under Linux or RedHat) to make a clean reboot.
> >
> > 'Linux or RedHat' Not sure what that means.
> >
> > BUT what is wrong with using CAD to reboot? All it does is send a boot
> > message to init as far as I can tell. My machine goes through exactly the
> > same routine whether I press CAD or run telinit 6 or run reboot or shutdown
> > -r now. They're all equivalent.
> >
> I've found that different distributions of Linux setup init and keymaps
> differently, so rebooting using CAD is different from machine to machine.
>
> I use Slackware Linux, and pressing LCTRL+LALT+DEL is *better* than
> 'telinit 6' because it runs the 'shutdown' command first:
> ca::ctrlaltdel:/sbin/shutdown -t5 -rfn now
>
> It would probably be best to either change keyboard maps or just type
> 'shutdown -r now' as root.
>
> - --
> Sean KElly
> <smkelly@zombie.org>
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: "Michael L. Galbraith" <mikeg@weiden.de>
> Date: Thu, 19 Feb 1998 05:39:45 +0100 (MET)
> Subject: Re: Claimed 486/Pentium CPU "flaw"
>
> On Thu, 19 Feb 1998, MOLNAR Ingo wrote:
>
> >
> > On Wed, 18 Feb 1998, David C Niemi wrote:
> >
> > > There is an interesting article about underperformance of pre-Pro x86
> > > processors on:
> > > http://www.intelligentfirm.com/membench/index.shtml
> >
> > i suspect this is the same 'cache line access stall' thing observed &
> > posted by Robert Collins to comp.sys.intel a few months ago? If you look
> > at the Linux pentium FPU-memcpy patch, it's basically already optimized
> > for such an access type, although the correct order of memory accesses was
> > not found by analyzing the processor's (undocumented) behavior, it was
> > found via experimentation (according to the author). This patch has been
> > available for more than 2 years now AFAIR ...
> >
> > -- mingo
>
> I've been running that patch since inception with nothing but nice
> (very) performance wins. Any idea why it hasn't been assimilated?
>
> -Mike
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Daniel Haun <dhaun@ecf2.puc.edu>
> Date: Wed, 18 Feb 1998 22:25:40 -0800 (PST)
> Subject: Re: quake server / 2.1.8x / UDP?
>
> > Somewhere between 2.1.56 and 2.1.85, my quake server (squake -listen and
> > squake -dedicated) stopped working.
> > About the only other detail I know is that quake uses UDP.
> > When I try to connect to the server from localhost or another machine (in
> > 2.1.8[567] only), it says "Trying..." several times, then quits. In
> > 2.1.56, it finds the host immediately.
> > This is SMP, Tyan S1668 dual PPRO, 64MB, de205 isa ethernet (ewrk3
> > driver, module), only non-default networking option = IP accounting
> > Compiled: pgcc-2.91.02 971216 (gcc-2.8.0)
> > (also tried 2.1.87 no SMP gcc 2.7.2.3: same result)
>
> I've been experiencing this too. Running "netstat -au" shows the
> following:
>
> Active Internet connections (including servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> [...]
> udp 2654 0 *:26000 *:*
>
> (of course, the data in Recv-Q varies depending on how many times I've
> tried to connect)
>
> > Suggestions?
>
> I found that reversing the patch to udp.c from 2.1.73 cures the problem
> for me, although I'm not enough of a guru to understand why. I'd be
> happy to try out a more proper fix.
>
> Daniel
> dhaun@puc.edu
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: kaih@khms.westfalen.de (Kai Henningsen)
> Date: 19 Feb 1998 00:24:00 +0200
> Subject: Re: VFS 64-bit clean
>
> chip@atlantic.net wrote on 17.02.98 in <199802171859.NAA04002@cyprus.atlantic.net>:
>
> > According to Rik van Riel:
> > > On Tue, 17 Feb 1998, Albert D. Cahalan wrote:
> > > > __u32 i_dtime; /* Deletion Time */
> > > after 2038, we'll need larger time.
> >
> > No, that's an unsigned value, it'll go way beyond 2038.
>
> Oh?
>
> khms# touch -d 1950-01-01 bla
> khms# ls -laFtr bla
> - -rw-r--r-- 1 root root 0 Jan 1 1950 bla
>
> I don't think so.
>
> MfG Kai
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Gerhard Mack <gmack@imag.net>
> Date: Wed, 18 Feb 1998 23:15:41 -0800 (PST)
> Subject: Re: ctrl-alt-del not handicap accesable?
>
> On Wed, 18 Feb 1998, Rik van Riel wrote:
>
> > On Wed, 18 Feb 1998, Linux Mailing list account wrote:
> >
> > >
> > > Recently, a friend of mine (who only has one arm) was complaining to me that
> > > ctrl-alt-del did not shutdown/reboot his linux box. It took me a minute to
> > > realize that you must use the left control and alt keys -- the right ones
> > > don't work. He now uses his nose to reboot his system, but complains to me
> > > every time :)
> > >
> > > Is there any reason we are only allowing the left control and alt keys to be
> > > used?
> >
> > Not specifically, but you _shouldn't_ use ctrl-alt-del
> > to reboot your system. You should to a reboot or telinit 6
> > (when under Linux or RedHat) to make a clean reboot.
>
> What is the deiifrenct between trapping <ctrl>-<alt>-<del> and executing
> the correct shutdown program and running reboot ?
>
> Gerhard Mack<gmack@imag.net>
> - --
>
> As a computer I find your faith in technology amusing.
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> From: Trevor Johnson <trevor@jpj.net>
> Date: Thu, 19 Feb 1998 02:20:13 -0500 (EST)
> Subject: 2.1.87 oopsen
>
> I tried 2.1.87 with e2compr-0.3.6-patch-2.1.80 on a system that had been
> running 2.1.72 for 14 days, and got multiple oops when init started the
> PostgreSQL postmaster. Here is one of them, with some other error
> messages that appeared with it:
>
> swap_free: offset exceeds max
> swap_free: offset exceeds max
> swap_free: offset exceeds max
> swap_free: offset exceeds max
> swap_free: offset exceeds max
> swap_free: offset exceeds max
> swap_free: offset exceeds max
> swap_free: offset exceeds max
> Unable to handle kernel NULL pointer dereference at virtual address 00000021
> current->tss.cr3 = 010e6000, %cr3 = 010e6000
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c0135114>]
> EFLAGS: 00010286
> eax: 000000c9 ebx: c10e1e40 ecx: ffffffff edx: c143e40c
> esi: 00000003 edi: 40241000 ebp: 40187000 esp: c10e5f20
> ds: 0018 es: 0018 ss: 0018
> Process postmaster (pid: 201, process nr: 64, stackpage=c10e5000)
> Stack: c10e1e40 c10e1e40 40241000 c011a6e5 c10e1e40 c10e1e40 40187000 000ba000
> 00000000 c011a9e7 c10e1e40 40187000 000ba000 c10e5f74 c119ffa0 40187000
> 40187000 40187000 c10e4000 00000001 c139fec0 c10e1d80 c0135188 40187000
> Call Trace: [<c011a6e5>] [<c011a9e7>] [<c0135188>] [<c010dae6>] [<c0109a5a>] [<c010991e>]
> Code: 66 89 41 22 a1 60 bf 1f c0 89 41 18 66 8b 41 24 89 c7 66 4f
> swap_free: swap-space map bad (entry 00008100)
> swap_free: swap-space map bad (entry 00010100)
> swap_free: swap-space map bad (entry 00018100)
> swap_free: swap-space map bad (entry 00020100)
> swap_free: swap-space map bad (entry 00028100)
> swap_free: swap-space map bad (entry 00030100)
> INIT: Id "pg" respawning too fast: disabled for 5 minutes
>
> Here's the disassembly of it:
>
> Using `System-2.1.87.map' to map addresses to symbols.
>
> >>EIP: c0135114 <shm_close+38/6c>
> Trace: c011a6e5 <unmap_fixup+45/14c>
> Trace: c011a9e7 <do_munmap+1e7/23c>
> Trace: c0135188 <sys_shmdt+40/50>
> Trace: c010dae6 <sys_ipc+286/2d0>
> Trace: c0109a5a <error_code+32/3c>
> Trace: c010991e <system_call+3a/40>
> Code: c0135114 <shm_close+38/6c>
> Code: c0135114 <shm_close+38/6c> 66 89 41 22 movw %ax,0x22(%ecx)
> Code: c0135118 <shm_close+3c/6c> a1 60 bf 1f c0 movl 0xc01fbf60,%eax
> Code: c013511d <shm_close+41/6c> 89 41 18 movl %eax,0x18(%ecx)
> Code: c0135126 <shm_close+4a/6c> 66 8b 41 24 movw 0x24(%ecx),%ax
> Code: c013512a <shm_close+4e/6c> 89 c7 movl %eax,%edi
> Code: c013512c <shm_close+50/6c> 66 4f decw %di
>
> Here's the kernel configuration:
>
> #
> # Automatically generated make config: don't edit
> #
>
> #
> # Code maturity level options
> #
> CONFIG_EXPERIMENTAL=y
>
> #
> # Processor type and features
> #
> # CONFIG_M386 is not set
> # CONFIG_M486 is not set
> CONFIG_M586=y
> # CONFIG_M686 is not set
> # CONFIG_MATH_EMULATION is not set
>
> #
> # Loadable module support
> #
> CONFIG_MODULES=y
> # CONFIG_MODVERSIONS is not set
> CONFIG_KERNELD=y
>
> #
> # General setup
> #
> CONFIG_NET=y
> CONFIG_PCI=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_OPTIMIZE=y
> CONFIG_PCI_OLD_PROC=y
> # CONFIG_MCA is not set
> CONFIG_SYSVIPC=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> CONFIG_SYSCTL=y
> # CONFIG_BINFMT_AOUT is not set
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_MISC=m
> CONFIG_BINFMT_JAVA=m
> CONFIG_VIDEO_SELECT=y
> CONFIG_PARPORT=y
> CONFIG_PARPORT_PC=y
> # CONFIG_PARPORT_OTHER is not set
>
> #
> # Plug and Play support
> #
> # CONFIG_PNP is not set
>
> #
> # Floppy, IDE, and other block devices
> #
> CONFIG_BLK_DEV_FD=m
> 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 is not set
> # 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 is not set
> # CONFIG_BLK_DEV_RZ1000 is not set
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_BLK_DEV_OPTI621 is not set
> # CONFIG_BLK_DEV_TRM290 is not set
> # CONFIG_BLK_DEV_NS87415 is not set
> # CONFIG_IDE_CHIPSETS is not set
>
> #
> # Additional Block Devices
> #
> CONFIG_BLK_DEV_LOOP=m
> # CONFIG_BLK_DEV_MD is not set
> # CONFIG_BLK_DEV_RAM is not set
> # CONFIG_BLK_DEV_XD is not set
> CONFIG_PARIDE_PARPORT=y
> # CONFIG_PARIDE is not set
> # CONFIG_BLK_DEV_HD is not set
>
> #
> # Networking options
> #
> CONFIG_PACKET=m
> # CONFIG_NETLINK is not set
> CONFIG_FIREWALL=y
> # CONFIG_NET_ALIAS is not set
> # CONFIG_FILTER is not set
> CONFIG_UNIX=y
> CONFIG_INET=y
> # CONFIG_IP_MULTICAST is not set
> # CONFIG_IP_ADVANCED_ROUTER is not set
> # CONFIG_IP_PNP is not set
> CONFIG_IP_FIREWALL=y
> CONFIG_IP_FIREWALL_VERBOSE=y
> CONFIG_IP_TRANSPARENT_PROXY=y
> CONFIG_IP_ALWAYS_DEFRAG=y
> CONFIG_IP_ACCT=y
> CONFIG_IP_MASQUERADE=y
>
> #
> # Protocol-specific masquerading support will be built as modules.
> #
> CONFIG_IP_MASQUERADE_ICMP=y
>
> #
> # Protocol-specific masquerading support will be built as modules.
> #
> CONFIG_IP_MASQUERADE_IPAUTOFW=m
> # CONFIG_IP_MASQUERADE_IPPORTFW is not set
> # CONFIG_IP_ROUTER is not set
> # CONFIG_NET_IPIP is not set
> # CONFIG_NET_IPGRE is not set
> # CONFIG_IP_ALIAS is not set
> # CONFIG_SYN_COOKIES is not set
>
> #
> # (it is safe to leave these untouched)
> #
> # CONFIG_INET_RARP is not set
> CONFIG_IP_NOSR=y
> # CONFIG_SKB_LARGE is not set
> # CONFIG_IPV6 is not set
>
> #
> #
> #
> # CONFIG_IPX is not set
> # CONFIG_ATALK 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
> # CONFIG_NET_FASTROUTE is not set
> # CONFIG_NET_HW_FLOWCONTROL is not set
> # CONFIG_CPU_IS_SLOW is not set
> # CONFIG_NET_SCHED is not set
> # CONFIG_NET_PROFILE is not set
>
> #
> # SCSI support
> #
> CONFIG_SCSI=y
>
> #
> # SCSI support type (disk, tape, CD-ROM)
> #
> # CONFIG_BLK_DEV_SD is not set
> CONFIG_CHR_DEV_ST=y
> CONFIG_BLK_DEV_SR=y
> # CONFIG_BLK_DEV_SR_VENDOR is not set
> CONFIG_CHR_DEV_SG=y
>
> #
> # Some SCSI devices (e.g. CD jukebox) support multiple LUNs
> #
> # CONFIG_SCSI_MULTI_LUN is not set
> # CONFIG_SCSI_CONSTANTS is not set
> CONFIG_SCSI_LOGGING=y
>
> #
> # SCSI low-level drivers
> #
> # CONFIG_SCSI_7000FASST is not set
> # CONFIG_SCSI_AHA152X is not set
> CONFIG_SCSI_AHA1542=y
> # CONFIG_SCSI_AHA1740 is not set
> # CONFIG_SCSI_AIC7XXX is not set
> # 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_GDTH 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 is not set
> # CONFIG_SCSI_PAS16 is not set
> # CONFIG_SCSI_PCI2000 is not set
> # CONFIG_SCSI_PCI2220I is not set
> # CONFIG_SCSI_PSI240I 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_DC390T 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=y
> # CONFIG_EL1 is not set
> # CONFIG_EL2 is not set
> # CONFIG_ELPLUS is not set
> # CONFIG_EL16 is not set
> # CONFIG_EL3 is not set
> # CONFIG_VORTEX is not set
> # CONFIG_LANCE is not set
> # CONFIG_NET_VENDOR_SMC is not set
> # CONFIG_NET_VENDOR_RACAL 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_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=m
>
> #
> # CCP compressors for PPP are only built as modules.
> #
> # CONFIG_SLIP is not set
> # CONFIG_NET_RADIO is not set
> # CONFIG_TR is not set
> # CONFIG_SHAPER is not set
>
> #
> # Amateur Radio support
> #
> # CONFIG_HAMRADIO is not set
>
> #
> # ISDN subsystem
> #
> CONFIG_ISDN=y
> # CONFIG_ISDN_PPP is not set
> # CONFIG_ISDN_AUDIO is not set
> # CONFIG_ISDN_DRV_ICN is not set
> # CONFIG_ISDN_DRV_PCBIT is not set
> # CONFIG_ISDN_DRV_HISAX is not set
> # CONFIG_ISDN_DRV_SC is not set
> # CONFIG_ISDN_DRV_AVMB1 is not set
>
> #
> # CD-ROM drivers (not for SCSI or IDE/ATAPI drives)
> #
> # CONFIG_CD_NO_IDESCSI is not set
> CONFIG_CDROM=y
>
> #
> # Filesystems
> #
> # CONFIG_QUOTA is not set
> CONFIG_MINIX_FS=m
> CONFIG_EXT2_FS=y
> CONFIG_EXT2_COMPRESS=y
> CONFIG_EXT2_IND_BITMAP=y
> CONFIG_EXT2_USE_LZV1=y
> CONFIG_EXT2_USE_LZRW3A=y
> CONFIG_EXT2_USE_GZIP=y
> CONFIG_EXT2_USE_BZIP2=y
> CONFIG_GZ_HACK=y
> # CONFIG_EXT2_DEFAULT_COMPR_METHOD_LZV1 is not set
> # CONFIG_EXT2_DEFAULT_COMPR_METHOD_LZRW3A is not set
> # CONFIG_EXT2_DEFAULT_COMPR_METHOD_GZIP1 is not set
> CONFIG_EXT2_DEFAULT_COMPR_METHOD_GZIP3=y
> # CONFIG_EXT2_DEFAULT_COMPR_METHOD_GZIP6 is not set
> # CONFIG_EXT2_DEFAULT_COMPR_METHOD_GZIP9 is not set
> # CONFIG_EXT2_DEFAULT_COMPR_METHOD_BZIP2 is not set
> # CONFIG_EXT2_DEFAULT_CLUSTER_BITS_2 is not set
> # CONFIG_EXT2_DEFAULT_CLUSTER_BITS_3 is not set
> CONFIG_EXT2_DEFAULT_CLUSTER_BITS_4=y
> # CONFIG_EXT2_DEFAULT_CLUSTER_BITS_5 is not set
> CONFIG_ISO9660_FS=y
> CONFIG_JOLIET=y
> CONFIG_FAT_FS=m
> # CONFIG_MSDOS_FS is not set
> # CONFIG_UMSDOS_FS is not set
> CONFIG_VFAT_FS=m
> CONFIG_PROC_FS=y
> CONFIG_NFS_FS=m
> CONFIG_NFSD=m
> CONFIG_SUNRPC=m
> CONFIG_LOCKD=m
> CONFIG_CODA_FS=m
> CONFIG_SMB_FS=m
> CONFIG_SMB_WIN95=y
> # CONFIG_HPFS_FS is not set
> # CONFIG_NTFS_FS is not set
> # CONFIG_SYSV_FS is not set
> # CONFIG_AFFS_FS is not set
> # CONFIG_HFS_FS is not set
> # CONFIG_ROMFS_FS is not set
> CONFIG_AUTOFS_FS=y
> # CONFIG_UFS_FS is not set
> # CONFIG_ADFS_FS is not set
> # CONFIG_MAC_PARTITION is not set
> CONFIG_NLS=y
>
> #
> # Native Language Support
> #
> CONFIG_NLS_CODEPAGE_437=m
> # CONFIG_NLS_CODEPAGE_737 is not set
> # CONFIG_NLS_CODEPAGE_775 is not set
> # CONFIG_NLS_CODEPAGE_850 is not set
> # CONFIG_NLS_CODEPAGE_852 is not set
> # CONFIG_NLS_CODEPAGE_855 is not set
> # CONFIG_NLS_CODEPAGE_857 is not set
> # CONFIG_NLS_CODEPAGE_860 is not set
> # CONFIG_NLS_CODEPAGE_861 is not set
> # CONFIG_NLS_CODEPAGE_862 is not set
> # CONFIG_NLS_CODEPAGE_863 is not set
> # CONFIG_NLS_CODEPAGE_864 is not set
> # CONFIG_NLS_CODEPAGE_865 is not set
> # CONFIG_NLS_CODEPAGE_866 is not set
> # CONFIG_NLS_CODEPAGE_869 is not set
> # CONFIG_NLS_CODEPAGE_874 is not set
> CONFIG_NLS_ISO8859_1=m
> # CONFIG_NLS_ISO8859_2 is not set
> # CONFIG_NLS_ISO8859_3 is not set
> # CONFIG_NLS_ISO8859_4 is not set
> # CONFIG_NLS_ISO8859_5 is not set
> # CONFIG_NLS_ISO8859_6 is not set
> # CONFIG_NLS_ISO8859_7 is not set
> # CONFIG_NLS_ISO8859_8 is not set
> # CONFIG_NLS_ISO8859_9 is not set
> # CONFIG_NLS_KOI8_R is not set
>
> #
> # Character devices
> #
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_SERIAL=y
> # CONFIG_SERIAL_CONSOLE is not set
> # CONFIG_SERIAL_EXTENDED is not set
> # CONFIG_SERIAL_NONSTANDARD is not set
> CONFIG_PRINTER=y
> CONFIG_PRINTER_READBACK=y
> # CONFIG_MOUSE is not set
> # CONFIG_UMISC is not set
> # CONFIG_QIC02_TAPE is not set
> # CONFIG_APM is not set
> # CONFIG_WATCHDOG is not set
> # CONFIG_RTC is not set
> # CONFIG_VIDEO_DEV is not set
> # CONFIG_NVRAM is not set
> # CONFIG_JOYSTICK is not set
> # CONFIG_MISC_RADIO is not set
>
> #
> # Ftape, the floppy tape device driver
> #
> # CONFIG_FTAPE is not set
>
> #
> # Sound
> #
> # CONFIG_SOUND is not set
>
> #
> # Kernel hacking
> #
> # CONFIG_PROFILE is not set
> # CONFIG_MAGIC_SYSRQ is not set
> CONFIG_VGA_CONSOLE=y
>
> I tried commenting out the 16 MB swap partition from /etc/fstab, but got
> the same oops after rebooting. Here's what "free" said at that time:
>
> total used free shared buffers cached
> Mem: 30924 16992 13932 41444 2308
> - -/+ buffers: 14684 11624
> Swap: 0 0 0 5956
>
> I didn't have any modules loaded.
>
> Hardware: PC clone with 32 MB SDRAM, 150 MHz Cyrix 6x86L, VIA VT
> 82C585/VT 82C586 motherboard, two IDE hard drives, Tekram DC-300B
> (AHA-1542 clone), PCI NE2000 clone Ethernet with the Realtek 8029 chip,
> floppy, VGA, modem, and AT-compatible keyboard.
> ___
> Trevor Johnson
>
> - -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
> ------------------------------
>
> End of linux-kernel-digest V1 #1608
> ***********************************
>
> 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".

unsubscribe linux-kernel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:1.365 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site