* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Kumar Gala @ 2006-10-20 14:18 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <453884F5.4000804@bplan-gmbh.de>
On Oct 20, 2006, at 3:12 AM, Nicolas DET wrote:
> Kumar Gala wrote:
> >
> > On Oct 19, 2006, at 7:39 AM, Nicolas DET wrote:
> >
> >> This 'big' patch adds support for CHRP/MPC52xx based platform.
> Here, this is the bPlan's Efika computer (http://www.bplan-gmbh.de/
> efika_spec_en.html)
> >
>
> > Some high level comments:
> > 1. lets stick with the 52xx naming, instead of 5k2
>
> Ok. Will be done
>
> > 2. PIC code needs to be updated for new interrupt model (as well
> as remove of pt_regs)
>
> Ok.
>
> > 3. use standard kernel debug macros
>
> Loads of changes in the pipe line ;-)
>
> > 4. look at replacing sram_allocator w/rheap
> >
>
> This SRAM allocator is the exact same from the original Linux one.
> In fact, it is the original one. Would it be possible to accept
> this code as it is and schedule rheap integration later ?
I dont follow, what do you mean by 'original Linux one' ?
> > if you repost the patch broken up into driver and platform bits
> it will be easier to provide more detailed comments.
>
> Ok. I'm alraedy working on it since I post the first one :-) .
> Thank you very much for your comments. I hope to re submit a much
> better patch today.
>
> Regads
> <nd.vcf>
^ permalink raw reply
* how to reserve memory in linux?
From: Ming Liu @ 2006-10-20 14:27 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
My situation is, I want to reserve some amount of memory and make it shared
by both Linux kernel and another hardware peripheral. That is, when I boot
linux and execute some user space programs, this part of memory should be
reserved for other use and cannot be used by both the kernel and those
applications. But it could be accessed by Linux with some certain kind of
application and also be accessed by another hardware peripheral with DMA or
something like that.
I am not sure if I am right but I think it's just like the situation of
multiprocessing (if we can treat that hardware peripheral as another
processor, or just use another processor to realize its functions.) and
that part of memory is just like the hardware shared memory by
multiprocessor. Am I right?
Then my question is, how to reserve such part of memory in Linux? Does
Linux has such a function?
I am not falimiar with such a topic, so any hint related to this is
appreciated.
Thanks for your ideals and suggestions.
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Kumar Gala @ 2006-10-20 14:34 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <4538DC0B.7060402@bplan-gmbh.de>
On Oct 20, 2006, at 9:24 AM, Nicolas DET wrote:
> Kumar Gala wrote:
>
> >>
> >> > 4. look at replacing sram_allocator w/rheap
> >> >
> >>
> >> This SRAM allocator is the exact same from the original Linux
> one. In
> >> fact, it is the original one. Would it be possible to accept
> this code
> >> as it is and schedule rheap integration later ?
> >
> > I dont follow, what do you mean by 'original Linux one' ?
>
> There are already some kind of Bestcomm DMA engine supoprt for some
> embbeded system (ARCH=ppc). In order to speed up the developement,
> the API is (almost) compatible so we can use the drivers wrote for
> this API. For example, the Ethernet driver enterily rely on this
> API. However, the 'soon to be release' ATA driver has been rewritten.
>
> I did not at the time (yet) to look at rheap, but I know the
> current allocator is not really good (it can not free!).
>
> I was just thinking, as this code is alraedy in some Linux tree, we
> could still use it there, and plan to replace it by a much better
> one (keeping the API compatible) later on.
Is this in the kernel tree already, I am not coming across it.
- k
^ permalink raw reply
* Re: Correct way to format spufs file output.
From: Arnd Bergmann @ 2006-10-20 14:38 UTC (permalink / raw)
To: Dwayne Grant McConnell; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <Pine.WNT.4.64.0610200848580.5976@dwayne>
On Friday 20 October 2006 15:54, Dwayne Grant McConnell wrote:
> I think %0xllx is the way to go. I would even advocate changing
> signal1_type and signal2_type unless it is actually too dangerous.
There is absolutely no reason why these should be hexadecimal, they
are basically implementing a bool.
> Is there even a case where changing from %llu to %0xllx would break things?
> Perhaps with the combination of a old library with a new kernel?
Right, a library or some script that has been written assuming there
is no leading 0x.
Arnd <><
^ permalink raw reply
* Re: Correct way to format spufs file output.
From: Dwayne Grant McConnell @ 2006-10-20 14:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <200610201638.52404.arnd@arndb.de>
On Fri, 20 Oct 2006, Arnd Bergmann wrote:
> On Friday 20 October 2006 15:54, Dwayne Grant McConnell wrote:
> > I think %0xllx is the way to go. I would even advocate changing
> > signal1_type and signal2_type unless it is actually too dangerous.
>
> There is absolutely no reason why these should be hexadecimal, they
> are basically implementing a bool.
>
> > Is there even a case where changing from %llu to %0xllx would break things?
> > Perhaps with the combination of a old library with a new kernel?
>
> Right, a library or some script that has been written assuming there
> is no leading 0x.
Okay. Thanks for considering it. I'll leave the %llu as is.
--
Dwayne Grant McConnell <decimal@us.ibm.com>
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Nicolas DET @ 2006-10-20 14:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <122A4E06-B8A6-4256-B96E-3811EA93EA25@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
Kumar Gala wrote:
>>
>> > 4. look at replacing sram_allocator w/rheap
>> >
>>
>> This SRAM allocator is the exact same from the original Linux one. In
>> fact, it is the original one. Would it be possible to accept this code
>> as it is and schedule rheap integration later ?
>
> I dont follow, what do you mean by 'original Linux one' ?
There are already some kind of Bestcomm DMA engine supoprt for some
embbeded system (ARCH=ppc). In order to speed up the developement, the
API is (almost) compatible so we can use the drivers wrote for this API.
For example, the Ethernet driver enterily rely on this API. However, the
'soon to be release' ATA driver has been rewritten.
I did not at the time (yet) to look at rheap, but I know the current
allocator is not really good (it can not free!).
I was just thinking, as this code is alraedy in some Linux tree, we
could still use it there, and plan to replace it by a much better one
(keeping the API compatible) later on.
Regards,
[-- Attachment #2: nd.vcf --]
[-- Type: text/x-vcard, Size: 249 bytes --]
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:nd@bplan-gmbh.de
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Andy Whitcroft @ 2006-10-20 14:18 UTC (permalink / raw)
To: Paul Mackerras
Cc: akpm, Mel Gorman, linux-kernel, linuxppc-dev, Anton Blanchard,
Christoph Lameter
In-Reply-To: <17720.30804.180390.197567@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Christoph Lameter writes:
>
>> The page allocator must be running and able to serve pages from the boot
>> node. This fails for some reason and the slab cannot bootstrap. The memory
>> not available is the first guess. Could you trace the allocation in the
>> page allocator (__alloc_pages) when the slab attempts to bootstrap and
>> figure out why exactly the allocation fails?
>
> What is happening is that all pages are getting their zone id field in
> their page->flags set to point to zone for node 1 by memmap_init_zone
> calling set_page_links (which does set_page_zone). Thus, when those
> pages get freed by free_all_bootmem_node, they all end up in the zone
> for node 1.
>
> memmap_init_zone is called (as memmap_init, since we don't have
> __HAVE_ARCH_MEMMAP_INIT defined) from init_currently_empty_zone, which
> is called from free_area_init_core. Now the thing is that memmap_init
> and init_currently_empty_zone are called with the node's start PFN and
> size in pages, *including* holes. On the partition I'm using we have
> these PFN ranges for the nodes:
>
> 1: 0 -> 32768
> 0: 32768 -> 278528
> 1: 278528 -> 524288
>
> So node 0's start PFN is 32768 and its size is 245760 pages, and so we
> correctly set pages 32786 to 278527 to be in the zone for node 0.
> Then for node 1, we have the start PFN is 0 and the size is 524288, so
> we then go through and set *all* pages of memory to be in the zone for
> node 1, including the pages which are actually on node 0.
>
> That's why we can't allocate any pages on node 0, and the kmem cache
> bootstrapping blows up.
>
> I don't know this code well enough to know what the correct fix is.
> Clearly memmap_init_zone should only be touching the pages that are
> actually present in the zone, but I don't know exactly what data
> structures it should be using to know what those pages are.
Mel Gorman and I have been poking at this from different ends. Mel from
the context of this thread and myself trying to fix a machine which was
exhibiting on 32MB of ram in node 0 and the rest in node 1.
I remember that we used to have code to cope with this in the ppc64
architecture, indeed I remember reviewing it all that time ago. Looking
at the current state of the tree it was removed in the two patches below
in mainline:
"[PATCH] Remove SPAN_OTHER_NODES config definition"
"[PATCH] mm: remove arch independent NODES_SPAN_OTHER_NODES"
These commits:
f62859bb6871c5e4a8e591c60befc8caaf54db8c
a94b3ab7eab4edcc9b2cb474b188f774c331adf7
I'll follow up to this email with the reversion patch we used in
testing. It seems to sort this problem out at least, though now its
blam'ing in ibmveth, so am retesting with yet another patch. This patch
reverts the two patches above and updates the commentry on the Kconfig
entry.
-apw
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Mike Kravetz @ 2006-10-20 14:59 UTC (permalink / raw)
To: Andy Whitcroft
Cc: akpm, Mel Gorman, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Christoph Lameter
In-Reply-To: <4538DACC.5050605@shadowen.org>
On Fri, Oct 20, 2006 at 03:18:52PM +0100, Andy Whitcroft wrote:
> I remember that we used to have code to cope with this in the ppc64
> architecture, indeed I remember reviewing it all that time ago. Looking
> at the current state of the tree it was removed in the two patches below
> in mainline:
> "[PATCH] Remove SPAN_OTHER_NODES config definition"
> "[PATCH] mm: remove arch independent NODES_SPAN_OTHER_NODES"
That was me. Seem to remember some discussion that these were only
needed for DISCONTIGMEM, so I removed them when the DISCONTIGMEM option
for power went away. But, that is clearly NOT the case. Appears that
SPARSEMEM and the old slab code covered up the issue. Sorry about that.
Thanks!
--
Mike
^ permalink raw reply
* Re: CPM2 (MPC8260) SMC problem. Please help.
From: Vitaly Bordug @ 2006-10-20 15:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4536913F.8060801@fabiotec.com>
On Wed, 18 Oct 2006 22:40:31 +0200
Boris Shteinbock <boris@fabiotec.com> wrote:
> Hi ppl.
>
> I have discovered very very odd problem with SMC2 on my 8260 board.
> kernel version is 2.6.17.
>
> The board is 8260 with serial ports on SMC1 and SMC 2 (SMC1 - console)
>
> Now if I use SMC2 for communicating with remote device, ( some protocol)
> I am sending packets and wait for a response.
> However if the packet I send is SMALLER than 5 bytes, SMC goes
> completely crazy.
> write() doesn't return error, but the next read() hangs completely, and the
> process moves to D state and it is impossible to kill it by any means.
> It only happens when consequent writes of smaller than 5 bytes.
> I tried to check the driver, but couldn't find any clues to what goes wrong.
>
> I tried both compatibility and platform-based modes with the same results.
>
> Any help on the issue would be highliy appreciated.
>
>
I think that should be walked along the cpm_uart driver, TX part to see is sending stuff
do not indicate any error in the CPM registers, or at least discover exact track leading to the endless loop.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-20 15:19 UTC (permalink / raw)
To: Andy Whitcroft
Cc: akpm, Mel Gorman, linux-kernel, linuxppc-dev, Anton Blanchard,
Christoph Lameter
In-Reply-To: <4538DACC.5050605@shadowen.org>
On Fri, 2006-20-10 at 15:18 +0100, Andy Whitcroft wrote:
> Paul Mackerras wrote:
> > Christoph Lameter writes:
> >
I got dropped off the CC list somewhere.. :-(
if something is bouncing, let me know,.. otherwise please dont do
that..
> Mel Gorman and I have been poking at this from different ends. Mel from
> the context of this thread and myself trying to fix a machine which was
> exhibiting on 32MB of ram in node 0 and the rest in node 1.
>
> I remember that we used to have code to cope with this in the ppc64
> architecture, indeed I remember reviewing it all that time ago. Looking
> at the current state of the tree it was removed in the two patches below
> in mainline:
> "[PATCH] Remove SPAN_OTHER_NODES config definition"
> "[PATCH] mm: remove arch independent NODES_SPAN_OTHER_NODES"
>
> These commits:
> f62859bb6871c5e4a8e591c60befc8caaf54db8c
> a94b3ab7eab4edcc9b2cb474b188f774c331adf7
>
> I'll follow up to this email with the reversion patch we used in
> testing. It seems to sort this problem out at least, though now its
> blam'ing in ibmveth, so am retesting with yet another patch. This patch
> reverts the two patches above and updates the commentry on the Kconfig
> entry.
I've got a couple LPARs that exhibit the problem, so can verify your
patch once I see it..
-Will
>
> -apw
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Andy Whitcroft @ 2006-10-20 16:00 UTC (permalink / raw)
To: Paul Mackerras
Cc: akpm, Mel Gorman, linux-kernel, linuxppc-dev, Anton Blanchard,
Christoph Lameter
In-Reply-To: <4538DACC.5050605@shadowen.org>
Andy Whitcroft wrote:
> Paul Mackerras wrote:
>> Christoph Lameter writes:
>>
>>> The page allocator must be running and able to serve pages from the boot
>>> node. This fails for some reason and the slab cannot bootstrap. The memory
>>> not available is the first guess. Could you trace the allocation in the
>>> page allocator (__alloc_pages) when the slab attempts to bootstrap and
>>> figure out why exactly the allocation fails?
>> What is happening is that all pages are getting their zone id field in
>> their page->flags set to point to zone for node 1 by memmap_init_zone
>> calling set_page_links (which does set_page_zone). Thus, when those
>> pages get freed by free_all_bootmem_node, they all end up in the zone
>> for node 1.
>>
>> memmap_init_zone is called (as memmap_init, since we don't have
>> __HAVE_ARCH_MEMMAP_INIT defined) from init_currently_empty_zone, which
>> is called from free_area_init_core. Now the thing is that memmap_init
>> and init_currently_empty_zone are called with the node's start PFN and
>> size in pages, *including* holes. On the partition I'm using we have
>> these PFN ranges for the nodes:
>>
>> 1: 0 -> 32768
>> 0: 32768 -> 278528
>> 1: 278528 -> 524288
>>
>> So node 0's start PFN is 32768 and its size is 245760 pages, and so we
>> correctly set pages 32786 to 278527 to be in the zone for node 0.
>> Then for node 1, we have the start PFN is 0 and the size is 524288, so
>> we then go through and set *all* pages of memory to be in the zone for
>> node 1, including the pages which are actually on node 0.
>>
>> That's why we can't allocate any pages on node 0, and the kmem cache
>> bootstrapping blows up.
>>
>> I don't know this code well enough to know what the correct fix is.
>> Clearly memmap_init_zone should only be touching the pages that are
>> actually present in the zone, but I don't know exactly what data
>> structures it should be using to know what those pages are.
>
> Mel Gorman and I have been poking at this from different ends. Mel from
> the context of this thread and myself trying to fix a machine which was
> exhibiting on 32MB of ram in node 0 and the rest in node 1.
>
> I remember that we used to have code to cope with this in the ppc64
> architecture, indeed I remember reviewing it all that time ago. Looking
> at the current state of the tree it was removed in the two patches below
> in mainline:
> "[PATCH] Remove SPAN_OTHER_NODES config definition"
> "[PATCH] mm: remove arch independent NODES_SPAN_OTHER_NODES"
>
> These commits:
> f62859bb6871c5e4a8e591c60befc8caaf54db8c
> a94b3ab7eab4edcc9b2cb474b188f774c331adf7
>
> I'll follow up to this email with the reversion patch we used in
> testing. It seems to sort this problem out at least, though now its
> blam'ing in ibmveth, so am retesting with yet another patch. This patch
> reverts the two patches above and updates the commentry on the Kconfig
> entry.
Ok, I've just gotten a successful boot on this box for the first time in
like 15 git releases. I needed the three patches below:
clameter-fallback_alloc_fix2 -- from earlier in this thread, under the
message ID below:
<Pine.LNX.4.64.0610131515200.28279@schroedinger.engr.sgi.com>
Reintroduce-NODES_SPAN_OTHER_NODES-for-powerpc -- the patch I just
submitted, under the message ID below:
<8a76dfd735e544016c5f04c98617b87d@pinky>
ibmveth-fix-index-increment-calculation -- this patch is already in -mm.
Feel free to take this as an ACK for the patches other than mine.
Acked-by: Andy Whitcroft <apw@shadowen.org>
-apw
^ permalink raw reply
* Re: [PATCH] Reintroduce NODES_SPAN_OTHER_NODES for powerpc
From: Mel Gorman @ 2006-10-20 16:30 UTC (permalink / raw)
To: Andy Whitcroft
Cc: akpm, linux-kernel, linuxppc-dev, Paul Mackerras, Anton Blanchard,
Christoph Lameter
In-Reply-To: <8a76dfd735e544016c5f04c98617b87d@pinky>
On Fri, 20 Oct 2006, Andy Whitcroft wrote:
> Reintroduce NODES_SPAN_OTHER_NODES for powerpc
>
> Revert "[PATCH] Remove SPAN_OTHER_NODES config definition"
> This reverts commit f62859bb6871c5e4a8e591c60befc8caaf54db8c.
> Revert "[PATCH] mm: remove arch independent NODES_SPAN_OTHER_NODES"
> This reverts commit a94b3ab7eab4edcc9b2cb474b188f774c331adf7.
>
> Also update the comments to indicate that this is still required
> and where its used.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Mel Gorman <mel@csn.ul.ie>
^ permalink raw reply
* Selecting the ppc_md.power_save method at boot time
From: Arnd Bergmann @ 2006-10-20 16:40 UTC (permalink / raw)
To: linuxppc-dev, Anthony J Marsala
Anthony was asking me to add support for disabling the cbe_idle
function for cell at boot time, in order to make it easier to
use some debugging tools.
I already intend to move the cbe_idle implementation over to
a simpler power_save method, so these two changes could be
combined by making the power_save function selectable at
boot time.
I could imagine two ways to implement this:
1. Add a boot option to simply disable calling ppc_md->power_save
on all platforms. E.g. powersave=off.
2. Make it possible to have multiple implementations, e.g.
powersave=cbe, powersave=nap, powersave=cede, powersave=off,
powersave=power4, with a per-platform default.
Is anyone interested in the second solution? Otherwise I'd post
a simple patch to just do powersave=off.
Arnd <><
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Andrew Morton @ 2006-10-20 17:09 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Jeff Garzik, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Anton Blanchard, Christoph Lameter
In-Reply-To: <4538F2A2.5040305@shadowen.org>
On Fri, 20 Oct 2006 17:00:34 +0100
Andy Whitcroft <apw@shadowen.org> wrote:
> > I'll follow up to this email with the reversion patch we used in
> > testing. It seems to sort this problem out at least, though now its
> > blam'ing in ibmveth, so am retesting with yet another patch. This patch
> > reverts the two patches above and updates the commentry on the Kconfig
> > entry.
>
> Ok, I've just gotten a successful boot on this box for the first time in
> like 15 git releases. I needed the three patches below:
>
> clameter-fallback_alloc_fix2 -- from earlier in this thread, under the
> message ID below:
> <Pine.LNX.4.64.0610131515200.28279@schroedinger.engr.sgi.com>
That's this:
Here is another fall back fix checking if the slab has already been setup
for this node. MPOL_INTERLEAVE could redirect the allocation.
Index: linux-2.6.19-rc1-mm1/mm/slab.c
===================================================================
--- linux-2.6.19-rc1-mm1.orig/mm/slab.c 2006-10-10 21:47:12.949563383 -0500
+++ linux-2.6.19-rc1-mm1/mm/slab.c 2006-10-13 17:21:31.937863714 -0500
@@ -3158,12 +3158,15 @@ void *fallback_alloc(struct kmem_cache *
struct zone **z;
void *obj = NULL;
- for (z = zonelist->zones; *z && !obj; z++)
+ for (z = zonelist->zones; *z && !obj; z++) {
+ int nid = zone_to_nid(*z);
+
if (zone_idx(*z) <= ZONE_NORMAL &&
- cpuset_zone_allowed(*z, flags))
+ cpuset_zone_allowed(*z, flags) &&
+ cache->nodelists[nid])
obj = __cache_alloc_node(cache,
- flags | __GFP_THISNODE,
- zone_to_nid(*z));
+ flags | __GFP_THISNODE, nid);
+ }
return obj;
}
Christoph, can you please finalise and resend that?
> Reintroduce-NODES_SPAN_OTHER_NODES-for-powerpc -- the patch I just
> submitted, under the message ID below:
> <8a76dfd735e544016c5f04c98617b87d@pinky>
OK, I got that.
> ibmveth-fix-index-increment-calculation -- this patch is already in -mm.
Normally a Jeff thing, but small-and-simple. I'll send that in to Linus
today.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-20 17:13 UTC (permalink / raw)
To: Andy Whitcroft
Cc: akpm, Mel Gorman, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Christoph Lameter
In-Reply-To: <4538F2A2.5040305@shadowen.org>
On Fri, 2006-20-10 at 17:00 +0100, Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Paul Mackerras wrote:
> >> Christoph Lameter writes:
> Ok, I've just gotten a successful boot on this box for the first time in
> like 15 git releases. I needed the three patches below:
>
> clameter-fallback_alloc_fix2 -- from earlier in this thread, under the
> message ID below:
> <Pine.LNX.4.64.0610131515200.28279@schroedinger.engr.sgi.com>
>
> Reintroduce-NODES_SPAN_OTHER_NODES-for-powerpc -- the patch I just
> submitted, under the message ID below:
> <8a76dfd735e544016c5f04c98617b87d@pinky>
>
> ibmveth-fix-index-increment-calculation -- this patch is already in -mm.
>
> Feel free to take this as an ACK for the patches other than mine.
>
> Acked-by: Andy Whitcroft <apw@shadowen.org>
>
> -apw
I've applied these three blobs to the linux-2.6.git tree and verified
that it does fix the problem.
And a "Thanks!" to Christoph for being responsive.. even when the
problem wasnt introduced by him. :)
Acked-by: Will Schmidt <will_schmidt@vnet.ibm.com>
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-20 17:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, Anton Blanchard, linux-kernel
In-Reply-To: <17720.30804.180390.197567@cargo.ozlabs.ibm.com>
On Fri, 20 Oct 2006, Paul Mackerras wrote:
> What is happening is that all pages are getting their zone id field in
> their page->flags set to point to zone for node 1 by memmap_init_zone
> calling set_page_links (which does set_page_zone). Thus, when those
> pages get freed by free_all_bootmem_node, they all end up in the zone
> for node 1.
Ok. So no memory on node 0? Then my patch to reenable fallback in the slab
should have worked but it did not. Could you retest with the patch that
Will tried? If that is not working the comment out the 3 lines with
__GFP_THISNODE in get_page_from_freelist. That will reenable fallback
globally. If that does not work then I doubt that this is my issue.
> memmap_init_zone is called (as memmap_init, since we don't have
> __HAVE_ARCH_MEMMAP_INIT defined) from init_currently_empty_zone, which
> is called from free_area_init_core. Now the thing is that memmap_init
> and init_currently_empty_zone are called with the node's start PFN and
> size in pages, *including* holes. On the partition I'm using we have
> these PFN ranges for the nodes:
>
> 1: 0 -> 32768
> 0: 32768 -> 278528
> 1: 278528 -> 524288
>
> So node 0's start PFN is 32768 and its size is 245760 pages, and so we
> correctly set pages 32786 to 278527 to be in the zone for node 0.
> Then for node 1, we have the start PFN is 0 and the size is 524288, so
> we then go through and set *all* pages of memory to be in the zone for
> node 1, including the pages which are actually on node 0.
I do not get it. You first mark all pages on node 0 then we run the bootup
code and later we shift those pages into node 0? So the slab bootstrap is
running when all pages are marked as being part of node 1 then later we
switch those pages under it to node 0?
> I don't know this code well enough to know what the correct fix is.
> Clearly memmap_init_zone should only be touching the pages that are
> actually present in the zone, but I don't know exactly what data
> structures it should be using to know what those pages are.
The fix that I posted yesterday should have reenabled fallback in the
slab during bootstrap and should have made the system work. Here it is
again:
Index: linux-2.6.19-rc2-mm1/mm/slab.c
===================================================================
--- linux-2.6.19-rc2-mm1.orig/mm/slab.c 2006-10-19 11:54:24.000000000 -0500
+++ linux-2.6.19-rc2-mm1/mm/slab.c 2006-10-19 16:32:09.454825851 -0500
@@ -1589,7 +1589,10 @@ static void *kmem_getpages(struct kmem_c
* the needed fallback ourselves since we want to serve from our
* per node object lists first for other nodes.
*/
- flags |= cachep->gfpflags | GFP_THISNODE;
+ if (g_cpucache_up != FULL)
+ flags |= cachep->gfpflags & ~__GFP_THISNODE;
+ else
+ flags |= cachep->gfpflags | GFP_THISNODE;
page = alloc_pages_node(nodeid, flags, cachep->gfporder);
if (!page)
^ permalink raw reply
* Re: [PATCH] Slight refactor of interrupt mapping for FSL parts (take 3)
From: Andy Fleming @ 2006-10-20 17:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <94A9DAA6-37CD-48F0-A793-70274E0B38FA@kernel.crashing.org>
On Oct 20, 2006, at 00:44, Kumar Gala wrote:
>
> On Oct 19, 2006, at 7:52 PM, Andy Fleming wrote:
>
>> * Cleaned up interrupt mapping a little by adding a helper
>> function which parses the irq out of the device-tree, and puts
>> it into a resource.
>
> Split this patch in two. One for the mapping cleanup and one for
> the PHY changes.
I don't want to be a whiner, here, but isn't that more effort than
the benefit it gives? I mean, I'll do it if you really want, but I'm
trying to get to work on the *next* patch.
>
>> * Changed the arch/ppc platform files to specify PHY_POLL, instead
>> of -1
>
> This seems like a confusing way to indicate lack of interrupt.
> Can't remember but if in my system all the PHYs are just polled do
> I even have to setup the data structure?
It is precisely the way to indicate lack of interrupt. Here are the
options:
1) PHY is not used.
2) PHY is polled by PHY lib
3) PHY lib handles interrupts, does not poll
4) PHY Lib does not handle reflecting device state changes
#4 Is indicated by setting phydev->irq to PHY_IGNORE_INTERRUPT
#3 Is indicated by phydev->irq containing an actual irq number
#2 is indicated by setting phydev->irq to PHY_POLL
#1 means it doesn't matter what the irq is set to
So yes, you have to set up the data structure. If you set it to -1,
you have only been *coincidentally* getting PHY_POLL (because
PHY_POLL is -1). That's a bad idea, because PHY_POLL might change in
the future.
Andy
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-20 17:46 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeff Garzik, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Anton Blanchard
In-Reply-To: <20061020100904.ed1fa0af.akpm@osdl.org>
Here is the patch:
Slab: Do not fallback to nodes that have not been bootstrapped yet
The zonelist may contain zones of nodes that have not been bootstrapped
and we will oops if we try to allocate from those zones. So check if the
node information for the slab and the node have been setup before
attempting an allocation. If it has not been setup then skip that zone.
Usually we will not encounter this situation since the slab bootstrap
code avoids falling back before we have setup the respective nodes but we
seem to have a special needs for pppc.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.19-rc2-mm1/mm/slab.c
===================================================================
--- linux-2.6.19-rc2-mm1.orig/mm/slab.c 2006-10-20 12:39:02.000000000 -0500
+++ linux-2.6.19-rc2-mm1/mm/slab.c 2006-10-20 12:41:04.137684581 -0500
@@ -3160,12 +3160,15 @@ void *fallback_alloc(struct kmem_cache *
struct zone **z;
void *obj = NULL;
- for (z = zonelist->zones; *z && !obj; z++)
+ for (z = zonelist->zones; *z && !obj; z++) {
+ int nid = zone_to_nid(*z);
+
if (zone_idx(*z) <= ZONE_NORMAL &&
- cpuset_zone_allowed(*z, flags))
+ cpuset_zone_allowed(*z, flags) &&
+ cache->nodelists[nid])
obj = __cache_alloc_node(cache,
- flags | __GFP_THISNODE,
- zone_to_nid(*z));
+ flags | __GFP_THISNODE, nid);
+ }
return obj;
}
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Andy Whitcroft @ 2006-10-20 18:07 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrew Morton, Jeff Garzik, Mel Gorman, linux-kernel,
linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <Pine.LNX.4.64.0610201044570.16161@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> Here is the patch:
>
> Slab: Do not fallback to nodes that have not been bootstrapped yet
>
> The zonelist may contain zones of nodes that have not been bootstrapped
> and we will oops if we try to allocate from those zones. So check if the
> node information for the slab and the node have been setup before
> attempting an allocation. If it has not been setup then skip that zone.
>
> Usually we will not encounter this situation since the slab bootstrap
> code avoids falling back before we have setup the respective nodes but we
> seem to have a special needs for pppc.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> Index: linux-2.6.19-rc2-mm1/mm/slab.c
> ===================================================================
> --- linux-2.6.19-rc2-mm1.orig/mm/slab.c 2006-10-20 12:39:02.000000000 -0500
> +++ linux-2.6.19-rc2-mm1/mm/slab.c 2006-10-20 12:41:04.137684581 -0500
> @@ -3160,12 +3160,15 @@ void *fallback_alloc(struct kmem_cache *
> struct zone **z;
> void *obj = NULL;
>
> - for (z = zonelist->zones; *z && !obj; z++)
> + for (z = zonelist->zones; *z && !obj; z++) {
> + int nid = zone_to_nid(*z);
> +
> if (zone_idx(*z) <= ZONE_NORMAL &&
> - cpuset_zone_allowed(*z, flags))
> + cpuset_zone_allowed(*z, flags) &&
> + cache->nodelists[nid])
> obj = __cache_alloc_node(cache,
> - flags | __GFP_THISNODE,
> - zone_to_nid(*z));
> + flags | __GFP_THISNODE, nid);
> + }
> return obj;
> }
>
>
Applied this and the previous version, diff says they are identicle, so
my previous testing applies.
Acked-by: Andy Whitcroft <apw@shadowen.org>
-apw
^ permalink raw reply
* Re: Build openssl in ELDK 3.1.1
From: Wolfgang Denk @ 2006-10-20 18:48 UTC (permalink / raw)
To: tran vanle; +Cc: linuxppc-embedded
In-Reply-To: <20061020124651.41291.qmail@web33003.mail.mud.yahoo.com>
In message <20061020124651.41291.qmail@web33003.mail.mud.yahoo.com> you wrote:
>
...
> - Go to <project>/usr/src/denx/SPECS and run
> ppc_8xx-rpmbuild openssl.spec
> Then I receive in <project>/usr/src/denx/openssl-0.9.7f/ libssl.so.0.9.7 and openssl in <project>/usr/src/denx/openssl-0.9.7f/apps
>
> That's OK
Good.
> But I don't know Was command openssl added in image in <project>/ppc_8xx/images? If no how i can do it ?
It does not modify the images files at all. why should it?
> I also want to rebuild kernel but i only receive vmlinux in <project>/ppc_8xx/usr/src/linux/ Was vmlinux added in image in <project>/ppc_8xx/images? If no how i can do it ?
> If I want to build an application but not in ftp://ftp.sunet.se/pub/Linux/distributions/eldk/3.1.1/ppc-linux-x86/sources/target/SRPMS/
> how can I do?
May I suggest you start reading the documentation? It explains all
these things. See http://www.denx.de/wiki/DULG/Manual
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.
^ permalink raw reply
* Re: [PATCH] Xilinx UART Lite 2.6.18 driver
From: Peter Korsgaard @ 2006-10-20 19:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <609d5c8e0610151648x41b0c49cj4d0cda0e3b5bf1e@mail.gmail.com>
>>>>> "David" == David Bolcsfoldi <dbolcsfoldi@gmail.com> writes:
Hi - sorry for the slow response, this week has been crazy :/
>> Could you make it relative to my driver so the changes are easier
>> to see?
David> Done and done. Look at the end of this e-mail.
Thanks.
>> The PPC is big endian - Did you remember to add 3 to your base
>> address?
David> I don't see how reading a single byte would be affected by the
David> endianess of the platform. I think it has more to do with the
David> fact that the status and control registers are both 4 byte wide
David> and when you add 3 to your offset you read only the LSB. I also
David> suspect that the RX and TX registers are 4 byte wide too, even
David> though this is not stated explicitly in the documentation I
David> think it would be prudent to access these two as 4-byte wide
David> registers as well.
Well, the end result is the same. I guess the only reason for the
4-byte spacing between the registers is the 32bit width of the OPB
bus. The logical contents of the registers are all 8bit or less, and
sticking to 8bit access makes things easier (no endianness issues, no
issues with alternative implementations with another physical width).
E.G. the driver might be useful for other architectures
(E.G. microblaze) and for other implementations of the uartlite. We
are using another uart with a uartlite compatible interface in a
non-virtex fpga.
The exact same thing is done my 8250.c for the 16550 opb core.
David> I guess it is OK to read and write bytes as long as the
David> bitflags don't change location. But I believe it is stated in
David> the documentation that the OPB UART Lite device is a big endian
David> device, in my opinion it would better to honor this and do big
David> endian access of register width.
The driver has to be updated If the hardware interface changes no
matter what. The documentation clearly states (bottom of page 3) that
you can access the registers using 8, 16 or 32bit accesses.
I'll test and take a closer look at your patch when I have access to
hw again on Monday.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Selecting the ppc_md.power_save method at boot time
From: Benjamin Herrenschmidt @ 2006-10-20 22:05 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Anthony J Marsala
In-Reply-To: <200610201840.14389.arnd.bergmann@de.ibm.com>
> Is anyone interested in the second solution? Otherwise I'd post
> a simple patch to just do powersave=off.
Simple solution sounds good to me.
Ben.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Paul Mackerras @ 2006-10-20 22:54 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, Anton Blanchard, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610201029190.16161@schroedinger.engr.sgi.com>
Christoph Lameter writes:
> I do not get it. You first mark all pages on node 0 then we run the bootup
> code and later we shift those pages into node 0? So the slab bootstrap is
> running when all pages are marked as being part of node 1 then later we
> switch those pages under it to node 0?
No, the bootmem code correctly marks all the pages in node 0 as being
in node 0. Then it goes through and marks *all* pages as being in
node 1, because it marks all pages between the first and last pages in
the node as being in the node. The first page in node 1 is before all
the pages in node 0, and the last page in node 1 is after all the
pages in node 0.
So we end up with the system thinking all the memory is in node 1,
although in fact half the memory is in node 0.
Anyway, it looks like this problem wasn't introduced by your patches,
and is solved by the patch Andy Whitcroft posted, so thanks for your
assistance with this.
Paul.
^ permalink raw reply
* Re: Selecting the ppc_md.power_save method at boot time
From: Olof Johansson @ 2006-10-20 23:22 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Anthony J Marsala
In-Reply-To: <200610201840.14389.arnd.bergmann@de.ibm.com>
On Fri, 20 Oct 2006 18:40:13 +0200 Arnd Bergmann <arnd.bergmann@de.ibm.com> wrote:
> 2. Make it possible to have multiple implementations, e.g.
> powersave=cbe, powersave=nap, powersave=cede, powersave=off,
> powersave=power4, with a per-platform default.
Doesn't make a whole lot of sense, since there's no way to use the
power4 powersave on a cell system -- specifying it on the command line
won't do much good.
> Is anyone interested in the second solution? Otherwise I'd post
> a simple patch to just do powersave=off.
Gobal powersave=off sounds good, specific platforms could implement
others as needed.
-Olof
^ permalink raw reply
* Re: [Cbe-oss-dev] Correct way to format spufs file output.
From: Benjamin Herrenschmidt @ 2006-10-21 1:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, Dwayne Grant McConnell, cbe-oss-dev, linux-kernel
In-Reply-To: <200610201638.52404.arnd@arndb.de>
On Fri, 2006-10-20 at 16:38 +0200, Arnd Bergmann wrote:
> On Friday 20 October 2006 15:54, Dwayne Grant McConnell wrote:
> > I think %0xllx is the way to go. I would even advocate changing
> > signal1_type and signal2_type unless it is actually too dangerous.
>
> There is absolutely no reason why these should be hexadecimal, they
> are basically implementing a bool.
>
> > Is there even a case where changing from %llu to %0xllx would break things?
> > Perhaps with the combination of a old library with a new kernel?
>
> Right, a library or some script that has been written assuming there
> is no leading 0x.
We might still want to "broadcast" that we might change that and see how
much gets broken. It's very likely that nothing will.
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox