We carefully set loglevel to 7, and print the sysrq messsage
as to what event we're doing, but we can't actually see
the output as it sets it back before calling the handler,
rather than after.
Move the assignment down one line.
Signed-off-by: Martin J. Bligh [EMAIL PROTECTED]
diff -aurpN -X
David Woodhouse writes:
Of course, the _numbers_ might change -- a given port might no longer be
ttyS0 but ttyS1. But we're happy to overlook that one even though the
effect on the user is identical, right?
Why would the numbers be prone to change, any more than they are
already?
-
To
Willy Tarreau wrote:
On Wed, Mar 28, 2007 at 01:02:10PM -0700, David Miller wrote:
Please nobody reply to his posting, I'm shit-canning this thread from
the start as it's nothing but flame fodder.
He forgot the most important thing: there are *many* benevolent dictators,
all with their own
On Thu, 05 Apr 2007 19:42:19 +0200
[EMAIL PROTECTED] wrote:
Introduce a mechanism to wait on free memory.
Currently congestion_wait() is abused to do this.
Such a very small explanation for such a terrifying change.
...
--- linux-2.6-mm.orig/mm/vmscan.c 2007-04-05 16:29:46.0
On Fri, 2007-04-06 at 08:53 +1000, Paul Mackerras wrote:
Why would the numbers be prone to change, any more than they are
already?
Because now 8250 ports can actually coexist with Zilog ports. Before my
fix, it was strictly one or the other.
--
dwmw2
-
To unsubscribe from this list: send the
On Thu, 2007-04-05 at 14:55 -0500, Kevin Corry wrote:
Hello,
Carl Love and I have been working on getting the latest perfmon2 patches
(http://perfmon2.sourceforge.net/) working on Cell, and on powerpc in
general. We've come up with some powerpc-specific questions and we're hoping
to get
From: Luck, Tony [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 15:50:02 -0700
Maybe a granule is not the right unit of allocation ... perhaps 4M
would work better (4M/56 ~= 75000 pages ~= 1.1G)? But if this is
too small, then a hard-coded 16M would be better than a granule,
because 64M is (IMHO)
On Thu, 05 Apr 2007 19:42:20 +0200
[EMAIL PROTECTED] wrote:
Only do the congestion wait when we actually encountered congestion.
The name congestion_wait() was accurate back in 2002, but it isn't accurate
any more, and you got misled. It does not only wait for a queue to become
uncongested.
On Thu, 05 Apr 2007 19:42:21 +0200
[EMAIL PROTECTED] wrote:
Now that we have per BDI dirty throttling is makes sense to also have oer BDI
congestion feedback; why wait on another device if the current one is not
congested.
Similar comments apply. congestion_wait() should be called
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21. Please apply; this patch
is needed as a bugfix in 2.6.21. An updated version for 2.6.22 will
come later
Zachary Amsden wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21. Please apply; this patch
is needed as a bugfix in 2.6.21. An updated version for
On Thu, 5 Apr 2007 15:36:51 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
If we add a new flag so that we can distinguish between the
first page and the tail pages then we can avoid to use page-private
in the first page. page-private == page for the first page, so there
is no real
On Friday 06 April 2007 01:29:56 Zachary Amsden wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21.
I think it is. That is why i didn't apply it.
I built a version of 2.6.21-rc5-mm4 with an initramfs and it built OK
the first time.
Then I made changes (applied a Reiser4 patch) and rebuilt, and got the
following error:
zephyr linux # make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL
On Thu, 05 Apr 2007 16:34:43 -0700
Zachary Amsden [EMAIL PROTECTED] wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21. Please apply; this patch
On Tuesday, 3 April 2007 01:06, Adrian Bunk wrote:
On Sun, Apr 01, 2007 at 06:48:03PM +0200, Rafael J. Wysocki wrote:
On Sunday, 1 April 2007 17:21, Tilman Schmidt wrote:
I'm sorry to say this has now happened with kernel 2.6.21-rc5, too.
I started a kernel compilation in the evening and
Andi Kleen wrote:
On Friday 06 April 2007 01:29:56 Zachary Amsden wrote:
I noticed this never got applied. There was some feedback which I did
not include in this patch because I think it is inappropriate to touch
code outside vmi.c at this point for 2.6.21.
I think it is. That is
On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
From: Andrew Burgess [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 15:13:27 -0700
David, do you see any other problems with scsi_send_eh_cmnd?
I've switched back to 2.6.18 which seems to not oops
and am happy to try patches.
Does
Hi Ignatich,
After seeing the following benchmarks at
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
The Reiser4 benchmarks are so good, I have decided to try the Reiser4
filesystem.
.-.
|
Zachary Amsden wrote:
Well at this point, the proper fix is dependent on Jeremy's
kmap_atomic_pte changes, which are definitely too late to pull into
2.6.21. Can we just apply this patch please?
Hm, I think they're independent aren't they? Your fix is about making
lazy_mmu disable
On Thu, 2007-04-05 at 11:44 +0100, Alan Hourihane wrote:
Attached is a patch against 2.6.21-rc5 which adds the Intel Vermilion
Range support.
Intel funded Tungsten Graphics to do this work.
If there's any problems or updates needed to be done to get accepted,
please let me know.
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Well at this point, the proper fix is dependent on Jeremy's
kmap_atomic_pte changes, which are definitely too late to pull into
2.6.21. Can we just apply this patch please?
Hm, I think they're independent aren't they? Your fix is
From: James Bottomley [EMAIL PROTECTED]
Date: Thu, 05 Apr 2007 19:02:19 -0500
On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
From: Andrew Burgess [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 15:13:27 -0700
David, do you see any other problems with scsi_send_eh_cmnd?
I've
Zachary Amsden wrote:
No, they are totally dependent. The reason interrupts are disabled is
to stop kmap_atomic in interrupt handlers. With the kmap_atomic_pte
changes, the whole interrupt disable jibberish goes away.
But kmap_atomic_pte is a special case of kmap_atomic for ptes.
Interrupt
Rusty Russell wrote:
There is now more than one place where we use the fact that bit 9 of
eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
512 so it can be used in asm, too.
How about defining all the other EFLAGS in one place?
-hpa
-
To unsubscribe from this
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
No, they are totally dependent. The reason interrupts are disabled is
to stop kmap_atomic in interrupt handlers. With the kmap_atomic_pte
changes, the whole interrupt disable jibberish goes away.
But kmap_atomic_pte is a special case
H. Peter Anvin wrote:
Rusty Russell wrote:
There is now more than one place where we use the fact that bit 9 of
eflags is the interrupt-enabled flag, so define EFLAGS_IF. We make it
512 so it can be used in asm, too.
How about defining all the other EFLAGS in one place?
That
[EMAIL PROTECTED] wrote:
Anyway, I have patched the 2.6.20 kernel and have a partition formatted
with Reiser4.
However, I am having trouble getting LILO or GRUB working (with
Reiser4).
Could you guys who know all about this, help me, or point me to some
help.
Make your /boot a separate
Jeremy Fitzhardinge wrote:
That patch got dropped, and replaced by one which pulled all the flags
definitions out of asm/processor.h
Saw that a little too late :)
In general, it would be nice if the various CPU constants were all
defined in one place, so I'd rather suggest protecting the
On Tue, 03 Apr 2007 19:46:04 +0900
Tomoki Sekiyama [EMAIL PROTECTED] wrote:
This patchset is to avoid the problem that write(2) can be blocked for a
long time if a system has several disks with different speed and is
under heavy I/O pressure.
-Description of the problem:
While
Zachary Amsden wrote:
So the clean fix for this is still even further out. I don't think I
want to hook kmap/unmap as paravirt-ops.
Yes, it seems like overkill.
How about something like adding PARAVIRT_LAZY_FLUSH as an argument to
set_lazy_mode? It would be valid to use at any time, and it
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
are accurate?
[EMAIL PROTECTED] wrote:
Yeap, I guess that will probably work.
And here I was trying to compile old versions of GRUB from namesys.com.
By the way, do you think the benchmarks from:
http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
So the clean fix for this is still even further out. I don't think I
want to hook kmap/unmap as paravirt-ops.
Yes, it seems like overkill.
How about something like adding PARAVIRT_LAZY_FLUSH as an argument to
set_lazy_mode? It would
On Thu, Apr 05, 2007 at 05:29:52PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
That patch got dropped, and replaced by one which pulled all the flags
definitions out of asm/processor.h
Saw that a little too late :)
In general, it would be nice if the various CPU constants
Linus Torvalds wrote:
On Thu, 5 Apr 2007, Robin Holt wrote:
For testing, Jack Steiner create the following patch. All it does
is moves tasks which are transitioning to the zombie state from where
they are in the children list to the head of the list. In this way,
they will be the first found
On Thu, 2007-04-05 at 17:15 -0700, David Miller wrote:
This won't work I believe.
There are cases that use smaller sense buffers than the minimum
specified by the SCSI layer.
One example is that do_sr_ioctl() stuff when the cgc passed
in has a sense buffer. That will only be as large as
Zachary Amsden wrote:
Yes, thought about several solutions, and this seems the best. But it
requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
J
diff -r 5be4a5ff8e6b arch/i386/mm/highmem.c
--- a/arch/i386/mm/highmem.cThu Apr 05 17:04:04
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yes, thought about several solutions, and this seems the best. But it
requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
Throw it in the queue; I'll slide in after it.
Zach
-
To
On Tue, 03 Apr 2007 18:35:06 -0700
Davide Libenzi davidel@xmailserver.org wrote:
Remove some unneeded include files from epoll code.
Our definitions of unneeded might differ.
Signed-off-by: Davide Libenzi davidel@xmailserver.org
- Davide
Index:
Dmitry Torokhov wrote:
+static void hid_bus_release(struct device *dev)
+{
+}
+
+struct device hid_bus = {
+.bus_id = hidbus0,
+.release = hid_bus_release
+};
+
+static void hid_dev_release(struct device *dev)
+{
+}
+
That will for sure raise Greg KH's blood
Chris Snook wrote:
Linus Torvalds wrote:
On Thu, 5 Apr 2007, Robin Holt wrote:
For testing, Jack Steiner create the following patch. All it does
is moves tasks which are transitioning to the zombie state from where
they are in the children list to the head of the list. In this way,
they
On Thursday 05 April 2007 21:54, Ingo Molnar wrote:
- fiftyp.c: noticeable, but alot better than previously!
fiftyp.c seems to have been stumbled across by accident as having an effect
when Xenofon was trying to recreate Mike's 50% x 3 test case. I suggest a ten
percent version like the
Andi Kleen wrote:
No processor.h is such a hodgepodge of unrelated stuff that any
splitting up is a good thing.
Fair enough. However, I'd still like to see the X86_CR* constants
moved, too (and constants added for at least CR0 as well.)
-hpa
-
To unsubscribe from this list: send
On Thu, 5 Apr 2007, Andrew Morton wrote:
epoll uses signal stuff and might need signal.h. It implements syscalls
and it certainly needs to have those syscall's prototypes in scope. It
surely uses stuff from mm.h (doesn't everything??)
Ack about signal.h, I forgot about the pwait code :(
Why
On Tue, 3 Apr 2007 21:02:03 -0700
Yinghai Lu [EMAIL PROTECTED] wrote:
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set
and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the
kernel can not be
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Eric Dumazet wrote:
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
--- linux-2.6.21-rc5-mm4/kernel/futex.c
+++ linux-2.6.21-rc5-mm4-ed/kernel/futex.c
@@ -16,6 +16,9 @@
* Copyright (C) 2006 Red Hat,
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Yes, thought about several solutions, and this seems the best. But it
requires a new paravirt-op.
Not with the power of multiplexing. Something like this, perhaps?
Ok, I tried that and I got a nice clean fix. For 2.6.22.
On Thu, 5 Apr 2007 18:12:58 -0700 (PDT)
Davide Libenzi davidel@xmailserver.org wrote:
On Thu, 5 Apr 2007, Andrew Morton wrote:
epoll uses signal stuff and might need signal.h. It implements syscalls
and it certainly needs to have those syscall's prototypes in scope. It
surely uses
Rik van Riel wrote:
Nick Piggin wrote:
Oh, also: something like this patch would help out MADV_DONTNEED, as it
means it can run concurrently with page faults. I think the locking will
work (but needs forward porting).
Ironically, your patch decreases throughput on my quad core
test system,
On Thu, 5 Apr 2007, Chris Snook wrote:
Linus Torvalds wrote:
Another thing we could do is to just make sure that kernel threads simply
don't end up as children of init. That whole thing is silly, they're really
not children of the user-space init anyway. Comments?
Does anyone
Zachary Amsden wrote:
Throw it in the queue; I'll slide in after it.
I've pushed it up. I added a few missing cases to the patch
(kmap_atomic_pte, kunmap_atomic).
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Throw it in the queue; I'll slide in after it.
I've pushed it up. I added a few missing cases to the patch
(kmap_atomic_pte, kunmap_atomic).
Do you mean kmap_atomic_pfn? kunmap_atomic can stay lazy (at least for
VMI), actually,
Hi Peter,
You say that the results may be accurate, but not relevant.
.-.
| FILESYSTEM | TIME |DISK |
| TYPE |(secs)|USAGE|
.-.
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
|REISER4 | 3462 | 692 |
|EXT2| 4092 | 816 |
Zachary Amsden wrote:
Do you mean kmap_atomic_pfn?
Yes.
kunmap_atomic can stay lazy (at least for VMI), actually, but it
doesn't help since it happens outside the spin lock.
May as well be consistent. Or do you mean you can't flush outside the
spinlock, even if there's nothing pending?
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Do you mean kmap_atomic_pfn?
Yes.
kunmap_atomic can stay lazy (at least for VMI), actually, but it
doesn't help since it happens outside the spin lock.
May as well be consistent. Or do you mean you can't flush outside the
Linus Torvalds [EMAIL PROTECTED] writes:
On Thu, 5 Apr 2007, Chris Snook wrote:
Linus Torvalds wrote:
Another thing we could do is to just make sure that kernel threads simply
don't end up as children of init. That whole thing is silly, they're really
not children of the user-space init
Can anyone tell me what this means:
Apr 5 22:11:56 vegeta kernel: [ 1265.267700] scsi0: device overrun (status a)
on 0:1:0
Kernel is 2.6.20.
I setup a raid1 between 2 hard disks (on partition #2), as soon as it
started to sync the array, my log was flooded with the above entry.
The scsi
On Thu, 2007-04-05 at 11:43 -0300, Glauber de Oliveira Costa wrote:
and here's the new patch, merging rusty's suggestions and some more on my own.
May I upload this, or does Rusty (or any other) has some more suggestions?
This looks excellent!
There are a couple of extra spaces floating
On Thu, 2007-04-05 at 15:36 -0700, David Miller wrote:
From: Andrew Burgess [EMAIL PROTECTED]
Date: Thu, 5 Apr 2007 15:13:27 -0700
David, do you see any other problems with scsi_send_eh_cmnd?
I've switched back to 2.6.18 which seems to not oops
and am happy to try patches.
Does
On Thu, 2007-04-05 at 14:29 -0700, David Brownell wrote:
On Tuesday 03 April 2007 11:28 pm, Wu, Bryan wrote:
USB gadget rndis: skb_push function may return a pointer which is not
aligned as required by struct rndis_packet_msg_type.
Can you instead try to update the declaration of that
On Thu, 2007-04-05 at 18:06 -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
No processor.h is such a hodgepodge of unrelated stuff that any
splitting up is a good thing.
Fair enough. However, I'd still like to see the X86_CR* constants
moved, too (and constants added for at least
Ulrich Drepper wrote:
In case somebody wants to play around with Rik patch or another
madvise-based patch, I have x86-64 glibc binaries which can use it:
http://people.redhat.com/drepper/rpms
These are based on the latest Fedora rawhide version. They should work
on older systems, too, but
On Thu April 5 2007 3:32 pm, Kevin Corry wrote:
On Thu April 5 2007 3:08 pm, Arnd Bergmann wrote:
On Thursday 05 April 2007, Kevin Corry wrote:
First, the stock 2.6.20 kernel has a prototype in include/linux/smp.h
for a function called smp_call_function_single(). However, this routine
On Thu April 5 2007 6:04 pm, Benjamin Herrenschmidt wrote:
On Thu, 2007-04-05 at 14:55 -0500, Kevin Corry wrote:
First, the stock 2.6.20 kernel has a prototype in include/linux/smp.h for
a function called smp_call_function_single(). However, this routine is
only implemented on i386, x86_64,
Ok,
I don't think there really is anything very interesting here, but we're
hopefully whittling down the list of regressions, and fixing various
random other small issues while at it.
Some smallish MIPS updates, networking (and network driver) fixes, removal
of a long obsolete framebuffer
On Thu, Apr 05, 2007 at 06:00:16PM +0200, Cornelia Huck wrote:
On Thu, 5 Apr 2007 23:27:32 +0800,
WANG Cong [EMAIL PROTECTED] wrote:
Thank you very much! I know. So I should replace all kfree with kobject_put,
like this one:
-sysfs_create_link(p-kobj, block_subsys.kset.kobj, subsystem);
Nick Piggin wrote:
Cool. According to my thinking, madvise(MADV_DONTNEED) even in today's
kernels using down_write(mmap_sem) for MADV_DONTNEED is better than
mmap/mprotect, which have more fundamental locking requirements, more
overhead and no benefits (except debugging, I suppose).
It's a
Ulrich Drepper wrote:
Nick Piggin wrote:
Cool. According to my thinking, madvise(MADV_DONTNEED) even in today's
kernels using down_write(mmap_sem) for MADV_DONTNEED is better than
mmap/mprotect, which have more fundamental locking requirements, more
overhead and no benefits (except debugging,
On Thu, Apr 05, 2007 at 12:28:03PM -0500, Michael wrote:
Hi, Dick,
Your steps work beautifully. Thanks.
If you could explain a little about what happens in each step, that
would be even better.
# cd /usr/src/linux-2.6.20.3
If your current kernel is 2.6.20.3, edit the Makefile to
add some
On Thu, 2007-04-05 at 16:40 -0400, Steven Rostedt wrote:
Glauber noticed long delays between hitting a key, and seeing data come
up on the virtual console. Looking into this, I found that the
wake_parent routine that reads from all devices was actually starving
out the parent after sending
[PATCH] usb gadget rndis:
skb_push function may return a pointer which is not aligned as required
by struct rndis_packet_msg_type. Using attribute trick to fix this bug.
Signed-off-by: Roy Huang [EMAIL PROTECTED]
Signed-off-by: Jie Zhang [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL
[EMAIL PROTECTED] wrote:
Hi Peter,
You say that the results may be accurate, but not relevant.
NO, I said that whether they're accurate is another matter.
If they are accurate, THEN they are obviously very relevant.
Crap-o-la. Whether or not they're relevant depends on how well they
Hi Peter,
You say that the results may be accurate, but Whether or not they're
*relevant* is a totally different ball of wax. and
Whether or not they're relevant depends on how well they happen to
reflect your particular usage pattern.
Well, surprise, surprise,.. everyone knows that.
Have a
On Thu, 05 Apr 2007 18:34:48 PDT, [EMAIL PROTECTED] said:
If they are accurate, THEN they are obviously very relevant.
Erm. No. They're not obviously very relevant.
I could hypothetically create a benchmark, that's accurate and repeatable,
that shows that reiser4 is able to wash a herd of
On 4/5/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 06 Apr 2007 02:33:03 +1000
Reuben Farrelly [EMAIL PROTECTED] wrote:
Hi,
On 3/04/2007 3:47 PM, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
- The oops in
Remove an empty and thus unused definition of 'setup_nr_node_ids' (in
case of MAX_NUMNODES 1) in order to resolve a compiler warning.
Signed-off-by: Patrick Ringl [EMAIL PROTECTED]
---
--- linux-2.6.20-o/mm/page_alloc.c 2007-03-22 23:11:25.0 +0100
+++ linux-2.6.20/mm/page_alloc.c
Nick Piggin a écrit :
Hi Eric,
Thanks for doing this... It's looking good, I just have some minor
comments:
Hi Nick, thanks for reviewing.
Eric Dumazet wrote:
*/
-int get_futex_key(void __user *uaddr, union futex_key *key)
+int get_futex_key(void __user *uaddr, union futex_key *key,
+
Some versions of libc can't deal with a VDSO which doesn't have its
ELF headers matching its mapped address. COMPAT_VDSO maps the VDSO at
a specific system-wide fixed address. Previously this was all done at
build time, on the grounds that the fixed VDSO address is always at
the top of the
Dmitry Torokhov wrote:
+static int hid_bus_match(struct device *dev, struct device_driver
*drv) +{
+struct hid_driver *hid_drv;
+struct hid_device *hid_dev;
+
+hid_drv = to_hid_driver(drv);
+hid_dev = to_hid_device(dev);
+
+if (is_hid_driver_sticky(hid_drv))
+
On Wed, 4 Apr 2007 22:05:34 -0700 Randy Dunlap [EMAIL PROTECTED] wrote:
Use documented tag for IA-32 (not i386) to indicate which
kernel parameters apply to IA-32.
mv arch/i386 arch/ia32 ;)
Seriously, is there any point in this? Kernel uses the i386 terminology
and surely there's no
On Wed, Apr 04, 2007 at 05:27:31PM -0700, Linus Torvalds wrote:
Good point. In fact, it doesn't need to be a malloc() - I remember people
doing this with Fortran programs and just having an absolutely incredibly
big BSS (with traditional Fortran, dymic memory allocations are just not
done).
On 3/26/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Sun, Mar 25, 2007 at 12:50:25PM -0700, Paul Jackson wrote:
Is there perhaps another race here?
Yes, we have!
Modified patch below. Compile/boot tested on a x86_64 box.
Currently cpuset_exit() changes the exiting task's -cpuset
Rusty Russell wrote:
On Wed, 2007-04-04 at 23:14 -0400, Steven Rostedt wrote:
On Wed, 2007-04-04 at 23:06 -0400, Kyle Moffett wrote:
(Erk, I wonder what I was thinking when I wrote that?) Can I ask
for %#x (or 0x%x)? I'm easily confused.
How about %p for pointers?
But that would require
David Woodhouse writes:
OK, how about a config option to preserve the old behaviour...
Well, that's a start but it doesn't provide a migration path.
Is it possible to have the pmac_zilog ports registered both with the
new number and with the old number (assuming it's not already taken)?
That
From: Randy Dunlap [EMAIL PROTECTED]
Use documented tag for IA-32 (not i386) to indicate which
kernel parameters apply to IA-32.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt |8
1 file changed, 4 insertions(+), 4 deletions(-)
---
On Wed, Apr 04, 2007 at 01:11:11PM -0700, David S. Miller wrote:
If we're going to consider this seriously, there is a case I know of.
Look at flush_dcache_page()'s test for ZERO_PAGE() on sparc64, there
is an instructive comment:
/* Do not bother with the expensive D-cache flush if it
David Woodhouse writes:
And you always will be. The amount of pain involved in implementing
this, just so that people can call their serial port 'ttyS0', is _far_
more than it's worth. It could be done, but it's a completely pointless
waste of time and effort.
Avoiding breaking userspace is
On Wed, Apr 04, 2007 at 02:20:23PM +0100, Christian Kujau wrote:
On Wed, 4 Apr 2007, Jarek Poplawski wrote:
So, it's a lot sooner than before. (BTW, isn't there anything
in debug log?)
No, nothing. I've set up remote-syslgging to the other node (node1
logging to node2 and vice versa) -
Eric Dumazet wrote:
Database workload, where the user multi threaded app is constantly
accessing GBytes of data, so L2 cache hit is very small. If you want to
oprofile it, with say a CPU_CLK_UNHALTED:5000 event, then find_vma() is
in the top 5.
We did have a workload with lots of Java and
Looking at both the i386 and x86-64 implementations I fail to understand why
there is an explicit requirement on calling global_flush_tlb() after
change_page_attr(), yet actual TLB flushing will not normally happen (on i386
it will happen if the CPU doesn't support clflush, but if it does, or on
Randy Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
Use documented tag for IA-32 (not i386) to indicate which
kernel parameters apply to IA-32.
We call this architecture i386 everywhere else. I think it makes more
sense to change the documented tag to i386, especially with Intel
Now that relocation of the VDSO for COMPAT_VDSO users is done at
runtime rather than compile time, it is possible to enable/disable
compat mode at runtime.
This patch allows you to enable COMPAT_VDSO mode with vdso=2 on the
kernel command line, or via sysctl.
The COMPAT_VDSO config option still
On Wed, Apr 04, 2007 at 07:57:40PM -0700, Paul Menage wrote:
Firstly, this is not a unique problem introduced by using -nsproxy.
Secondly we have discussed this to some extent before
(http://lkml.org/lkml/2007/2/13/122). Essentially if we see zero tasks
sharing a resource object pointed to by
On Wed, 2007-04-04 at 17:34 -0700, Daniel Walker wrote:
The fact that a list is used to string together clocksource structures
is an internal detail of the clock subsystem. It's annoying that there
has to be a list head in the clocksource structure, but at least as a
clocksource
Nick Piggin a écrit :
Eric Dumazet wrote:
This was not a working patch, just to throw the idea, since the
answers I got showed I was not understood.
In this case, find_extend_vma() should of course have one struct
vm_area_cache * argument, like find_vma()
One single cache on one mm is not
Hi Andi,
Here's a couple of patches to fix up COMPAT_VDSO:
The first is a straightforward implementation of Jan's original idea
of relocating the VDSO to match its mapped location. Unlike Jan and
Zach's version, I changed it to relocate based on the phdrs rather than
the sections; the result is
Hi,
When reading corrupted reiserfs directory data, d_reclen
could be a negative number, then memcpy will overflow
kernel stack. This can lead to kernel panic.
The following patch adds a sanity check. (against 2.6.20.4)
Signed-off-by: Lepton Wu [EMAIL PROTECTED]
diff -pru
On Wed, Apr 04, 2007 at 11:13:30AM -0700, Keshavamurthy, Anil S wrote:
On Wed, Apr 04, 2007 at 05:43:49PM +0530, Ananth N Mavinakayanahalli wrote:
This patch provides a debugfs knob to turn kprobes on/off
Nice feature. Thanks. Review inline.
Thanks for the review Anil...
+static void
The patch looks nice and clean. However, it does not relocate the symbol
table(s) values. I thought that was done in an earlier version of this I
saw, but I might be misremembering. Though not fatal, this is a regression
from the previous CONFIG_COMPAT_VDSO behavior. It will show up in things
501 - 600 of 813 matches
Mail list logo
