Followup to: <[EMAIL PROTECTED]>
By author:Andre Hedrick <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
>
> Is there a limit?
> I keep getting barfs on an iso9960 image 4,592,353,280 of this size.
> Basically I am burning DVD's at 4.7GB tests before patching the kernel
> before 2.4
On Mon, 9 Oct 2000, Rick Haines wrote:
> It works fine in Win2k. After reading Andre's comment I think it could
> be a udf problem as well because iso9660 cd's work fine. In fact, after
> mounting an iso9660 cdr I can now mount dvd's every try.
I tend to agree that it is FS layer and not so
Andreas Dilger wrote:
> Albert D. Cahalan wrote:
> > X, and any other big friendly processes, could participate in
> > memory balancing operations. X could be made to clean out a
>
> Gerrit Huizenga wrote:
> > Anyway, there is/was an API in PTX to say (either from in-kernel or through
> > some
Hi Dave,
I tried the patch, but the result is the same... Uncompressing Linux..., now
booting the kernel..., NOTHING
These Winchips need all the help they can get, so if you know something else I
might try...
Cheers//Frank
--
W ___
## o o\/ Frank de
Date:Tue, 10 Oct 2000 02:21:48 +0200
From: Bernd Eckenfels <[EMAIL PROTECTED]>
We will see who feels responsible for adding it to the kernel
source. Alexey? Andi? Davem? Alan?
I have applied the fix, and will send it to Linus.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
> Rik van Riel wrote:
> > > How about SIGTERM a bit before SIGKILL then re-evaluate the OOM
> > > N usecs later?
> >
> > And run the risk of having to kill /another/ process as well ?
> >
> > I really don't know if that would be a wise thing to do
> > (but feel free to do some tests to see if
Date: Mon, 09 Oct 2000 11:44:34 +0200
From: Jorg de Jong <[EMAIL PROTECTED]>
attached you will find my patch again
Patch applied, thanks for being so patient.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Hi,
I want to setup RAID.
I am working on kernel version 2.2.12.
I am using RAID patches available.
I create a RAID configuring file called
/etc/raidtab
#mkraid /dev/md0/*md0 is the device I am
selecting*/
After this when I check /proc/mdstat , I find
> If init dies the kernel hangs solid anyway
Init should never die. If we get to do_exit in init we'll panic which is
the right thing to do (reboot on critical systems).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Periodically, I get the following error with the 2.4.0test9 kernel:
spurious 8259A interrupt: IRQ7.
I did not receive this error with the 2.0.36 kernel that came stock on my
slack installation. However, 2 things have been changed; I configured the
PAS16 to use IRQ7 (I don't recall its exact
> (but I'd be curious if somebody actually manages to
> trick the OOM killer into killing init ... please
> test a bit more to see if this really happens ;))
In a non-real-world situation, yes. (mem=3500k, many drivers, init=/bin/bash,
tried to enter a command). Since the process in question
Hi Linus
I just resend this patch (the first time I forgot to put the
[PATCH] field). It fixes a leak in swapon reported by marcelo
quite time ago.
Later, Juan.
> "marcelo" == Marcelo de Paula Bezerra <[EMAIL PROTECTED]> writes:
Hi
sorry for the delay (this problem has
> > Then if you select USB HID support, that builds the hid driver,
> > which handles mice, keyboards, joysticks, gamepads, speaker
> > buttons, any-old-kind-of buttons, toaster buttons, etc.
> >
> > OTOH, if you want just some basic USB mouse & keyboard support,
> > you don't have to use the
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> how about registering the full path (or inode number of the executable?),
> the owner, and an optional high water mark of memory consumption, over
> which the process is considered to be leaking memory and gets added to the
> algorithm of processes
how about registering the full path (or inode number of the executable?),
the owner, and an optional high water mark of memory consumption, over
which the process is considered to be leaking memory and gets added to the
algorithm of processes to kill? this is because while normally i want to
> > Dear.
> >
> > I use linux-2.0.39-pre8, and work fine.
> > I wait for releasing linux-2.0.39,
> >
> > when do relese linux-2.0.39?
>
> Well, I'm still investigating some problems that some users are
> experiencing. However, if I can't resolve those within a reasonable
> time, I'll release
On Mon, 9 Oct 2000, Matthew Dharm wrote:
> On Mon, Oct 09, 2000 at 09:25:38PM -0400, Byron Stanoszek wrote:
> > echo "init" > /proc/sys/oom-ignore
> > echo "httpd" >> /proc/sys/oom-ignore
> > echo "parallel-fft" >> /proc/sys/oom-ignore
> > etc...
>
> I'd be concerned with the security
On Mon, Oct 09, 2000 at 11:22:44PM +0200, Jens Axboe wrote:
> On Mon, Oct 09 2000, Rick Haines wrote:
> > I'm having real trouble mounting a dvd (udf filesystem) in my Pioneer
> > 104S drive. It usually failes with:
> > mount: wrong fs type, bad option, bad superblock on /dev/dvd,
> >or
On Mon, Oct 09, 2000 at 09:25:38PM -0400, Byron Stanoszek wrote:
> On Tue, 10 Oct 2000, Jochen Striepe wrote:
> > What about a user-defined list of "wishes"? The administrator should be
> > enabled to enforce that specific processes are to be terminated only as a
> > last resource (syslogd), or
On Tue, 10 Oct 2000, Jochen Striepe wrote:
> Hi, a question regarding the OOM process killer...
>
> Hmm, sometimes daemon-like processes (e.g. web servers) only need root
> privileges to open a network port<1024 - you may start them as non-root
> if they do not need such a privileged port.
This has suddenly started happening tonight. Also happens with test9
and test10-pre1 but they lock-up hard, to the extent that Atl-SysRQ+B is
needed, box doesn't respond to pings etc.
The only thing that's changed recently is the addition of a new PS/2
keyboard.
My first Oops report so
Date: Fri, 6 Oct 2000 00:19:20 -0700
From: Richard Henderson <[EMAIL PROTECTED]>
Seems to me that if you want to play games and be sure that they
stay played, that you'd have to put all the variables into a
struct.
Indeed, I've hacked this up and will send the fix to linus.
>Hence, yes I can provide an interface from the kernel to log a trace event
>with a variable length buffer, but I don't think that taking away the
statically
>defined trace points is the right thing to do. (I might have gotten this
>completely wrong, though ... My presumption about your
whoops. Here's a resend with the actual patch attached. :)
one of those days I guess?
Attached is a patch to include 3dfx voodoo5 framebuffer support.
Looking for comments.
Doesn't do much other than check for the voodoo5 device id. It also
doesn't do anything voodoo5 specific. (voodoo5 is
Hi there,
redhat 6.2 will (should) install on this system. Maybe you have to use
the upgraded driver / update disk and maybe you have to use text
install. However, the installed kernel will fail during boot because it
tries to disable the cpuid serial number on your system (of course there
isn't
On Tue, Oct 10, 2000 at 10:08:13AM +0900, Seiichi Nakashima wrote:
> Dear.
>
> I use linux-2.0.39-pre8, and work fine.
> I wait for releasing linux-2.0.39,
>
> when do relese linux-2.0.39?
Well, I'm still investigating some problems that some users are
experiencing. However, if I can't resolve
Dear.
I use linux-2.0.39-pre8, and work fine.
I wait for releasing linux-2.0.39,
when do relese linux-2.0.39?
On Mon, Oct 09, 2000 at 05:19:37PM -0700, Matthew Dharm wrote:
>I'm not sure this is correct -- the options that this if conditional
>controls are the Keyboard and Mouse _Boot_Protocol_ support, which is
>separate form the regular HID support -- I believe it's for motherboards
>which can boot
See Documentation/networking/ip-sysctl.txt, section "tcp_mem".
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
First, my apologies for an OT request here. We recently upgraded one of
our machines here to a Duron 700Mhz running on a QDI mainboard, and haven't
been able to get a few recent Linux distros to install reasonably on it.
RH6.2 installs but chokes constantly whenever we exit the X-server
Mitchell Blank Jr writes:
> [EMAIL PROTECTED] wrote:
> > 4. Boot Time Failures
> [...]
> > * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
> >more info)
>
> I _highly_ suspect that this is not a 2.4 bug but is instead user error.
> I've seen it several times.
On Mon, 9 Oct 2000 15:29:53 +0200, Lars Callenbach blurted forth:
> Hallo,
>
> I´m trying the 2.4-9 kernel and sometimes it crashes. I haven´t found any hint for
>the crashes but I´ve got messages like the following one in /var/log/messages:
[snip]
> Perhaps someone can explain what
"Dunlap, Randy" wrote:
> Then if you select USB HID support, that builds the hid driver,
> which handles mice, keyboards, joysticks, gamepads, speaker
> buttons, any-old-kind-of buttons, toaster buttons, etc.
>
> OTOH, if you want just some basic USB mouse & keyboard support,
> you don't have
> > I didn't realize USB had this level of functionality.
>
> Hrm... I wonder if anyone out there is making USB Toasters That would
> be really nice -- have a nice snack waiting for me when I get home, etc. ;)
I remember someone made a /dev/coffee to control their coffe machine. Do a
On Mon, Oct 09, 2000 at 04:17:01PM -0700, Dunlap, Randy wrote:
> . OOPS in usb-storage from the error-recovery handler. {CRITICAL}
> (Matthew Dharm; [EMAIL PROTECTED])
This is fixed as of test9.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux
Matthew Dharm wrote:
>
> I'm not sure this is correct -- the options that this if conditional
> controls are the Keyboard and Mouse _Boot_Protocol_ support, which is
> separate form the regular HID support -- I believe it's for motherboards
> which can boot from a USB keyboard.
>
> Can somone
Every nit needs picking.
Index: 0-test10-pre1.1/Makefile
--- 0-test10-pre1.1/Makefile Tue, 03 Oct 2000 12:24:51 +1100 kaos
(linux-2.4/B/c/27_Makefile 1.1.2.2.2.4.1.7.1.3.1.5.2.5 644)
+++ 0-test10-pre1.1(w)/Makefile Tue, 10 Oct 2000 11:33:03 +1100 kaos
+(linux-2.4/B/c/27_Makefile
On Tue, Oct 10, 2000 at 12:31:08AM -0700, James Simmons wrote:
> > Then if you select USB HID support, that builds the hid driver,
> > which handles mice, keyboards, joysticks, gamepads, speaker
> > buttons, any-old-kind-of buttons, toaster buttons, etc.
>
> I didn't realize USB had this level
On Mon, Oct 09 2000, Jeff V. Merkey wrote:
>
> Jens,
>
> DVD should always use UDF? This may explain what we are seeing as well.
Yes, that is the preferred way of doing it.
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe
> Not needed. This is a misunderstanding. Maybe that needs
> some work (in Help maybe), but not this patch.
Yes please. It can be very misleading.
> Then if you select USB HID support, that builds the hid driver,
> which handles mice, keyboards, joysticks, gamepads, speaker
> buttons,
What I'd personally like to see in the OOM should cover the following
scenarios, theoretically:
1. User does a malloc() bomb. This should be caught instantly and killed when
there is no memory left to allocate. This covers tons of low-sized
mallocs() as well as a timed delay infinite
Not needed. This is a misunderstanding. Maybe that needs
some work (in Help maybe), but not this patch.
You have the first USB option ("Support for USB") set to Y,
right?
Then if you select USB HID support, that builds the hid driver,
which handles mice, keyboards, joysticks, gamepads,
On Mon, Oct 09, 2000 at 11:44:34AM +0200, Jorg de Jong wrote:
> your just a bit off here, I believe Gerhard has posted this bug
> a number of times, further more I have submitted a fix for this
> bug, but has still not been accepted. Neither has there been any feedback
> on why ?
the address
Oops. Sorry folks. My patch was too big to be posted on the mailing
list. Uncompressed it is 63K. Here it is compressed.
>Hi!
>
> This patch places code common to both vgacon and vga16fb into a common
>file (vga.c). The utlimate goal is to have the ability to go from vgacon
>to fbcon and back.
> This patch fixes a minor config error for drivers/usb/Config.in. When you
> select USB Human Interface Device (HID) support I assume you should be
> able to select a USB mouse and/or USB keyboard. With the current Config.in
you can't.
HIDBP is an alternative the existing code is correct.
-
I'm not sure this is correct -- the options that this if conditional
controls are the Keyboard and Mouse _Boot_Protocol_ support, which is
separate form the regular HID support -- I believe it's for motherboards
which can boot from a USB keyboard.
Can somone on the linux-usb-devel mailinglist
New variant of ext2 patch is available. Patch is against -test9
and -test10-pre1 and it lives on ftp.math.psu.edu/pub/viro/ext2-patch-9e.gz
Interface between namei.c and dir.c remains the same, dir.c got
serious cleanup compared to the previous version. Handling of records with
This patch fixes a minor config error for drivers/usb/Config.in. When you
select USB Human Interface Device (HID) support I assume you should be
able to select a USB mouse and/or USB keyboard. With the current Config.in
you can't.
--- Config.in.orig Tue Oct 10 00:10:06 2000
+++ Config.in
Hi!
This patch places code common to both vgacon and vga16fb into a common
file (vga.c). The utlimate goal is to have the ability to go from vgacon
to fbcon and back. At present you can't do this. This will allow for
easier debugging in the future for fbdev drivers.
-
To unsubscribe from
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> Date: Mon, 9 Oct 2000 19:13:25 -0400 (EDT)
>
> >> From: Linus Torvalds <[EMAIL PROTECTED]>
>
> >> One of the biggest bitmaps is the background bitmap. So you have a
> >> client that uploads it to X and then goes away. There's nobody to
> >>
Attached is a patch to include 3dfx voodoo5 framebuffer support.
Looking for comments.
Doesn't do much other than check for the voodoo5 device id. It also
doesn't do anything voodoo5 specific. (voodoo5 is apparently backward
compatible to the voodoo3) But I changed some of the code to make it
We are running some fairly intensive tests with XFS
and with HIGHMEM on an X86 machine with 4G of memory and
4 cpus. The linux-kernel version is test8. The code
also contains Stephen Tweedie's highmem-kiobuf.
What we see is that after a while of running,
smp_call_function getting stuck in the
On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote:
> > If the oom killer kills a thing like init by mistake
> That only happens in the "random" OOM killer 2.2 has ...
[OOM killer war]
Hi there,
before you argue endlessly about the "Right OOM Killer (TM)", I
did a small patch to
Tim,
I forwarded this one to the lawyers.
Thanks
Jeff
Timothy Roscoe wrote:
>
> For what it's worth, the system was called "Jackdaw" and was written by
> Mike Challis. It was in extensive use on the University's MVT/MVS/MVSXA
> mainframe for many years as the database for holding user
On Mon, 9 Oct 2000, Alan Cox wrote:
> > Is there a limit?
> > I keep getting barfs on an iso9960 image 4,592,353,280 of this size.
>
> That seems reasonable
>
> > Basically I am burning DVD's at 4.7GB tests before patching the kernel
> > before 2.4 for expanded DVD support.
>
> You should be
On Mon, 9 Oct 2000, Albert D. Cahalan wrote:
> Jim Gettys writes:
> >> From: Linus Torvalds <[EMAIL PROTECTED]>
>
> >> One of the biggest bitmaps is the background bitmap. So you have a
> >> client that uploads it to X and then goes away. There's nobody to
> >> un-count to by the time X decides
Hi Ted,
Here's an updated USB 2.4 TODO list.
The new entries (changes) are marked with '+'.
~Randy
USB Status/Problems in 2.4.0-test9
2000-October-09
1. Should [already] Be Fixed
. hid joystick handling (patch from Vojtech) (2.4.0.9.4)
Jim Gettys writes:
>> From: Linus Torvalds <[EMAIL PROTECTED]>
>> One of the biggest bitmaps is the background bitmap. So you have a
>> client that uploads it to X and then goes away. There's nobody to
>> un-count to by the time X decides to switch to another background.
>
> Actually, the big
On Tue, Oct 10, 2000 at 12:55:33AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
> > Simple. Each interrupt stack is, say, 8 pages. You have an array
> > of N interrupt stacks. Then you calculate
> >
> >cpu_id = (sp & ~(INT_STACK_SIZE-1)) >>
On Tue, 10 Oct 2000, bert hubert wrote:
> On Mon, Oct 09, 2000 at 02:38:10PM -0700, Linus Torvalds wrote:
>
> > So the process that gave X the bitmap dies. What now? Are we going to
> > depend on X un-counting the resources?
> >
> > I'd prefer just X having a higher "mm nice level" or
On Mon, 9 Oct 2000, Byron Stanoszek wrote:
> On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > Anyway, there is/was an API in PTX to say (either from in-kernel or through
> > some user machinations) "I Am a System Process". Turns on a bit in the
> > proc struct (task struct) that made it exempt
On Mon, Oct 09, 2000 at 11:45:18PM +0100, Kenn Humborg wrote:
> Simple. Each interrupt stack is, say, 8 pages. You have an array
> of N interrupt stacks. Then you calculate
>
>cpu_id = (sp & ~(INT_STACK_SIZE-1)) >> (PAGE_SHIFT + 3);
>
> Actually, I'd put the interrupt stack and any other
> > I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> > behind an I/O interface that is slower than ideal
>
> Where would you put it for IA32 ? I don't know any free MSR that could
> be abused for that, and acessing MSRs is insanely slow anyways. Any
> other ideas ?
Date:Tue, 10 Oct 2000 00:44:58 +0200
From: "Andi Kleen" <[EMAIL PROTECTED]>
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> I dont actually know a CPU that doesnt have one in SMP mode. Its just often
> behind an I/O interface that is slower than ideal
Where
Jens,
DVD should always use UDF? This may explain what we are seeing as well.
Jeff
Jens Axboe wrote:
>
> On Mon, Oct 09 2000, Andre Hedrick wrote:
> > > You should be burning these disks UDF formatted
> >
> > But the original DVD was an iso9660 image, also where are tools for doing
> > UDF?
On Mon, Oct 09, 2000 at 11:11:15PM +0200, Frank van Maarseveen wrote:
> On Sat, Sep 16, 2000 at 07:22:38PM +0200, Alain Knaff wrote:
> > The following patch (against 2.4.0-test8) restores floppy ioctl functionality,
> > which has been broken in 2.4.0-test6-pre7. It now tests for fake
> > ioctl's,
On Tue, Oct 10, 2000 at 12:36:35AM +0200, Andi Kleen wrote:
> On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > > I think I'll go for the 'current is in a well-known register'
> > > approach and see how this goes...
> >
> > Failing that the 2.0 approach will work, current is a global
On Mon, Oct 09, 2000 at 11:41:13PM +0100, Alan Cox wrote:
> > The problem is where to get the cpuid from (see how smp_processor_id
> > is currently defined ;) When you don't have a hidden register in the
> > CPU you're screwed.
> > [x86-64 has one btw]
>
> I dont actually know a CPU that
On Mon, Oct 09 2000, Andre Hedrick wrote:
> > You should be burning these disks UDF formatted
>
> But the original DVD was an iso9660 image, also where are tools for doing
> UDF?
Most likely bridged iso9660/udf. But just use UDF -- grab the UDF off
the cvs tree, it comes with tools to make UDF
> The problem is where to get the cpuid from (see how smp_processor_id
> is currently defined ;) When you don't have a hidden register in the
> CPU you're screwed.
> [x86-64 has one btw]
I dont actually know a CPU that doesnt have one in SMP mode. Its just often
behind an I/O interface that
On Mon, Oct 09, 2000 at 02:38:10PM -0700, Linus Torvalds wrote:
> So the process that gave X the bitmap dies. What now? Are we going to
> depend on X un-counting the resources?
>
> I'd prefer just X having a higher "mm nice level" or something.
I wonder how many megabytes we can fill with all
Andre,
Here's the info you called about today. The DVD next door is a SCSI (I
thought it was an ATAPI device, but it's SCSI). The other burner with
the speed=8 problem is the MATSHITA and it is an ATAPI device. Here's
the technical info. This is the drive that returned all the packet
On Mon, 9 Oct 2000, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
You can also still
On Mon, Oct 09, 2000 at 11:30:50PM +0100, Alan Cox wrote:
> > I think I'll go for the 'current is in a well-known register'
> > approach and see how this goes...
>
> Failing that the 2.0 approach will work, current is a global in uniprocessor
> and a #define to an array indexed by cpu id in smp
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote:
> Anyway, there is/was an API in PTX to say (either from in-kernel or through
> some user machinations) "I Am a System Process". Turns on a bit in the
> proc struct (task struct) that made it exempt from death from a variety
> of sources, e.g. OOM,
On Mon, Oct 09, 2000 at 04:37:38PM +, Zdenek Kabelac wrote:
> I'm having some serious problems with parallel port ZIP with latest
> 2.4.0-test9 kernel
> Oct 9 16:57:23 dual kernel: Detected scsi removable disk sda at scsi0,
> channel
> Oct 9 16:57:24 dual kernel: sda : READ CAPACITY
> > You should be burning these disks UDF formatted
>
> But the original DVD was an iso9660 image, also where are tools for doing
> UDF?
I dont know where the DVD format building tools are, but the isofs code won't
handle > 4Gig. I guess you could rewrite bits of it to do so if you needed the
> I think I'll go for the 'current is in a well-known register'
> approach and see how this goes...
Failing that the 2.0 approach will work, current is a global in uniprocessor
and a #define to an array indexed by cpu id in smp
-
To unsubscribe from this list: send the line "unsubscribe
Largely VM balancing and OOM things (get rid of the VM livelock that
existed in test9), and USB fixes.
And a number of random driver fixes (SMP locking on network drivers, what
not).
Linus
-
- pre1:
- Roger Larsson: ">=" instead of ">" to make the VM not get stuck.
On Mon, 9 Oct 2000, Alan Cox wrote:
> > Is there a limit?
> > I keep getting barfs on an iso9960 image 4,592,353,280 of this size.
>
> That seems reasonable
>
> > Basically I am burning DVD's at 4.7GB tests before patching the kernel
> > before 2.4 for expanded DVD support.
>
> You should be
On Tue, Oct 10, 2000 at 09:04:30AM +1100, Keith Owens wrote:
> On 9 Oct 2000 11:08:36 -0700,
> [EMAIL PROTECTED] (Linus Torvalds) wrote:
> >Note that there are alternative approaches. For example, you could make
> >the interrupt stack be in the same multi-page as the regular stack, and
> >switch
> Is there a limit?
> I keep getting barfs on an iso9960 image 4,592,353,280 of this size.
That seems reasonable
> Basically I am burning DVD's at 4.7GB tests before patching the kernel
> before 2.4 for expanded DVD support.
You should be burning these disks UDF formatted
-
To unsubscribe
Is there a limit?
I keep getting barfs on an iso9960 image 4,592,353,280 of this size.
Basically I am burning DVD's at 4.7GB tests before patching the kernel
before 2.4 for expanded DVD support.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line
> > While working on vgacon I noticed their are 2 cli() in vga_vesa_blank
> > that are excuted one after another. Is their are a reason for this or
> > shoudl it be just one cli()?
>
> If you look at vgacon.c you still see remains of what the code used to
> look like. Now comapare with
At Sequent, we found that there are a small set of processes which are
"critical" to the system's operation in that they should not be killed
on swap shortage, memory shortage, etc. This included things like init,
potentially inetd, the swapper, page daemon, clusters heartbeat daemon,
and
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Mon, 9 Oct 2000 14:50:51 -0700 (PDT)
> To: Jim Gettys <[EMAIL PROTECTED]>
> Cc: Alan Cox <[EMAIL PROTECTED]>, Andi Kleen <[EMAIL PROTECTED]>,
> Ingo Molnar <[EMAIL PROTECTED]>, Andrea Arcangeli <[EMAIL PROTECTED]>,
> Rik van Riel
On Mon, Oct 09, 2000 at 08:56:29PM -0700, James Simmons wrote:
> While working on vgacon I noticed their are 2 cli() in vga_vesa_blank
> that are excuted one after another. Is their are a reason for this or
> shoudl it be just one cli()?
If you look at vgacon.c you still see remains of what
On 9 Oct 2000 11:08:36 -0700,
[EMAIL PROTECTED] (Linus Torvalds) wrote:
>Note that there are alternative approaches. For example, you could make
>the interrupt stack be in the same multi-page as the regular stack, and
>switch them both at task-switch time - just allocate four pages instead
>of
On Mon, 9 Oct 2000, Aaron Sethman wrote:
> I think the run time should probably be accounted into to this
> as well. Basically start knocking off recent processes first,
> which are likely to be childless, and start working your way up
> in age.
I'm almost getting USENET flashbacks ... ;)
> > across AF_UNIX sockets so the mechanism is notionally there to provide the
> > credentials to X, just not to use them
>
> The problem is that there is no way to keep track of them afterwards.
If you use mmap for your allocator then beancounter will get it right. Every
resource knows which
On Mon, 9 Oct 2000, James Sutherland wrote:
> On Mon, 9 Oct 2000, Ingo Molnar wrote:
>
> > On Mon, 9 Oct 2000, Rik van Riel wrote:
> >
> > > > so dns helper is killed first, then netscape. (my idea might not
> > > > make sense though.)
> > >
> > > It makes some sense, but I don't think OOM is
On Mon, 9 Oct 2000, Jim Gettys wrote:
>
>
> On Date: Mon, 9 Oct 2000 14:38:10 -0700 (PDT), Linus Torvalds
><[EMAIL PROTECTED]>
> said:
>
> >
> > The problem is that there is no way to keep track of them afterwards.
> >
> > So the process that gave X the bitmap dies. What now? Are we going
On Date: Mon, 9 Oct 2000 14:38:10 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
said:
>
> The problem is that there is no way to keep track of them afterwards.
>
> So the process that gave X the bitmap dies. What now? Are we going to
> depend on X un-counting the resources?
>
X has to
On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > I'd prefer just X having a higher "mm nice level" or something.
>
> Which it has, because:
>
> 1) CAP_RAW_IO
> 2) p->euid == 0
Oh, I agree, but we might want to generalize this a bit so that root could
say "this process is important" and then
> > Sounds like one needs in addition some mechanism for servers to "charge"
> clients for
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate client
> > (at least when on machine).
>
> Definitely -
On Mon, 9 Oct 2000, Linus Torvalds wrote:
> On Mon, 9 Oct 2000, Alan Cox wrote:
> > > consumption. X certainly knows on behalf of which connection resources
> > > are created; the OS could then transfer this back to the appropriate client
> > > (at least when on machine).
> >
> > Definitely -
On Mon, 9 Oct 2000, Alan Cox wrote:
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate client
> > (at least when on machine).
>
> Definitely - and this is present in some non Unix OS's. We do pass
On Mon, 9 Oct 2000, Ingo Molnar wrote:
> On Mon, 9 Oct 2000, Rik van Riel wrote:
>
> > Would this complexity /really/ be worth it for the twice-yearly OOM
> > situation?
>
> the only reason i suggested this was the init=/bin/bash, 4MB
> RAM, no swap emergency-bootup case. We must not kill init
On Mon, Oct 09, 2000 at 10:28:38PM +0100, Alan Cox wrote:
> > Sounds like one needs in addition some mechanism for servers to "charge" clients
>for
> > consumption. X certainly knows on behalf of which connection resources
> > are created; the OS could then transfer this back to the appropriate
On Mon, 9 Oct 2000, David Ford wrote:
> Not if "init" is a particular program running on a router floppy for
> example. The system may be designed to be a router and the userland
> monitor/control program is the only thing that runs and consumes 90% of the
> memory. If a forked or spawned
1 - 100 of 528 matches
Mail list logo
