On Tuesday 16 January 2007 19:01, Chris Wedgwood wrote:
> On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
> > >If one use iommu=soft the sata_nv will continue to use the new code
> > >for the ADMA, right?
> >
> > Right, that shouldn't affect it.
>
> right now i'm thinking if we can'
Arkadiusz Miskiewicz wrote:
> FYI it seems that I was also hit by this bug with qlogic fc card + adaptec
> taro raid controller on Thunder K8SRE S2891 mainboard with nvidia chipset on
> it.
>
> http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/b8bdbde9721f7d35/45701994c95fe2cf?l
As it is currently written, sys_select checks its return code to convert
ERESTARTNOHAND to EINTR. However, the check is within an if (tvp) clause, and
so if select is called from userspace with a NULL timeval, then it is possible
for the ERESTARTNOHAND errno to leak into userspace, which is incorr
Chris Wedgwood <[EMAIL PROTECTED]> writes:
> right now i'm thinking if we can't figure out which cpu/bios
> combinations are safe we might almost be better off doing iommu=soft
> for *all* k8 stuff except for those that are whitelisted; though this
> seems extremely drastic
Do you (someone) have
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> I agree,... it seems drastic, but this is the only really secure
> solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem
Helge Hafting <[EMAIL PROTECTED]> wrote:
> Michael Tokarev wrote:
>> But seriously - what about just disallowing non-O_DIRECT opens together
>> with O_DIRECT ones ?
>>
> Please do not create a new local DOS attack.
> I open some important file, say /etc/resolv.conf
> with O_DIRECT and just sit
Oliver:
Are you aware that your patch for safe attribute file removal provokes a
lockdep warning at bootup?
[ 25.270416] =
[ 25.270518] [ INFO: possible recursive locking detected ]
[ 25.270571] 2.6.20-rc4 #3
[ 25.270619] --
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote:
> Do you (someone) have (maintain) a list of affected systems,
> including motherboard type and possibly version, BIOS version and
> CPU type? A similar list of unaffected systems with 4GB+ RAM could
> be useful, too.
All I know is
On Tue, 16 Jan 2007, Paul Menage wrote:
> I was thinking runtime, unless MAX_NUMNODES is less than 64 in which
> case you can make the decision at compile time.
>
> >
> > If done at compile time then we will end up with a pointer to an unsigned
> > long for a system with <= 64 nodes. If we alloc
Am Dienstag, 16. Januar 2007 21:33 schrieb Alan Stern:
> Are you aware that your patch for safe attribute file removal provokes a
> lockdep warning at bootup?
Yes, I am aware of that. However, the top down lock order is always
followed. A patch to make the lock checker realize that has been poste
Adrian Bunk wrote:
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc3-mm1:
...
git-gfs2-nmw.patch
...
git trees
...
This patch makes the needlessly globlal gfs2_change_nlink_i() static.
We will probably need to call this routine from other
On Tue, Jan 16, 2007 at 10:15:57PM +0100, Oliver Neukum wrote:
> Am Dienstag, 16. Januar 2007 21:33 schrieb Alan Stern:
> > Are you aware that your patch for safe attribute file removal provokes a
> > lockdep warning at bootup?
>
> Yes, I am aware of that. However, the top down lock order is alwa
Hi,
I have looked at kprobes code and have some questions for you. I would really
like to use it to patch dynamically my marker immediate value by doing code
patching. Using an int3 seems like the right way to handle this wrt pIII erratum
49.
Everything is ok, except for a limitation important to
On Tue, Jan 16, 2007 at 04:04:15PM -0500, Wendy Cheng wrote:
> Adrian Bunk wrote:
> >On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
> >
> >>...
> >>Changes since 2.6.20-rc3-mm1:
> >>...
> >> git-gfs2-nmw.patch
> >>...
> >> git trees
> >>...
> >>
> >
> >
> >This patch makes the
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
> On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> > I agree,... it seems drastic, but this is the only really secure
> > solution.
>
> I'd like to here from Andi how he feels about this? It seems like a
> somewha
> On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
>
> Currently cpusets are not able to do proper writeback since
> dirty ratio calculations and writeback are all done for the system
> as a whole.
We _do_ do proper writeback. But it's less efficient than i
> I'd like to here from Andi how he feels about this? It seems like a
> somewhat drastic solution in some ways given a lot of hardware doesn't
> seem to be affected (or maybe in those cases it's just really hard to
> hit, I don't know).
>
> > Well we can hope that Nvidia will find out more (thoug
> Secondly we modify the dirty limit calculation to be based
> on the acctive cpuset.
The global dirty limit definitely seems to be a problem
in several cases, but my feeling is that the cpuset is the wrong unit
to keep track of it. Most likely it should be more fine grained.
> If we are in a cp
Subject: nfs: fix congestion control
The current NFS client congestion logic is severely broken, it marks the
backing device congested during each nfs_writepages() call and implements
its own waitqueue.
Replace this by a more regular congestion implementation that puts a cap
on the number of acti
On Tue, 16 Jan 2007, Andrew Morton wrote:
> > On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter <[EMAIL
> > PROTECTED]> wrote:
> >
> > Currently cpusets are not able to do proper writeback since
> > dirty ratio calculations and writeback are all done for the system
> > as a whole.
>
> W
On Wed, 17 Jan 2007, Andi Kleen wrote:
> > Secondly we modify the dirty limit calculation to be based
> > on the acctive cpuset.
>
> The global dirty limit definitely seems to be a problem
> in several cases, but my feeling is that the cpuset is the wrong unit
> to keep track of it. Most likely i
This is a note to let you know that I've just added the patch titled
Subject: PCI: rework Documentation/pci.txt
to my gregkh-2.6 tree. Its filename is
pci-rework-documentation-pci.txt.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.
On Tue, 2007-01-16 at 23:08 +0100, Peter Zijlstra wrote:
> Subject: nfs: fix congestion control
>
> The current NFS client congestion logic is severely broken, it marks the
> backing device congested during each nfs_writepages() call and implements
> its own waitqueue.
>
> Replace this by a more
Hi all,
I have just tried a 2.6.20-rc5 kernel (I previously used a 2.6.19 one),
and I have noticed that the IPv6 router advertisement functionality is
broken. The interface is not attributed an IPv6 address anymore, despite
/proc/sys/net/ipv6/conf/all/ra_accept being set to 1 (also true for each
i
Aurelien Jarno wrote:
> I have just tried a 2.6.20-rc5 kernel (I previously used a 2.6.19 one),
> and I have noticed that the IPv6 router advertisement functionality is
> broken. The interface is not attributed an IPv6 address anymore, despite
> /proc/sys/net/ipv6/conf/all/ra_accept being set to 1
On Wed, Jan 17, 2007 at 01:38:35AM +0900, takada wrote:
> You are right. I agree to your comment. These variables are needless.
> I made a patch again.
>
> diff -Narup linux-2.6.19.orig/arch/i386/kernel/cpu/cyrix.c
> linux-2.6.19/arch/i386/kernel/cpu/cyrix.c
> --- linux-2.6.19.orig/arch/i386/kern
Ingo Oeser <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> On Tuesday, 16. January 2007 17:39, Eric W. Biederman wrote:
>> diff --git a/drivers/parport/procfs.c b/drivers/parport/procfs.c
>> index 2e744a2..5337789 100644
>> --- a/drivers/parport/procfs.c
>> +++ b/drivers/parport/procfs.c
>> @@ -263,50
On Tue, Jan 16, 2007 at 10:42:53PM +0100, Aurelien Jarno wrote:
> I have just tried a 2.6.20-rc5 kernel (I previously used a 2.6.19 one),
> and I have noticed that the IPv6 router advertisement functionality is
Can you check if rc1, rc2, rc3 etc do work?
Thanks.
--
http://www.PowerDNS.com
Fir4st I'd say thanks a lot for forward-porting this, it's really useful
feature for all kinds of nasty debugging.
I think you should split this into two patches, one for the debugreg
infrastructure, and one for the actual kwatch code.
Also I think you provide one (or even a few) example wathes f
> On Tue, 16 Jan 2007 14:15:56 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
>
> ...
>
> > > This may result in a large percentage of a cpuset
> > > to become dirty without writeout being triggered. Under NFS
> > > this can lead to OOM conditions.
> >
> > OK, a big question: is this
On Tue, Jan 16, 2007 at 01:53:25PM -0800, Andrew Morton wrote:
> > On Mon, 15 Jan 2007 21:47:43 -0800 (PST) Christoph Lameter
> > <[EMAIL PROTECTED]> wrote:
> >
> > Currently cpusets are not able to do proper writeback since dirty ratio
> > calculations and writeback are all done for the system as
(Ingo -- you seem to be the last person to touch all this stuff, and I
can't untangle what you did, hence I'm sending this email to you)
On at least some of my configs on x86_64, when running sparse, I see
bogus 'warning: context imbalance in '' - wrong count at exit'.
This seems to be because I
I think the following patch
[IPV6] MCAST: Fix joining all-node multicast group on device initialization.
http://www.spinics.net/lists/netdev/msg22663.html
that went in after 2.6.20-rc5 should fix this problem.
Thanks
Sridhar
On 1/16/07, bert hubert <[EMAIL PROTECTED]> wrote:
On Tue, Jan 16,
On Mon, Jan 15, 2007 at 08:32:17PM +, David Hollis wrote:
> Interesting. It would really be something if your devices happen to
> work better with 0. Wouldn't make much sense at all unfortunately. If
> 0 works, could you also try setting it to 2 or 3? The PHY select value
> is a bit field w
Aurelien Jarno wrote:
Hi all,
I have just tried a 2.6.20-rc5 kernel (I previously used a 2.6.19 one),
and I have noticed that the IPv6 router advertisement functionality is
broken. The interface is not attributed an IPv6 address anymore, despite
/proc/sys/net/ipv6/conf/all/ra_accept being set to
On Tuesday 09 January 2007 16:43, Lennart Sorensen wrote:
> On Tue, Jan 09, 2007 at 06:41:56PM +0900, takada wrote:
> > In kernel 2.6, write back wrong register when configure Geode processor.
> > Instead of storing to CCR4, it stores to CCR3.
> >
> > --- linux-2.6.19/arch/i386/kernel/cpu/cyrix.c.o
On Tue, 16 Jan 2007, Andrew Morton wrote:
> It's a workaround for a still-unfixed NFS problem.
No its doing proper throttling. Without this patchset there will *no*
writeback and throttling at all. F.e. lets say we have 20 nodes of 1G each
and a cpuset that only spans one node.
Then a process r
On Tuesday 09 January 2007 18:33, Lennart Sorensen wrote:
> Then for the next one it does:
> ccr3 = GetCx86(CX86_CCR3);
> setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
>
> Couldn't that have been:
> setCx86(CX86_CCR3, (getCx86(CX86_CCR3) & 0x0f) | 0x10);
>
> No temp variable, and again it clearly does
Index: linux-2.6.19-rc6-arnd1+patches/arch/powerpc/platforms/cell/spufs/sched.c
===
---
linux-2.6.19-rc6-arnd1+patches.orig/arch/powerpc/platforms/cell/spufs/sched.c
2006-12-04 10:56:04.730698720 -0600
+++ linux-2.6.19-rc6-arnd
On Wed, Jan 17, 2007 at 12:30:53AM +0100, bert hubert wrote:
> On Tue, Jan 16, 2007 at 10:42:53PM +0100, Aurelien Jarno wrote:
>
> > I have just tried a 2.6.20-rc5 kernel (I previously used a 2.6.19 one),
> > and I have noticed that the IPv6 router advertisement functionality is
>
> Can you check
On Mon, Jan 08, 2007 at 11:06:44AM -0500, Alan Stern wrote:
> This patch (as832) fixes a newly-introduced bug in the driver core.
> When a kobject is assigned to a kset, it must acquire a reference to
> the kset.
>
> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
>
> ---
>
> The bug was introduce
> On Tue, 16 Jan 2007 16:16:30 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 16 Jan 2007, Andrew Morton wrote:
>
> > It's a workaround for a still-unfixed NFS problem.
>
> No its doing proper throttling. Without this patchset there will *no*
> writeback and throttling at
Chris Wedgwood wrote:
> I'd like to here from Andi how he feels about this? It seems like a
> somewhat drastic solution in some ways given a lot of hardware doesn't
> seem to be affected (or maybe in those cases it's just really hard to
> hit, I don't know).
>
Yes this might be true,.. those wh
Andi Kleen wrote:
> AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
> although there were similar problems on VIA in the past too.
> Unless a good workaround comes around soon I'll probably default
> to iommu=soft on Nvidia.
I've just read the posts about AMDs and NVIDIAs eff
On Tue, 16 Jan 2007, Andrew Morton wrote:
> Nope. You've completely omitted the little fact that we'll do writeback in
> the offending zone off the LRU. Slower, maybe. But it should work and the
> system should recover. If it's not doing that (it isn't) then we should
> fix it rather than avoi
On Tuesday 16 January 2007 16:47, Christoph Lameter wrote:
> I think having the ability to determine the maximum amount of nodes in
> a system at runtime is useful but then we should name this entry
> correspondingly and also only calculate the value once on bootup.
Are you sure this is even poss
On Tue, 16 Jan 2007 03:36:16 -0500 (EST) Robert P. J. Day wrote:
> On Tue, 16 Jan 2007, Ahmed S. Darwish wrote:
>
> > Use ARRAY_SIZE macro in pvrusb2-hdw.c file
> >
> > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
>
> ... snip ...
>
> i'm not sure it's worth submitting multiple patches t
On Tue, 16 Jan 2007, Randy Dunlap wrote:
> On Tue, 16 Jan 2007 03:36:16 -0500 (EST) Robert P. J. Day wrote:
>
> > On Tue, 16 Jan 2007, Ahmed S. Darwish wrote:
> >
> > > Use ARRAY_SIZE macro in pvrusb2-hdw.c file
> > >
> > > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
> >
> > ... snip ...
>
On Tue, Jan 16, 2007 at 03:36:16AM -0500, Robert P. J. Day wrote:
> On Tue, 16 Jan 2007, Ahmed S. Darwish wrote:
>
> > Use ARRAY_SIZE macro in pvrusb2-hdw.c file
> >
> > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
>
> ... snip ...
>
> i'm not sure it's worth submitting multiple patches t
On Tue, Jan 16, 2007 at 10:16:33AM -0800, Randy Dunlap wrote:
> On Tue, 16 Jan 2007 03:36:16 -0500 (EST) Robert P. J. Day wrote:
>
> > On Tue, 16 Jan 2007, Ahmed S. Darwish wrote:
> >
> > > Use ARRAY_SIZE macro in pvrusb2-hdw.c file
> > >
> > > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
Em Ter, 2007-01-16 às 20:54 +0200, Ahmed S. Darwish escreveu:
> On Tue, Jan 16, 2007 at 03:36:16AM -0500, Robert P. J. Day wrote:
> > On Tue, 16 Jan 2007, Ahmed S. Darwish wrote:
> >
> > > Use ARRAY_SIZE macro in pvrusb2-hdw.c file
> > >
> > > Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
>
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> First one is about building for UP (CONFIG_SMP not set) on my old P4
> laptop. As it seems, all my build attempts failed at the final link
> stage, with undefined references to paravirt_enable. After disabling
> CONFIG_PARAVIRT I get a similar fai
On Tue, January 16, 2007 11:56, Ingo Molnar wrote:
>
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> First one is about building for UP (CONFIG_SMP not set) on my old P4
>> laptop. As it seems, all my build attempts failed at the final link
>> stage, with undefined references to paravirt_enabl
> On Tue, 16 Jan 2007 17:30:26 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> > Nope. You've completely omitted the little fact that we'll do writeback in
> > the offending zone off the LRU. Slower, maybe. But it should work and the
> > system should recover. If it's not doing th
Dave,
Currently in resuming path graphics device's pci space restore is
behind host bridge, so resume function wrongly accesses graphics
device's space. This makes resuming failure which crashed X. So
here's a patch to restore device's pci space early, which makes
resuming ok with X. Patch ag
On Wed, 17 Jan 2007, Andi Kleen wrote:
> On Tuesday 16 January 2007 16:47, Christoph Lameter wrote:
>
> > I think having the ability to determine the maximum amount of nodes in
> > a system at runtime is useful but then we should name this entry
> > correspondingly and also only calculate the val
On Tue, 16 Jan 2007, Andrew Morton wrote:
> Consider: non-exclusive cpuset A consists of mems 0-15, non-exclusive
> cpuset B consists of mems 0-3. A task running in cpuset A can freely dirty
> all of cpuset B's memory. A task running in cpuset B gets oomkilled.
>
> Consider: a 32-node machine h
On Tue, Jan 16, 2007 at 05:15:02PM +1100, David Chinner wrote:
> On Sat, Jan 13, 2007 at 08:11:25AM +0100, Adrian Bunk wrote:
> > On Fri, Jan 12, 2007 at 02:27:48PM -0500, Linus Torvalds wrote:
> > >...
> > > A lot of developers (including me) will be gone next week for
> > > Linux.Conf.Au, so you
Mikael Pettersson wrote:
These #ifdefs are too ugly.
Since you apparently just add aliases for the case labels,
and do no actual code changes, why not
1. make the new cases unconditional, or
2. invoke a translation function before the switch which
maps the MTRRCIOC32_ constants to what the
On Tue, 2007-01-16 at 17:27 -0500, Trond Myklebust wrote:
> On Tue, 2007-01-16 at 23:08 +0100, Peter Zijlstra wrote:
> > Subject: nfs: fix congestion control
> >
> > The current NFS client congestion logic is severely broken, it marks the
> > backing device congested during each nfs_writepages() c
Just tried linux for the first time on this old machine, and i got
this problem. dmesg below:
Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo
4.1.1-r3)) #10 PREEMPT Sun Dec 10 17:35:24 BRST 2006
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (us
> Yes this is the result of the hierachical nature of cpusets which already
> causes issues with the scheduler. It is rather typical that cpusets are
> used to partition the memory and cpus. Overlappig cpusets seem to have
> mainly an administrative function. Paul?
The heavy weight tasks, which
> On Tue, 16 Jan 2007 19:40:17 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 16 Jan 2007, Andrew Morton wrote:
>
> > Consider: non-exclusive cpuset A consists of mems 0-15, non-exclusive
> > cpuset B consists of mems 0-3. A task running in cpuset A can freely dirty
> > all
On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> Just tried linux for the first time on this old machine, and i got
> this problem. dmesg below:
did this machine EVER support acpi ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Tuesday 16 January 2007 16:48, Christoph Lameter wrote:
> Direct reclaim: cpuset aware writeout
>
> During direct reclaim we traverse down a zonelist and are carefully
> checking each zone if its a member of the active cpuset. But then we call
> pdflush without enforcing the same restrictions. I
On Wednesday 17 January 2007 14:14, Christoph Lameter wrote:
> On Wed, 17 Jan 2007, Andi Kleen wrote:
> > On Tuesday 16 January 2007 16:47, Christoph Lameter wrote:
> > > I think having the ability to determine the maximum amount of nodes in
> > > a system at runtime is useful but then we should na
Andi wrote:
> Is there a reason this can't be just done by node, ignoring the cpusets?
This suggestion doesn't make a whole lot of sense to me.
We're looking to see if a task has dirtied most of the
pages in the nodes it is allowed to use. If it has, then
we want to start pushing pages to the di
On Wed, 17 Jan 2007, Andi Kleen wrote:
> On Tuesday 16 January 2007 16:48, Christoph Lameter wrote:
> > Direct reclaim: cpuset aware writeout
> >
> > During direct reclaim we traverse down a zonelist and are carefully
> > checking each zone if its a member of the active cpuset. But then we call
>
On Wed, 17 Jan 2007, Andi Kleen wrote:
> > > Are you sure this is even possible in general on systems with node
> > > hotplug? The firmware might not pass a maximum limit.
> >
> > In that case the node possible map must include all nodes right?
>
> Yes.
Then we are fine.
-
To unsubscribe from t
On 1/17/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> Just tried linux for the first time on this old machine, and i got
> this problem. dmesg below:
did this machine EVER support acpi ?
It used to support power button events, do
On Wednesday 17 January 2007 15:20, Paul Jackson wrote:
> Andi wrote:
> > Is there a reason this can't be just done by node, ignoring the cpusets?
>
> This suggestion doesn't make a whole lot of sense to me.
>
> We're looking to see if a task has dirtied most of the
> pages in the nodes it is allow
On 1/12/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Thu, 11 Jan 2007, Roy Huang wrote:
>
> On a embedded systerm, limiting page cache can relieve memory
> fragmentation. There is a patch against 2.6.19, which limit every
> opened file page cache and total pagecache. When the limit reach, i
> With a per node dirty limit ...
What would this mean?
Lets say we have a simple machine with 4 nodes, cpusets disabled.
Lets say all tasks are allowed to use all nodes, no set_mempolicy
either.
If a task happens to fill up 80% of one node with dirty pages, but
we have no dirty pages yet on ot
Subject: [PATCH]: cosmetic fixes
[MTRR 2.6.19.1]: cosmetic fixes
Signed-off-by: Giuliano Procida <[EMAIL PROTECTED]>
---
Fixed incorrect (though identical) types in struct mtrr_gentry32 and
tided some badly-indented comments.
--- linux-source-2.6.19.1.orig/include/asm-x86_64/mtrr.h2006
On Tue, 2007-01-16 at 21:26 +0100, Bodo Eggert wrote:
> Helge Hafting <[EMAIL PROTECTED]> wrote:
> > Michael Tokarev wrote:
>
> >> But seriously - what about just disallowing non-O_DIRECT opens together
> >> with O_DIRECT ones ?
> >>
> > Please do not create a new local DOS attack.
> > I open s
On Wednesday 17 January 2007 15:36, Paul Jackson wrote:
> > With a per node dirty limit ...
>
> What would this mean?
>
> Lets say we have a simple machine with 4 nodes, cpusets disabled.
There can be always NUMA policy without cpusets for once.
> Lets say all tasks are allowed to use all nodes,
On Wed, 2007-01-17 at 03:41 +0100, Peter Zijlstra wrote:
> On Tue, 2007-01-16 at 17:27 -0500, Trond Myklebust wrote:
> > On Tue, 2007-01-16 at 23:08 +0100, Peter Zijlstra wrote:
> > > Subject: nfs: fix congestion control
> > >
> > > The current NFS client congestion logic is severely broken, it ma
On Tue, Jan 16, 2007 at 04:27:25PM +0300, Oleg Nesterov wrote:
> > I meant issuing kthread_stop() in DOWN_PREPARE so that worker
> > thread exits itself (much before CPU is actually brought down).
>
> Deadlock if work_struct re-queues itself.
Are you referring to the problem you described here?
On Wed, 17 Jan 2007, Andi Kleen wrote:
> No actually people are fairly unhappy when one node is filled with
> file data and then they don't get local memory from it anymore.
> I get regular complaints about that for Opteron.
Switch on zone_reclaim and it will take care of it. You can even switch
On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
On 1/17/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> > Just tried linux for the first time on this old machine, and i got
> > this problem. dmesg below:
>
>
> did this machine E
On Tue, 16 Jan 2007, Andrew Morton wrote:
> > Yes this is the result of the hierachical nature of cpusets which already
> > causes issues with the scheduler. It is rather typical that cpusets are
> > used to partition the memory and cpus. Overlappig cpusets seem to have
> > mainly an administra
* Roland Dreier <[EMAIL PROTECTED]> wrote:
> (Ingo -- you seem to be the last person to touch all this stuff, and I
> can't untangle what you did, hence I'm sending this email to you)
>
> On at least some of my configs on x86_64, when running sparse, I see
> bogus 'warning: context imbalance i
> On Tue, 16 Jan 2007 22:27:36 -0800 (PST) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> On Tue, 16 Jan 2007, Andrew Morton wrote:
>
> > > Yes this is the result of the hierachical nature of cpusets which already
> > > causes issues with the scheduler. It is rather typical that cpusets are
>
Eric Sandeen wrote:
An update from the earlier thread, [PATCH] [RFC] remove ext3 inode
from orphan list when link and unlink race
I think this is better than the original idea of trying to handle the
race;
I've seen that the orphan inode list can get corrupted, but there may
well
be other imp
> Peter Staubach (PS) writes:
PS> Just out of curosity, what keeps i_nlink from going to 0 immediately
PS> after the new test is executed?
i_mutex in vfs_link() and vfs_unlink()
thanks, Alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Alex Tomas wrote:
Peter Staubach (PS) writes:
PS> Just out of curosity, what keeps i_nlink from going to 0 immediately
PS> after the new test is executed?
i_mutex in vfs_link() and vfs_unlink()
Ahhh... Okie doke, thanx!
ps
-
To unsubscribe from this list: send the
>On Sun, 14 Jan 2007, Adrian Bunk wrote:
> Date: Sun, 14 Jan 2007 14:45:54 +0100
> From: Adrian Bunk <[EMAIL PROTECTED]>
> To: Ravi Anand <[EMAIL PROTECTED]>,
> David Somayajulu <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], linux-scsi@vger.kernel.org,
> linux-kernel@vger.kernel.org
> Su
On Sat, 2007-01-13 at 04:25 +0100, Nick Piggin wrote:
> If prepare_write fails with AOP_TRUNCATED_PAGE, or if commit_write fails, then
> we may have failed the write operation despite prepare_write having
> instantiated blocks past i_size. Fix this, and consolidate the trimming into
> one place.
>
Since there's been no further comment on these patches, I'm going to resend
them one more time and ask Andrew to commit these to -mm. Once they're in
place there, I'll start working on and sending out follow-on patches to
clean up the other filesystems and ensure that they properly hash their
inode
When a 32-bit program that was not compiled with large file offsets does a
stat and gets a st_ino value back that won't fit in the 32 bit field, glibc
(correctly) generates an EOVERFLOW error. We can't do anything about fs's
with larger permanent inode numbers, but when we generate them on the fly,
This converts pipefs to use the new scheme. Here we're calling iunique to get
a unique i_ino value for the new inode, and then hashing it afterward. We
call iunique with a max_reserved value of 1 to avoid collision with the root
inode. Since the inode is now hashed, we need to take care that we en
This patch makes it so that simple_fill_super and get_sb_pseudo assign their
root inodes to be number 1. It also fixes up a couple of callers of
simple_fill_super that were passing in files arrays that had an index at
number 1, and adds a warning for any caller that sends in such an array.
It woul
On Tue, 2007-01-16 at 18:36 +0100, Peter Zijlstra wrote:
> buf, bytes);
> > @@ -1935,10 +1922,9 @@ generic_file_buffered_write(struct kiocb
> > cur_iov, iov_offset, bytes);
> > flush_dcache
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> Building this already with -rt5, still gives:
> ...
> LD arch/i386/boot/compressed/vmlinux
> OBJCOPY arch/i386/boot/vmlinux.bin
> BUILD arch/i386/boot/bzImage
> Root device is (3, 2)
> Boot sector 512 bytes.
> Setup is 7407 bytes.
> Syst
On 1/17/07, Luming Yu <[EMAIL PROTECTED]> wrote:
On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:
> It used to support power button events, dont know what else. Is there
> anything I can do to check how good the acpi support is?
Did you check BIOS setting? Is there any ACPI related menuite
I just tried the firmwarekit, and here are the results, attached.
TYVM, thats a very useful tool.
apicedge
(experimental) APIC Edge/Level check
4
This test checks if legacy interrupts are edge and PCI interrupts are level
Non-Legacy interrupt 0 is incorrectly level triggered
4
in
Annotate i386/kernel/entry.S with END/ENDPROC to assist disassemblers and
other analysis tools.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20-rc5/arch/i386/kernel/entry.S 2007-01-15 14:09:19.0
+0100
+++ 2.6.20-rc5-i386-entry-end/arch/i386/kernel/entry.S 2007-01-04
1
Ingo Molnar a écrit :
* Ulrich Drepper <[EMAIL PROTECTED]> wrote:
what do you mean by that - which is this same resource?
From what has been said here before, all futexes are stored in the
same list or hash table or whatever it was. I want to see how that
code behaves if many separate proces
Eric W. Biederman wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
>
> In the binary sysctl interface the hpet driver was claiming to
> be the cdrom driver. This is a no-no so remove support for the
> binary interface.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Acke
Hi!
I started using el-cheapo usb mouse... only to find out that it breaks
suspend to RAM. Suspend-to-disk works okay. I was not able to extract
any usefull messages...
Resume process hangs; I can still switch console and even type on
keyboard, but userland is dead, and I was not able to get mag
101 - 200 of 322 matches
Mail list logo
