I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
Bye.
---
Fix decision of memoryless node in find_next_best_node().
This can be cause of SW-IOMMU's allocation failure.
This patch is for 2.6.23-rc3-mm1.
Signed-off-by
On Thu, Aug 23, 2007 at 09:56:16AM -0700, Jesse Barnes wrote:
> On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote:
> > > Of course, the normal memory barrier would usually be a
> > > "spin_unlock()" or something like that, not a "wmb()". In fact, I
> > > don't think the powerpc imp
On Thu, Aug 23, 2007 at 06:27:42PM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote:
> >
> > On Thu, 23 Aug 2007, Nick Piggin wrote:
> > >
> > > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > > until the point of unlock.
> >
On Thu, Aug 23, 2007 at 09:16:42AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > until the point of unlock.
>
> And that is exactly what ppc64 does.
>
> But you're missing a big point:
vmalloc() returns a void pointer - no need to cast it.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
arch/ia64/sn/kernel/sn2/sn_hwperf.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/ia64/sn/kernel/sn2/sn_hwperf.c
b/arch/ia64/sn/kernel/sn2/sn_hwperf.c
index
On Thu, 23 Aug 2007 10:22:26 -0700
"Luck, Tony" <[EMAIL PROTECTED]> wrote:
> > __get_free_pages() of swiotlb_alloc_coherent() fails in rc3-mm1.
> > But, it doesn't fail on rc2-mm2, and kernel can boot up.
>
> That looks to be part of the problem here ... failing an order=3
> allocation during boo
> __get_free_pages() of swiotlb_alloc_coherent() fails in rc3-mm1.
> But, it doesn't fail on rc2-mm2, and kernel can boot up.
That looks to be part of the problem here ... failing an order=3
allocation during boot on a system that just a few lines earlier
in the boot log reported "Memory: 37474000
> > Yeah, they keep threatening to use this instead, but I'm not sure
> > how easy it would be. Also they may have more devices/drivers to
> > worry about than sn2, so maybe changing over would mean too much
> > driver debugging (well auditing really since it's not that hard to
> > know where to p
On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote:
> > Of course, the normal memory barrier would usually be a
> > "spin_unlock()" or something like that, not a "wmb()". In fact, I
> > don't think the powerpc implementation (as an example of this) will
> > actually synchronize with
On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote:
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > until the point of unlock.
>
> And that is exactly what ppc64 does.
>
> But you're missing a big point: for 99.9%
On Thu, 23 Aug 2007, Nick Piggin wrote:
>
> Also, FWIW, there are some advantages of deferring the mmiowb thingy
> until the point of unlock.
And that is exactly what ppc64 does.
But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
total no-op. So when you talk about "adva
On Thu, 23 Aug 2007, Nick Piggin wrote:
>
> OK, but we'd have some kind of functions that are called not to
> serialise the CPUs, but to serialise the IO. It would be up to
> the calling code to already provide CPU synchronisation.
>
> serialize_io(); / unserialize_io(); / a nicer name
We coul
Andrew Morton wrote:
> On Wed, 22 Aug 2007 14:15:16 -0500
> Dean Nelson <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Aug 22, 2007 at 11:04:22AM -0700, Andrew Morton wrote:
>>> On Wed, 22 Aug 2007 12:00:11 -0500
>>> Dean Nelson <[EMAIL PROTECTED]> wrote:
>>>
3) WARNING: declaring multiple variabl
> On (22/08/07 16:27), Luck, Tony didst pronounce:
> > > The more ioc's you have, the more space you will use.
> >
> > Default SW IOTLB allocation is 64MB ... how much should we see
> > used per ioc?
> >
> > Kamelesh: You could try increasing the amount of sw iotlb space
> > available by booting
On (22/08/07 16:27), Luck, Tony didst pronounce:
> > The more ioc's you have, the more space you will use.
>
> Default SW IOTLB allocation is 64MB ... how much should we see
> used per ioc?
>
> Kamelesh: You could try increasing the amount of sw iotlb space
> available by booting with a swiotlb=1
Luck, Tony wrote:
The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Kamelesh: You could try increasing the amount of sw iotlb space
available by booting with a swiotlb=131072 argument (argument
value is the n
James Bottomley wrote:
Hmm, didn't see the email ... but I'm probably not cc'd on all the
thread. However ... it isn't that you couldn't do it ... it's that you
don't want to do it because it's faster to violate the spec ... like all
those nice ATA devices that lie about having a cache and then
> Of course, the normal memory barrier would usually be a "spin_unlock()" or
> something like that, not a "wmb()". In fact, I don't think the powerpc
> implementation (as an example of this) will actually synchronize with
> anything *but* a spin_unlock().
We are even more sneaky in the sense t
On Wed, 2007-08-22 at 06:57 +0200, Nick Piggin wrote:
> It doesn't seem like this primary function of mmiowb has anything to do
> with a write barrier that we are used to (it may have a seconary semantic
> of a wmb as well, but let's ignore that for now). A write barrier will
> never provide you w
19 matches
Mail list logo
