---
Signed-off-by: <[EMAIL PROTECTED]>
---
Documentation/memctlr.txt | 70 ++
1 file changed, 70 insertions(+)
diff -puN /dev/null Documentation/memctlr.txt
--- /dev/null 2007-02-02 22:51:23.0 +0530
+++ linux-2.6.20-balbir/Documentation/m
Changelog
1. Move void *container to struct container (in scan_control and vmscan.c
and rmap.c)
2. The last set of patches churned the LRU list, in this release, pages
that can do not belong to the container are moved to a skipped_pages
list. At the end of the isolation they are added b
This is a repost of the patches at
http://lkml.org/lkml/2007/2/24/65
The previous post had a misleading subject which ended with a "(".
This patch applies on top of Paul Menage's container patches (V7) posted at
http://lkml.org/lkml/2007/2/12/88
It implements a controlle
Changelog
1. Be consistent, use the C style of returning 0 on success and negative
values on failure
2. Change and document the locking used by the controller
(I hope I got it right this time :-))
3. Remove memctlr_double_(un)lock routines
4. Comment the usage of MEMCONTROL_DONT_CHECK_LIMI
Randy Dunlap <[EMAIL PROTECTED]> writes:
> On Sat, 24 Feb 2007 00:43:18 +0300 Dmitriy Monakhov wrote:
>
>> Since commit:553c4aa630af7bc885e056d0436e4eb7f238579b
>> ata_pci_device_do_resume() can return error code, all callers was updated
>> except this one.
>>
>> Signed-off-by: Monakhov Dmitriy <
>From: Arjan van de Ven [mailto:[EMAIL PROTECTED]
>
>> I gave it a quick try (must admit, not too tested) and it seems that
>> the setting of TIF_SIGPENDING without really having a signal queued
>> is not having easily visible ugly consequences.
>
>what happens if you get a signal around the time t
Hello, it's me and my 70 GB of photos again.
I have tested both CIFS and NFSv4 clients in kernel 2.6.20-rc1 . CIFS
passed with flying colors and NFSv4 stalled after 7 GB.
Configuration:
Server: PIII/1GHz, 512 MB RAM, Debian testing,
distro kernel 2.6.18-3-vserver-686, Intel E1000 NIC,
On Mon, Feb 26, 2007 at 12:45:00AM -0600, Florin wrote:
> After the writing stalls, I have echoed 't' into /proc/sysrq-trigger
> and got a trace, which is at http://iucha.net/20-rc1/after.1. There was
> no oops before the trace request; the 'before' dmesg is at
> http://iucha.net/20-rc1/before.1 .
On Sun, Feb 25, 2007 at 11:01:06PM -0500, David Woodhouse wrote:
> Yeah, I did that before giving up on it for the day and going in search
> of dinner. It changes the failure mode to a BUG() in
> cache_free_debugcheck(), at line 2876 of mm/slab.c
> It smells like the pages weren't actually reserved
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Remove PF_NOFREEZE from the bluetooth threads, adding try_to_freeze() calls as
required.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
---
net/bluetoot
From: Paul E. McKenney <[EMAIL PROTECTED]>
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze() call as
required.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
kernel/rcut
From: Oleg Nesterov <[EMAIL PROTECTED]>
refrigerator() can miss a wakeup, "wait event" loop needs a proper memory
ordering.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
kernel/power/process.c
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Add try_to_freeze() calls to the remaining kernel threads that do not call
try_to_freeze() already, although they set PF_NOFREEZE.
In the future we are going to replace PF_NOFREEZE with a set of flags that will
be set to indicate in which situations the
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The reading of PF_BORROWED_MM in is_user_space() without task_lock() is racy.
Fix it.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
kernel/power/process.c |8 +++-
1 file changed, 7 insertio
Hi,
The following series of patches contains modifications of the task freezer that
harden it and prepare it to be used in the CPU hotplug.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
If the freezing of tasks fails and a task is preempted in refrigerator() before
calling frozen_process(), then thaw_tasks() may run before this task is frozen.
In that case the task will freeze and no one will thaw it.
To fix this race we can call freez
Robert P. J. Day wrote:
Remove the redundant intermediate checks for __KERNEL__ since, as
soon as one ends, the next one starts.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
However, what's much worse is that this already has put series of
constants which are part of the ABI under _
On 2/26/07, Martin Langhoff <[EMAIL PROTECTED]> wrote:
On 2/26/07, Marco Costalba <[EMAIL PROTECTED]> wrote:
> P.S: There is also a Qt4 version (works under Windows) downloadable
> from git://repo.or.cz/qgit4.git it is a little bit experimental
> tough.
Is the QT4 Windows port working against t
Hi Alan,
On 2/26/07, Alan <[EMAIL PROTECTED]> wrote:
Whats the status on this, I was suprised to see something so important
just go dead ?
It's not dead. You can find the latest patches here:
http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/
and user-space tests here:
http://www.cs.
Pekka Enberg wrote:
Hi Alan,
On 2/26/07, Alan <[EMAIL PROTECTED]> wrote:
Whats the status on this, I was suprised to see something so important
just go dead ?
It's not dead. You can find the latest patches here:
http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/
and user-space tests
On Sun, Feb 25, 2007 at 11:51:46AM -0500, Alan Stern wrote:
> This deserves to be discussed on LKML.
Are you sure? I thought it already got pretty well answered on the USB
mailing list (see David's response for one such response.)
thanks,
greg k-h
-
To unsubscribe from this list: send the line
On Sun, 25 Feb 2007, Greg KH wrote:
> On Sun, Feb 25, 2007 at 11:51:46AM -0500, Alan Stern wrote:
> > This deserves to be discussed on LKML.
>
> Are you sure? I thought it already got pretty well answered on the USB
> mailing list (see David's response for one such response.)
Well, I was sure a
On Sun, 2007-02-25 at 10:58 +0200, Avi Kivity wrote:
> I'm changing the kvm userspace interface to be more friendly to other
> archs. One issue is the PIO port size. x86 uses 16 bits to hold the
> port size (64K ports). Is that an issue for other archs?
>
> I guess I could change it to __u32,
Hollis Blanchard wrote:
On Sun, 2007-02-25 at 10:58 +0200, Avi Kivity wrote:
I'm changing the kvm userspace interface to be more friendly to other
archs. One issue is the PIO port size. x86 uses 16 bits to hold the
port size (64K ports). Is that an issue for other archs?
I guess I could
commit b350d3ae0a21fd093d99644a3cfb90f4fb275cb2
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Mon Feb 26 01:26:06 2007 -0500
[libata] sata_mv: clean up DMA boundary issues, turn on 64-bit DMA
The chips covered by sata_mv have a 32-bit DMA boundary they must not
cross, not a 64K
Hi!
I just brought two D-Link DGE-528T (uses r8159 driver) network adapters
to have nice 1 Gbps home network between two computers.
I have gigabit crossover cable that is connected like this
Pin Connector #1 Connector #2
1white/orange white/green
2orangegreen
3white/green
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
201 - 227 of 227 matches
Mail list logo
