On Wed, Aug 24, 2005 at 10:38:59PM +0100, Al Viro wrote:
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
Most of the remaining stuff is for
m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
* Esben Nielsen [EMAIL PROTECTED] wrote:
Yes, spin_lock(lock) is blocking since lock is mutex, not a spinlock
under preempt-rt. But isn't it easy to fix? Replace the two lines by
spin_lock_irqsave(flags). That would work for both preempt-rt and
!preempt-rt.
at this moment we do not
look at http://www.kernelnewbies.org
also it has a section on books. you can also use IRC #kernelnewbies
On 8/25/05, Shwetha V [EMAIL PROTECTED] wrote:
Could anyone inform which will be a good guide to start learning the linux
kernel programming.
--
Shwetha V
Software Engineer -
* Jens Axboe [EMAIL PROTECTED] wrote:
There can quite easily be lots of pending IO for the io_context (and,
in CFQ's case, below cfq_io_contexts), task exiting is completely
decoupled from any pending io.
yes, but that only affects the io_context reference count. Actual new
use of
On Wed, 2005-08-24 at 14:46 -0700, Ravikiran G Thirumalai wrote:
Following patch moves a few static 'read mostly' variables to the
.data.read_mostly section. Typically these are vector - irq tables,
boot_cpu_data, node_maps etc., which are initialized once and read from
often and rarely
DocBook: fix kernel-api documentation generation
This patch changes a macro definition so that kernel-doc can understand it.
Signed-off-by: Martin Waitz [EMAIL PROTECTED]
---
include/sound/pcm.h |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
Index:
On Thu, 2005-08-25 at 09:54 +0530, raja wrote:
[...]
Is There Any function in c to caliculate the exact time taken to
execute block of code(in micro sec and milli sec and minuits and hours).
thanking you,
Do you mean system-time, user-space-time or the time it took in the real
world?
25.08.2005 03:02, Daniel Brockman wrote/a écrit:
Hi list,
If I understand correctly, packets sent to the all-ones
broadcast address only go out through a single interface.
Hello,
I have some blur memories about this kind of issue, so my answer my be
wrong on some points...
My question is
Hi,
AMD's CodeAnalyst is the right tool for you. It is based on Oprofile.
It can be free downloaded from AMD website.
Best Regards
Bill Xie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sushant Sharma
Sent: Thursday, August 25, 2005 10:52 AM
To:
Jan Blunck [EMAIL PROTECTED] wrote:
IMO sys_readahead() doesn't make sense if the file is opened with
O_DIRECT, because the page cache is stuffed but never used. Therefore
this patch changes that by letting the call return with -EINVAL.
a) It doesn't hurt, it's just a bit of a silly thing
Hello,
This optimizes bh_lru_install(). It's a hot spot I think. The bh_lru is well
manipulated now so we can use put_bh() as a substitute for the first __brelse()
here, and a bogus BUG_ON() can be removed safely. We evict at the right place
too. Boot tested.
Coywolf
Signed-off-by:
Hello,
This cleanups up alloc_buffer_head(), by using a single get_cpu_var().
Boot tested.
Coywolf
Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---
buffer.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
--- 2.6.13-rc6-mm2/fs/buffer.c~orig 2005-08-23
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return v-counter;} on all
architectures. (keywords : sysctl, /proc/sys/fs/file-nr,
On Wed, Aug 24, 2005 at 06:20:31PM -0700, Chris Wright wrote:
Call security hooks conditionally if the security_op is filled out.
Branches can be more efficient than the unconditional indirect function
call. Inspired by patch from Kurt Garloff [EMAIL PROTECTED].
Signed-off-by: Chris Wright
Thanks a lot, Al!
On Thu, 25 Aug 2005, Al Viro wrote:
encapsulates the rest of arch-dependent operations with thread_info access.
Two new helpers - setup_thread_info() and end_of_stack(). For normal
case the former consists of copying thread_info of parent to new thread_info
and the latter
Just a bit of food for thought. There seem to be two different kinds
of workloads for non-local filesystems. Bandwidth intensive workloads
where files are read and written. Cache intensive workloads (like
kernel compiles) where performance directly relates to how
efficiently you can make
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
This patch assumes that atomic_read() is a plain {return v-counter;} on
all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own sysctl handler for it,
probably
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return v-counter;} on all
On Čt 25-08-05 10:36:31, Shaohua Li wrote:
On Wed, 2005-08-24 at 10:50 +0200, Pavel Machek wrote:
Hi!
diff -puN arch/i386/power/cpu.c~mcheck_resume arch/i386/power/cpu.c
--- linux-2.6.13-rc6/arch/i386/power/cpu.c~mcheck_resume
2005-08-23 09:32:13.054008584 +0800
+++
--- Andy Isaacson [EMAIL PROTECTED] a écrit :
The first register write will be completed before the second register
write because you use writel, which is defined to have the semantics you
want. (It uses a platform-specific method to guarantee this, possibly
volatile or asm(eieio) or
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 10:45:12AM +0200, Eric Dumazet wrote:
This patch assumes that atomic_read() is a plain {return v-counter;} on
all architectures. (keywords : sysctl, /proc/sys/fs/file-nr, proc_dointvec)
But that's not true. You need to write you own
Arjan van de Ven a écrit :
On Thu, 2005-08-25 at 10:45 +0200, Eric Dumazet wrote:
This patch removes filp_count_lock spinlock, used to protect
files_stat.nr_files.
Just use atomic_t type and atomic_inc()/atomic_dec() operations.
This patch assumes that atomic_read() is a plain {return
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
But that's not true. You need to write you own sysctl handler for it,
probably worth adding a generic atomic_t sysctl handler while you're
at it.
I checked linux-2.6.13-rc7 tree, and atomic_read() is just a wrapper to
read
Alan Cox wrote:
On Mer, 2005-08-24 at 11:43 -0500, Kumar Gala wrote:
The following set of patches removes the use and existence of
asm/segment.h from the architecture ports
You've broken various things by doing this because some driver code
rightly or wrongly uses segment.h. That is
On Wed, 24 Aug 2005, Al Viro wrote:
It does, no (build) regressions. BTW, tree is not far from allmodconfig
buildable on a bunch of targets now - yesterday pile of fixes was about
half of the set needed for that. Most of the remaining stuff is for
m68k (and applies both to Linus' tree and
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
diff -urN RC13-rc7/sound/oss/dmasound/dmasound_paula.c
RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_paula.c
--- RC13-rc7/sound/oss/dmasound/dmasound_paula.c 2005-06-17
15:48:29.0 -0400
+++
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
diff -urN RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h
RC13-rc7-amigaints/include/asm-m68k/amigaints.h
--- RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h2005-06-17
15:48:29.0 -0400
+++
On Wed, Aug 24, 2005 at 02:09:55PM -0600, Bjorn Helgaas wrote:
On Wednesday 24 August 2005 10:53 am, Kumar Gala wrote:
Removed IA64 architecture specific users of asm/segment.h and
asm-ia64/segment.h itself
I posted a similar patch a month ago, but I only removed the
arch/ia64 includes
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
+static inline void setup_thread_info(struct task_struct *p, struct
thread_info *ti)
+{
+ *ti = *p-thread_info;
+}
+
- *ti = *orig-thread_info;
*tsk = *orig;
+ setup_thread_info(tsk, ti);
tsk-thread_info = ti;
this patch adds atomic ops where there were none before
nope... a spinlock/spinunlock contains atomic ops.
unlock usually doesn't but ok
for those architectures that need atomics for read (parisc? arm?)
not today. No atomic needed for read.
however.. wouldn't it be better
On Thu, Aug 25, 2005 at 02:24:56AM -0700, Zachary Amsden wrote:
Yes, agree totally, i386 _requires_ asm/segment.h. It is used in
low-level trap handling and bootup code from assembly files. In
addition,
but keeping the header under that name will just encorage people
to put it back into
On Iau, 2005-08-25 at 11:14 +0200, moreau francis wrote:
I'm compiling Linux kernel for a MIPS32 cpu. On my platform, writel seems
expand to:
static inline writel(u32 val, volatile void __iomem *mem)
{
volatile u32 *__mem;
u32 __val;
__mem =
On 8/25/05, Shwetha V [EMAIL PROTECTED] wrote:
Could anyone inform which will be a good guide to start learning the linux
kernel programming.
Personally I've greatly enjoyed
Linux Kernel Development, 2ed http://rlove.org/kernel_book/
and
Linux Device Drivers, Third Edition
Two cases:
# uname -a; free | grep Mem; ls -l /proc/kcore
Linux v100 2.6.11-1.1166sp1 #1 Fri Mar 4 20:41:51 EST 2005 sparc64 sparc64
sparc64 GNU/Linux
Mem: 1031152 100976 930176 0 22208 32232
-r 1 root root 3756826624 Aug 25 11:28 /proc/kcore
# uname
Hi!
Something went wrong with PCMCIA on this X32. I inserted CF card, but
it detected both hde *and* hdf, mount took forever. At that point I
decided that I want my CF card back, took it back, it started
producing different I/O errors , and then it oopsed.
Hi Eric,
If I understand correctly, packets sent to the all-ones
broadcast address only go out through a single interface.
I have some blur memories about this kind of issue, so my
answer my be wrong on some points...
It turns out you are exactly right on all points. :-)
My question is
Hi,
On 22/08/2005 9:10 p.m., John McCutchan wrote:
On Sat, 2005-08-20 at 23:52 -0700, Andrew Morton wrote:
Reuben Farrelly [EMAIL PROTECTED] wrote:
Hi,
On 19/08/2005 11:37 a.m., Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
-
You need the kernel side timeout. Consider this case
One page of memory holds the parking code
A second page is swapped to disk and holds the resume code
You park the disk
You wakeup
You got to page in the resume code
So you really do want the kernel helping to avoid a deadlock
@@ -1661,6
On Wed, 24 Aug 2005, Andy Isaacson wrote:
You might benefit by running your source code through gcc -E and seeing
what the writel() expands to. (I do something like rm drivers/mydev.o;
make V=1 and then copy-n-paste the gcc line, replacing the -c -o mydev.o
options with -E.)
Well, `make
On Thu, 2005-08-25 at 16:10 +0530, P.Manohar wrote:
In RH9 the starting function of keyboard.c is handle_scancode,
this is
the function to which the scancode is given by the keyboard interrupt
handler, its fine, but in FC2 , this handle_scancode is not there,
it's
functionality is
Christoph Hellwig a écrit :
On Thu, Aug 25, 2005 at 11:17:23AM +0200, Eric Dumazet wrote:
But that's not true. You need to write you own sysctl handler for it,
probably worth adding a generic atomic_t sysctl handler while you're
at it.
I checked linux-2.6.13-rc7 tree, and atomic_read() is
This removes support for old (and non-mainline) kernels from
ipw2200. Please apply,
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
--- clean-mm/drivers/net/wireless/ipw2200.c 2005-08-24 20:25:09.0
+0200
+++ linux-mm/drivers/net/wireless/ipw2200.c 2005-08-25 12:50:19.0
This removes one trap for a programmer, few unused macros, and one
unused struct. Please apply,
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
--- clean-mm/drivers/net/wireless/ipw2200.c 2005-08-24 20:25:09.0
+0200
+++ linux-mm/drivers/net/wireless/ipw2200.c 2005-08-25
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
OK, here is a new clean patch that address this problem (nothing assumed
about
atomics)
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
This introduces lost update problems. 2 CPUs may store to
On Thu, Aug 25 2005, Ingo Molnar wrote:
* Jens Axboe [EMAIL PROTECTED] wrote:
There can quite easily be lots of pending IO for the io_context (and,
in CFQ's case, below cfq_io_contexts), task exiting is completely
decoupled from any pending io.
yes, but that only affects the
On Thu, Aug 25 2005, Pavel Machek wrote:
Hi!
Something went wrong with PCMCIA on this X32. I inserted CF card, but
it detected both hde *and* hdf, mount took forever. At that point I
decided that I want my CF card back, took it back, it started
producing different I/O errors , and then it
On Thu, Aug 25, 2005 at 03:56:23PM +0900, Tomita, Haruo wrote:
Hi Jeff,
2.6.13- rc7-libata1.patch.bz2 was used.
A combined mode of ata_piix seems not to work.
Is the following patches correct?
diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig
linux-2.6.13-rc7/drivers/scsi/Kconfig
o There are minor changes in command line options in kexec-tools for kdump.
This patch updates the documentation to reflect those changes.
Signed-off-by: Vivek Goyal [EMAIL PROTECTED]
---
linux-2.6.13-rc7-root/Documentation/kdump/kdump.txt | 16
1 files changed, 8
On Iau, 2005-08-25 at 13:19 +0200, Jens Axboe wrote:
Aug 25 11:35:23 amd kernel: hdf: probing with STATUS(0x50) instead of
ALTSTATUS(0x0a)
Aug 25 11:35:24 amd kernel: hdf:
^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H(^H^H^H(^H^H^H^H,
ATA DISK drive
Aug 25 11:35:24
Hi,
On Thu, Aug 25, 2005 at 11:48:46AM +0200, Pavel Machek wrote:
Something went wrong with PCMCIA on this X32. I inserted CF card, but
it detected both hde *and* hdf, mount took forever. At that point I
decided that I want my CF card back, took it back, it started
producing different I/O
Hi,
I have also observed another problem with inotify with dovecot - so I spoke
with Johannes Berg who wrote the inotify code in dovecot. He suggested I
post
here to LKML since his opinion is that this to be a kernel bug.
Allow me to jump in at this point. The small tool below triggers
Hello all,
I am a newbee tryinging for serial port
multiplexing. Currently my driver supports for one
port
(/dev/ttyS0). However i want to use the same physical
port for 2 virtual ports.I am NOT sending two type of
data simultaneously. I want to first reigister my
driver for /dev/ttyS0. When
Nick Piggin a écrit :
On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
OK, here is a new clean patch that address this problem (nothing assumed about
atomics)
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it
On 8/25/05, Pekka J Enberg [EMAIL PROTECTED] wrote:
@@ -392,6 +585,23 @@ otherwise noted.
fasync: called by the fcntl(2) system call when asynchronous
(non-blocking) mode is enabled for a file
+ lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
+
Hello,
your patch works!
first a box booting from a gdth:
a01:~# lsscsi
[0:0:0:0]diskICP Host Drive #00/dev/sda
[0:2:6:0]process SUPERGEM318 0 -
[1:0:0:10] diskIFT A16F-R1211 334B /dev/sdb
[1:0:0:12] diskIFT
On Tue, 2005-08-23 at 16:23 +0100, Jamie Lokier wrote:
receive some request...
if (any_dnotify_or_inotify_events_pending) {
read_dnotify_or_inotify_events();
if (any_events_related_to(file)) {
store_in_userspace_stat_cache(file, stat(file));
}
On Thu, Aug 25, 2005 at 01:24:40AM -0700, Andrew Morton wrote:
IMO sys_readahead() doesn't make sense if the file is opened with
O_DIRECT, because the page cache is stuffed but never used. Therefore
this patch changes that by letting the call return with -EINVAL.
a) It doesn't hurt,
Andrew Morton schrieb:
a) It doesn't hurt, it's just a bit of a silly thing to do.
IMO it may hurt the performance.
b) posix_fadvise(POSIX_FADV_WILLNEED) should get the same treatment (and
it's the preferred way of doing readahead).
Yes, of course.
c) O_DIRECT fd's should, as much
Nick Piggin wrote:
fork() can be changed so as not to set up page tables for
MAP_SHARED mappings. I think that has other tradeoffs like
initially causing several unavoidable faults reading
libraries and program text.
What kind of application are you using?
The application is a database system
Ray Fucillo [EMAIL PROTECTED] writes:
The application is a database system called Caché. We allocate a
large shared memory segment for database cache, which in a large
production environment may realistically be 1+GB on 32-bit platforms
and much larger on 64-bit. At these sizes fork() is
Hello everyone,
using two different USB memory cardreader I have a problem which I am able to
reproduce on serveral machines (x86 and x86_64, Kernel 2.6.x) and with
different memory cards (Compact Flash, SD-Card, Sony Memory-Stick):
When I plug them in, they will be recognized by hotplug (I'm
On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
Hi,
I have also observed another problem with inotify with dovecot - so I spoke
with Johannes Berg who wrote the inotify code in dovecot. He suggested I
post
here to LKML since his opinion is that this to be a kernel bug.
The
Howdy, and excuse me for crossposting - feel free to zap CC to
unrelated, if any, mailing lists.
just gave PeerGuardian a spin on my eDonkey home box and
said box didn't last half a day before oopsing in netlink/nf/tcp
related routines (or so it seems to my untrained eye).
K7800, 256MB
On Thu, 2005-08-25 at 14:18 +0200, Johannes Berg wrote:
Hi,
I have also observed another problem with inotify with dovecot - so I spoke
with Johannes Berg who wrote the inotify code in dovecot. He suggested I
post
here to LKML since his opinion is that this to be a kernel bug.
Doug Warzecha wrote:
This patch adds the Dell Systems Management Base Driver with sysfs support.
This patch incorporates changes based on comments from the previous posting.
Summary of changes:
* Changed permissions on sysfs files so that only owner can read.
* Changed to use __uNN/__sNN types
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
Right, but it would be nice to have that option if initramfs
using tmpfs becomes part of the kernel.
But it's not needed so why add bloat?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Hmm, haven't yet figured out why, but something in this patchset
doesn't work for power5. Oops attached, as well as the assembly
for selinux_task_create (which I'm weeding through right now).
thanks,
-serge
Oops output from console:
Security Framework v1.0.0 initialized
SELinux: Initializing.
On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
I get that message a lot. I know I have said this before (and was wrong)
but I think the idr layer is busted.
This time I think I agree with you. ;-)
Let's just pass zero for the above parameter in idr_get_new_above(),
which is I
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
I don't know, because tar is probably more widely used and
consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
kernel. Everyone has cpio probably so
On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
On 2.6.13-rc7 the test program fails. It always fails when a wd == 1024.
If I skip inotify_rm_watch when wd == 1024, it will fail at wd == 2048.
It seems the idr layer has an aversion to multiples of 1024.
When I run your test program
On Thu, 25 Aug 2005, Geert Uytterhoeven wrote:
Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
for my uClinux experiments.
sun3 is seriously broken and I doubt that we'll see any takers for testing
2.6 on those anyway ;-)
Hey, I'm writing this on a sun3! :)
On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:
Let's just pass zero for the above parameter in idr_get_new_above(),
which is I believe the behavior of the other interface, and see if the
1024-multiple problem goes away. We definitely did not have that
before.
Will we then need to
On Thu, 2005-08-25 at 15:50 +0200, Johannes Berg wrote:
On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
On 2.6.13-rc7 the test program fails. It always fails when a wd == 1024.
If I skip inotify_rm_watch when wd == 1024, it will fail at wd == 2048.
It seems the idr layer has an
Ray Fucillo [EMAIL PROTECTED] writes:
The application is a database system called Caché. We allocate a
large shared memory segment for database cache, which in a large
production environment may realistically be 1+GB on 32-bit platforms
and much larger on 64-bit. At these sizes
On Thu, 2005-08-25 at 16:03 +0200, Johannes Berg wrote:
On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:
Let's just pass zero for the above parameter in idr_get_new_above(),
which is I believe the behavior of the other interface, and see if the
1024-multiple problem goes away. We
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at least compiling is a good
start point.
On Thu, 2005-08-25 at 09:47 -0400, Robert Love wrote:
On Thu, 2005-08-25 at 09:40 -0400, John McCutchan wrote:
I get that message a lot. I know I have said this before (and was wrong)
but I think the idr layer is busted.
This time I think I agree with you. ;-)
Let's just pass zero
On Thu, 2005-08-25 at 10:06 -0400, John McCutchan wrote:
it fails on 2.6.13-rc6 as soon as the device is full and doesn't hold
any more directories.
Obviously this wasn't true, I was hitting the 8192 watches limit and
misinterpreted the error message. I just tested up to 10 watches
with
Did you ever check this with selinux? I'm assuming that the problem is
that selinux does things like:
rc = secondary_ops-task_create();
when secondary_ops-task_create can now be null...
(Will whip up the obvious patch asap - later this morning)
-serge
Quoting [EMAIL PROTECTED] ([EMAIL
On Thu, 25 Aug 2005, Al Viro wrote:
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at
On Thu, 25 Aug 2005, Al Viro wrote:
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at
Would it be worth trying to do something like this?
Maybe. Shouldn't be very hard though - you just need to check if the VMA is
backed by an object and if yes don't call copy_page_range for it.
I think it just needs (untested)
Index: linux-2.6.13-rc5-misc/kernel/fork.c
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
There's something strange going on with either ACPI or
Please download libsmbios 0.10.0-beta1 and send the dumpCmos output
from your machine. Please send it to the libsmbios devel mailing list.
From that output, I can tell you if this token is available on that
machine. If that token is available, then yes, you can set that feature.
libsmbios can be
Ray Fucillo wrote:
Nick Piggin wrote:
fork() can be changed so as not to set up page tables for
MAP_SHARED mappings. I think that has other tradeoffs like
initially causing several unavoidable faults reading
libraries and program text.
What kind of application are you using?
The
Andi Kleen wrote:
Would it be worth trying to do something like this?
Maybe. Shouldn't be very hard though - you just need to check if the VMA is
backed by an object and if yes don't call copy_page_range for it.
I think it just needs (untested)
I think you need to check for MAP_SHARED
On Thu, 2005-08-25 at 16:13 +0200, Johannes Berg wrote:
On Thu, 2005-08-25 at 10:06 -0400, John McCutchan wrote:
it fails on 2.6.13-rc6 as soon as the device is full and doesn't hold
any more directories.
Obviously this wasn't true, I was hitting the 8192 watches limit and
Ok, with the attached patch SELinux seems to work correctly. You'll
probably want to make it a little prettier :) Note I have NOT ran the
ltp tests for correctness. I'll do some performance runs, though
unfortunately can't do so on ppc right now.
thanks,
-serge
Signed-off-by: Serge Hallyn
On Thu, 2005-08-25 at 10:13 -0400, John McCutchan wrote:
I really don't want 2.6.13 to go out with this bug or the compromise. If
we use 0, we will have a lot of wd re-use. Which will cause strange
problems in inotify using applications that cleanup upon receipt of an
IN_IGNORE event.
What
OK, here it is. Against 2.6.13-rc7-rt1.
Please, test it well. Make sure to turn off any debugging, especially
CONFIG_RT_DEADLOCK_DETECT. Since that would use a global trace_lock
that defeats the purpose of removing the pi_lock.
The patch to remove the single pi_lock:
-- Steve
Signed-off-by:
On Thu, 2005-08-25 at 16:22 +0200, Andi Kleen wrote:
But I'm not sure it's a good idea in all cases. Would need a lot of
benchmarking at least.
-Andi
Exactly - one problem is that this forces all of the hugetlb users to go
the lazy faulting way. This is more or less similar to the
On Wed, Aug 24, 2005 at 08:09:09PM -0700, Chris Wedgwood wrote:
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote:
[...]
+Dell OpenManage requires this driver on the following Dell PowerEdge
systems:
+300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC,
Eric Dumazet wrote:
Nick Piggin a écrit :
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it would force to convert 3 int
(nr_files, nr_free_files, max_files) to 3 atomic_t. I feel bad
introducing a lot of sysctl rework
On Thu, Aug 25, 2005 at 11:14:03AM +0200, moreau francis wrote:
--- Andy Isaacson [EMAIL PROTECTED] a écrit :
The first register write will be completed before the second register
write because you use writel, which is defined to have the semantics you
want. (It uses a platform-specific
On Fri, Aug 26, 2005 at 12:51:30AM +1000, Nick Piggin wrote:
Eric Dumazet wrote:
Nick Piggin a ?crit :
Would you just be able to add the atomic sysctl handler that
Christoph suggested?
Quite a lot of work indeed, and it would force to convert 3 int
(nr_files, nr_free_files,
On Thu, 25 Aug 2005, Arjan van de Ven wrote:
On Thu, 2005-08-25 at 16:10 +0530, P.Manohar wrote:
In RH9 the starting function of keyboard.c is handle_scancode,
this is
the function to which the scancode is given by the keyboard interrupt
handler, its fine, but in FC2 , this
On Thu, 2005-08-25 at 10:47 -0400, Steven Rostedt wrote:
OK, here it is. Against 2.6.13-rc7-rt1.
@@ -1134,17 +1206,35 @@
return 0;
trace_lock_irqsave(trace_lock, flags, ti);
+ /*
+ * We are no longer blocked on the lock, so we are considered a
+ *
Nick Piggin a écrit :
OK, well I would prefer you do the proper atomic operations throughout
where it really matters in file_table.c, and do your lazy synchronize
with just the sysctl exported value.
But... I got complains about atomic_read(counter) being 'an atomic op'
(untrue), so my
On Thu, 2005-08-25 at 16:41 +0200, Johannes Berg wrote:
On Thu, 2005-08-25 at 10:13 -0400, John McCutchan wrote:
I really don't want 2.6.13 to go out with this bug or the compromise. If
we use 0, we will have a lot of wd re-use. Which will cause strange
problems in inotify using
On Thu, 2005-08-25 at 09:38 -0500, [EMAIL PROTECTED] wrote:
Ok, with the attached patch SELinux seems to work correctly. You'll
probably want to make it a little prettier :) Note I have NOT ran the
ltp tests for correctness. I'll do some performance runs, though
unfortunately can't do so
301 - 400 of 570 matches
Mail list logo
