Messages in this thread | | | Date | Fri, 20 Feb 1998 09:07:38 +0900 | From | Ko Young Ju <> | Subject | Re: 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(¤t_lock, flags); > if (CURRENT != NULL && CURRENT->rq_status == RQ_INACTIVE) { > - - restore_flags(flags); > + spin_unlock_irqrestore(¤t_lock, flags); > return; > }; > > @@ -451,6 +450,7 @@ > */ > if( SDev->host->in_recovery ) > { > + spin_unlock_irqrestore(¤t_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(¤t_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(¤t_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(¤t_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
| |