On Mon, Oct 09, 2000 at 06:01:50PM +0200, Ingo Oeser wrote:
> Hi there,
>
> there has been a patch, which limits the amount of RAM used by
> ramfs.
>
> I didn't find this in the archives (neither public ones nor
> private). And no, I do NOT think I just dreamed about it ;-)
That would be mine
On Mon, 9 Oct 2000, Kurt Garloff wrote:
> On Mon, Oct 09, 2000 at 01:05:10PM +0200, Andre Tomt wrote:
> > The sym53c8xx driver handles this card nicely in u160scsi mode using
> > kernel 2.4testX, but I don't want that kernel on this machine. 2.2.17 does
> > not detect the card, and looking at t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I just wanted to let everyone know that we have changed the
cryptographic key for the Linux Kernel Archives. The reason is that
the original key was generated with an expiration date, and
unfortunately it appears that too much software
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 for
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 muc
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 us
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 u
> 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 your
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 that
> 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]
Please
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 conf
> (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 (b
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 be
> > 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 hid
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 to
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
ign
> > 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 v
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 implicati
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 to
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 th
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. Might
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 apolog
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.
Later
>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 suggest
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 appa
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 from
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
(XFree-3
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.
Y
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 happens
"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
searc
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 USB
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 on
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 1.1.2.2.2.4.1.7
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 of
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 linux-kerne
> 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, any-old
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 loo
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, speake
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 for
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.
-
T
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 com
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
wro
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 thi
"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
> >> un-c
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
ea
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 lo
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 allow
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 inf
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 b
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 t
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 off
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)) >> (PAGE
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 something.
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 doesn
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 is
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 m
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
corrup
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, gen
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 failed
> > 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
s
> 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 linux-k
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 b
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 fro
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 "unsubsc
> > 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 vga16f
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 genera
> 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 t
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 tw
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 ... ;)
Plea
> > 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 b
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 t
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 un
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 drop
> > 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 - a
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 - and
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 c
1 - 100 of 288 matches
Mail list logo
