* Re: Linux v2.6.18-rc5
From: Yves-Alexis Perez @ 2006-08-29 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060829130629.GW11309@localdomain>
On Tue, 2006-08-29 at 08:06 -0500, Nathan Lynch wrote:
> Sorry about that, does this (a partial revert of the change) fix it
> for you?
I tried 2.6.18-rc5 on my powerbook g4 (5,6) and indeed I had lots of
deadlocks, it was quite unusable. I've tried this patch and it seems to
fix the problem. (up for half an our without problems, I guess)
--
Yves-Alexis
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Olaf Hering @ 2006-08-29 15:52 UTC (permalink / raw)
To: Nathan Lynch
Cc: linuxppc-dev, Linus Torvalds, Paul Mackerras,
Linux Kernel Mailing List
In-Reply-To: <20060829130629.GW11309@localdomain>
On Tue, Aug 29, Nathan Lynch wrote:
> Hi Olaf-
>
> Olaf Hering wrote:
> > On Sun, Aug 27, Linus Torvalds wrote:
> >
> > > Pls test it out, and please remind all the appropriate people about any
> > > regressions you find (including any found earlier if they haven't been
> > > addressed yet).
> >
> > > Nathan Lynch:
> > > [POWERPC] Fix gettimeofday inaccuracies
> >
> > Tested on B&W G3, iBook1 and a G4/466.
> > This patch causes deadlocks on ppc32, but not on ppc64. Have to verify
> > it on a vanilla kernel, but I'm sure there are no funky patches in
> > openSuSE.
> >
> > https://bugzilla.novell.com/show_bug.cgi?id=202146
>
> Sorry about that, does this (a partial revert of the change) fix it
> for you?
Yes, it works ok with this change.
^ permalink raw reply
* RE: atomic operations in user space
From: Esben Nielsen @ 2006-08-29 16:05 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-embedded
In-Reply-To: <a0bc9bf80608290637q165d1f54x2d80e771671c894f@mail.gmail.com>
On Tue, 29 Aug 2006, Li Yang wrote:
>> This is exactly how it is supposed to work! That's why there is a loop
>> in the atomic increment - you check if you still had the reservation
>> after the transaction by checking the result from the stwcx, and if not,
>> retry.
>
> I surely know all the theories you mentioned clearly. But please do
> look at the case I gave. Correct me if I missed anything. Thanks
>
> All the lwarx and stwcx operate on the same address.
>
>> Task A Task B
>> lwarx
> // Get RESERVATION
>> ......
>> lwarx
>> stwcx
>
> // RESERVATION cleared
>>
>> .....
>> .....
>> lwarx
>
> // Get RESERVATION again
Now we do a task switch involving atomic operations, and thus an
reservation on another address.
>> stwcx
>
> //Note here: RESERVATION is valid, address is the same.
> So the result is commited, no retry for task A
>
>> .....
>> stwcx
> //RESERVATION is cleared, retry atomic op for task B
>
> Please be noted that reservation is only identified by reservation bit
> and address operated on. So different lwarx's on the same address,
> may be considered as the same reservation.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Ralf Baechle @ 2006-08-29 16:17 UTC (permalink / raw)
To: linux-ia64, linux-mips, linuxppc-embedded, paulkf, takata,
linux-kernel
In-Reply-To: <20060828085244.GA13544@flint.arm.linux.org.uk>
On Mon, Aug 28, 2006 at 09:52:44AM +0100, Russell King wrote:
> asm/serial.h is supposed to contain the definitions for the architecture
> specific 8250 ports for the 8250 driver. It may also define BASE_BAUD,
> but this is the base baud for the architecture specific ports _only_.
>
> Therefore, nothing other than the 8250 driver should be including this
> header file. In order to move towards this goal, here is a patch which
> removes some of the more obvious incorrect includes of the file.
>
> MIPS and PPC has rather a lot of stuff in asm/serial.h, some of it looks
> related to non-8250 ports. Hence, it's not trivial to conclude that
> these includes are indeed unnecessary, so can mips and ppc people please
> test this patch carefully.
The MIPS bits were just unused leftovers from the days when the arch
code did did register serials & consoles. So for the MIPS bits:
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* Re: atomic operations in user space
From: Li Yang @ 2006-08-29 17:00 UTC (permalink / raw)
To: Esben Nielsen; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0608291804260.22067@frodo.shire>
On 8/30/06, Esben Nielsen <nielsen.esben@gogglemail.com> wrote:
>
>
> On Tue, 29 Aug 2006, Li Yang wrote:
>
> >> This is exactly how it is supposed to work! That's why there is a loop
> >> in the atomic increment - you check if you still had the reservation
> >> after the transaction by checking the result from the stwcx, and if not,
> >> retry.
> >
> > I surely know all the theories you mentioned clearly. But please do
> > look at the case I gave. Correct me if I missed anything. Thanks
> >
> > All the lwarx and stwcx operate on the same address.
> >
> >> Task A Task B
> >> lwarx
> > // Get RESERVATION
> >> ......
> >> lwarx
> >> stwcx
> >
> > // RESERVATION cleared
> >>
> >> .....
> >> .....
> >> lwarx
> >
> > // Get RESERVATION again
>
> Now we do a task switch involving atomic operations, and thus an
> reservation on another address.
>
This makes sense for me.
^ permalink raw reply
* undefined reference to pci_io_base
From: Geoff Levand @ 2006-08-29 17:34 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to understand the intended design of the inb()
and outb() macros in asm-powerpc/io.h. They are causing
me some grief when I set CONFIG_PCI=n:
drivers/built-in.o: undefined reference to `pci_io_base'
This is coming from drivers/char/mem.c, which is always
built in, and is referencing pci_io_base through inb()
and outb().
Anyway, it seems asm-powerpc/io.h has two sets of io macros,
one set for iSeries, and one generic set for everything else.
The problem arises because the generic macros just use the eeh
macros in eeh.h, which in turn, directly use pci_io_base.
I can think of three solutions to this that work for me, but
I'm not sure which, if any, would be the most proper. One
would be to just have this in io.h:
#if defined(CONFI_PCI)
extern unsigned long pci_io_base;
#else
#define pci_io_base 0
#endif
Another would be to have this in some file that is always built
in, like setup-common.c:
#if !defined(CONFI_PCI)
unsigned long pci_io_base;
EXPORT_SYMBOL(pci_io_base);
#endif
A third would be to have another set of io macros in io.h that
are used when CONFIG_PCI=n.
Comments welcome.
-Geoff
^ permalink raw reply
* Re: MPC85xx u-boot definition
From: Becky Bruce @ 2006-08-29 20:01 UTC (permalink / raw)
To: enorm; +Cc: linuxppc-embedded
In-Reply-To: <017001c6cb0e$1b81f440$a309a8c0@SZD823>
On Aug 28, 2006, at 8:54 PM, enorm wrote:
> Hi,
> Some naive questions about u-boot for MPC85xx, the definition of
> some macro in ppc_asm.tmpl. Can anyone there explain them to me
> please?
> 1) In GET_GOT(x) what does " lwz r0,0b-1b(r14) ;" do? what does
> "0b-1b" stands for, or the meaning of the syntax? why move the content
> of the memory pointing by LR?
0b and 1b refer to the labels 0: and 1:. The "b" means find the
first instance of that label backward from the reference point.
> #define GET_GOT \
> bl 1f ; \
> .text 2 ; \
> 0: .long .LCTOC1-1f ; \
> .text ; \
> 1: mflr r14 ; \
> lwz r0,0b-1b(r14) ; \
> add r14,r0,r14 ;
One thing to note when looking at this code that might be confusing:
The .text 2 directive says that the code after it should be put in
subsection "2" of the .text section. The default is 0 if this is not
specified. When you build, this code is no longer sequential -
the .text 2 stuff will end up somewhere in the executable *after* the
normal .text.
To illustrate, here's what you get if you compile just this code and
dump it (I just #defined .LCTOC1 to be 0x1000 so it would compile):
00000000 <.text>:
0: 48 00 00 05 bl 0x4
4: 7d c8 02 a6 mflr r14 << label 1: points here
8: 80 0e 00 0c lwz r0,12(r14)
c: 7d c0 72 14 add r14,r0,r14
10: 00 00 10 0c .long 0x100c << label 0: points here
And what it does, line by line:
bl 0x4 /* LR now contains actual address we're running at */
mflr r14 /* copy LR into r14 so we can use it */
lwz r0,12(r14) /* Get the linker-generated value .LCTOC1-1f */
add r14,r0,r14 /* Correct that value for where we're really
running */
The whole point here is to be somewhat position-independent - we're
calculating where things are rather than using the linker-generated
values because we don't necessarily want to assume we're loaded and
running at the link address.
>
> 2) In START_GOT, any special meaning for the value 32768?
> >> .LCTOC1=.+32768
So, I don't have the code for this, but if I had to guess..... That
value is equivalent to 0x8000 hex. The GOT is usually accessed using
a symbol that's in the middle of the GOT so you can use positive and
negative indexes from that point to access data in the GOT. The max
size of an immediate value in ppc asm is 16 bits. So this is the
halfway point that gives you maximum access with a 16-bit immediate.
> 3) Syntax for GOT_ENTRY(NAME) and GOT(NAME), like . - .LCTOC1
> (line 57) and .text 2 (line 50)
> could not find then in the GNU douments (ld, as, gcc, glibc etc).
Most everything you need is in the gas manual at http://www.gnu.org/
software/binutils/manual/gas-2.9.1/html_mono/as.html. and in the C
preprocessor documentation at http://gcc.gnu.org/onlinedocs/
gcc-2.95.3/cpp.html#SEC_Top. If you're really interested in
understanding this stuff, you should probably also dig up and read
the PowerPC Processor ABI Supplement document as well.
Cheers,
B
^ permalink raw reply
* LinuxThreads && MontaVista Pro 3.1
From: Eric Nuckols @ 2006-08-29 20:13 UTC (permalink / raw)
To: linuxppc-embedded
LinuxThreads && MontaVista Pro 3.1
our setup:
HW:
PrPMC800 MCP7410 board
SW:
MontaVista Pro 3.1
host - i686
target ppc_74xx-
kernel: 2.4.20_mvl31
glibc 2.3.2
LinuxThreads 0.10
GCC 3.3.1
After all the research, it seems the problem is LinuxThreads just has all
sorts of bugs between mishandling signals and deadlocking.
I'm dealing with a tight schedule and lots of code that works great until a
LinuxThreads threadmanager barfs.
I'm in one of those classic positions where I inherited a lot of code that
assumed pthreads worked as described, but have found otherwise.
There's no time or budget to rewrite the entire project to circumvent
threading.
I've built a newer cross-compiler using NPTL, and when compiling with it
(statically of course), I have the __libc_fork assertion problem due to some
botched syscalls.
Likewise, I can't easily modify my kernel for that workaround, because I
will continue to have to use the precompiled userland binaries in my system
that rely on the old glibc libs with LinuxThreads,
compiled in. When it comes to the userland apps that MontaVista supplies,
they don't provide the source and configuration for all the packages (at
least not with the CDs I have), and even if they did, I would probably
require more time than I have to get them all built as needed.
So, my questions to the helpful people on this list are:
1. Does anybody know if MontaVista has fixed these issues in their newer
releases/patches of Pro 3.1 or Pro 4.0? in other words,
would I be spending the company's money wisely to go back to MontaVista
for upgrades and service?
2. If the answer to #1 is NO, has anybody else out there come across this
same type of issue and found a decent solution?
// as for workarounds, I've blocked basically all signals in all threads,
created separate threads to wait on blocked signals, removed all the
pthread_mutex_lock()
calls, and when I debug, I find that ususally I'm deadlocked in some form of
timed_wait() or some other pthread related lockable/blockable call deep
inside another system call
such as syslog for example.
Thanks,
Eric Nuckols
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Linas Vepstas @ 2006-08-29 20:28 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44F47ABE.7080602@am.sony.com>
On Tue, Aug 29, 2006 at 10:34:54AM -0700, Geoff Levand wrote:
> I'm trying to understand the intended design of the inb()
> and outb() macros in asm-powerpc/io.h. They are causing
> me some grief when I set CONFIG_PCI=n:
>
> drivers/built-in.o: undefined reference to `pci_io_base'
>
> This is coming from drivers/char/mem.c, which is always
> built in, and is referencing pci_io_base through inb()
> and outb().
>
> Anyway, it seems asm-powerpc/io.h has two sets of io macros,
> one set for iSeries, and one generic set for everything else.
> The problem arises because the generic macros just use the eeh
> macros in eeh.h, which in turn, directly use pci_io_base.
>
> I can think of three solutions to this that work for me, but
> I'm not sure which, if any, would be the most proper. One
> would be to just have this in io.h:
>
> #if defined(CONFI_PCI)
> extern unsigned long pci_io_base;
> #else
> #define pci_io_base 0
> #endif
This makes the most sense to me; it compiles to something nice.
> Another would be to have this in some file that is always built
> in, like setup-common.c:
>
> #if !defined(CONFI_PCI)
> unsigned long pci_io_base;
> EXPORT_SYMBOL(pci_io_base);
> #endif
This compiles to something ugly and pointless ...
> A third would be to have another set of io macros in io.h that
> are used when CONFIG_PCI=n.
I'm not sure that yet-another set of macros improves readabily.
Those macros are already fairly byzantine in thier inter-connections.
--linas
^ permalink raw reply
* Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
From: Marcus Comstedt @ 2006-08-29 21:04 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20060829150759.269420@gmx.net>
"Gerhard Pircher" <gerhard_pircher@gmx.net> writes:
> Hi Marcus,
>
> I guess this message should also be forwarded to linux-usb-devel@lists.sourceforge.net. I hope the developers there can make some comments.
>
> Gerhard
Well, I figured the first thing to do would be to reach a consensus
here on whether or not atomic_t:s in DMA memory should be ruled as
unallowed. Judging from the massive silence, there doesn't seem to be
any strong opinions either way though...
// Marcus
^ permalink raw reply
* Help for building linux 2.6.15
From: wei.li4 @ 2006-08-29 21:11 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am working on ELDK 4.0 package with my evaluation board: A&M MPC875,
after configuration for my board, and do 'make zImage', I got the
following errors:
CC arch/ppc/syslib/m8xx_setup.o
arch/ppc/syslib/m8xx_setup.c:56: error: 'bd_t' undeclared here (not in
a function)
arch/ppc/syslib/m8xx_setup.c:62: error: parse error before '*' token
arch/ppc/syslib/m8xx_setup.c:62: warning: function declaration isn't a
prototype
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_calibrate_decr':
arch/ppc/syslib/m8xx_setup.c:144: error: 'binfo' undeclared (first use
in this function)
arch/ppc/syslib/m8xx_setup.c:144: error: (Each undeclared identifier is
reported only once
arch/ppc/syslib/m8xx_setup.c:144: error: for each function it appears in.)
arch/ppc/syslib/m8xx_setup.c:144: error: parse error before ')' token
arch/ppc/syslib/m8xx_setup.c:148: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_set_rtc_time':
arch/ppc/syslib/m8xx_setup.c:216: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_get_rtc_time':
arch/ppc/syslib/m8xx_setup.c:226: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_restart':
arch/ppc/syslib/m8xx_setup.c:235: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_show_percpuinfo':
arch/ppc/syslib/m8xx_setup.c:262: error: 'bp' undeclared (first use in
this function)
arch/ppc/syslib/m8xx_setup.c:264: error: parse error before ')' token
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_find_end_of_memory':
arch/ppc/syslib/m8xx_setup.c:327: error: 'binfo' undeclared (first use
in this function)
arch/ppc/syslib/m8xx_setup.c:328: warning: ISO C90 forbids mixed
declarations and code
arch/ppc/syslib/m8xx_setup.c:330: error: parse error before ')' token
arch/ppc/syslib/m8xx_setup.c:328: warning: unused variable '__res'
arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_map_io':
arch/ppc/syslib/m8xx_setup.c:344: error: 'IMAP_ADDR' undeclared (first
use in this function)
arch/ppc/syslib/m8xx_setup.c:344: error: 'IMAP_SIZE' undeclared (first
use in this function)
make[1]: *** [arch/ppc/syslib/m8xx_setup.o] Error 1
Can anyone help me? Thanks.
^ permalink raw reply
* Re: powerpc virq: new routine virq_to_hw
From: Benjamin Herrenschmidt @ 2006-08-29 22:36 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44F305AA.5020101@am.sony.com>
On Mon, 2006-08-28 at 08:03 -0700, Geoff Levand wrote:
> Benjamin Herrenschmidt wrote:
> > I'd much prefer:
> >
> > static inline irq_hw_number_t virq_to_hw (unsigned int virq)
> > {
> > return irq_map[virq].hwirq;
> > }
>
> Here is an updated version.
>
> -Geoff
>
>
> This adds an accessor routine virq_to_hw() to the
> virq routines which hides the implementation details
> of the virq to hwirq map.
>
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Index: cell--common--4/include/asm-powerpc/irq.h
> ===================================================================
> --- cell--common--4.orig/include/asm-powerpc/irq.h
> +++ cell--common--4/include/asm-powerpc/irq.h
> @@ -136,6 +136,10 @@
>
> extern struct irq_map_entry irq_map[NR_IRQS];
>
> +static inline irq_hw_number_t virq_to_hw(unsigned int virq)
> +{
> + return irq_map[virq].hwirq;
> +}
>
> /**
> * irq_alloc_host - Allocate a new irq_host data structure
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Benjamin Herrenschmidt @ 2006-08-29 22:38 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20060829202831.GB27372@austin.ibm.com>
> > #if defined(CONFI_PCI)
> > extern unsigned long pci_io_base;
> > #else
> > #define pci_io_base 0
> > #endif
>
> This makes the most sense to me; it compiles to something nice.
Agreed.
Ben.
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Paul Mackerras @ 2006-08-29 22:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44F47ABE.7080602@am.sony.com>
Geoff Levand writes:
> I'm trying to understand the intended design of the inb()
> and outb() macros in asm-powerpc/io.h. They are causing
> me some grief when I set CONFIG_PCI=n:
>
> drivers/built-in.o: undefined reference to `pci_io_base'
>
> This is coming from drivers/char/mem.c, which is always
> built in, and is referencing pci_io_base through inb()
> and outb().
Hmmm. inb and outb are designed for accessing PCI I/O space. I guess
we could turn them into BUG() when CONFIG_PCI=n.
Paul.
^ permalink raw reply
* [PATCH] powerpc: Fix MPIC sense codes in doc
From: Benjamin Herrenschmidt @ 2006-08-29 22:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The booting-without-of.txt had incorrect definition for the sense codes
for an OpenPIC controller
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/Documentation/powerpc/booting-without-of.txt
===================================================================
--- linux-work.orig/Documentation/powerpc/booting-without-of.txt 2006-08-30 08:51:19.000000000 +1000
+++ linux-work/Documentation/powerpc/booting-without-of.txt 2006-08-30 08:56:17.000000000 +1000
@@ -1136,10 +1136,10 @@
Devices connected to openPIC-compatible controllers should encode
sense and polarity as follows:
- 0 = high to low edge sensitive type enabled
+ 0 = low to high edge sensitive type enabled
1 = active low level sensitive type enabled
- 2 = low to high edge sensitive type enabled
- 3 = active high level sensitive type enabled
+ 2 = active high level sensitive type enabled
+ 3 = high to low edge sensitive type enabled
ISA PIC interrupt controllers should adhere to the ISA PIC
encodings listed below:
^ permalink raw reply
* libnuma interleaving oddness
From: Nishanth Aravamudan @ 2006-08-29 23:02 UTC (permalink / raw)
To: lameter, ak; +Cc: linux-mm, lnxninja, linuxppc-dev
Hi,
While trying to add NUMA-awareness to libhugetlbfs' morecore
functionality (hugepage-backed malloc), I ran into an issue on a
ppc64-box with 8 memory nodes, running SLES10. I am using two functions
from libnuma: numa_available() and numa_interleave_memory(). When I ask
numa_interleave_memory() to interleave over all nodes (numa_all_nodes is
the nodemask from libnuma), it exhausts node 0, then moves to node 1,
then node 2, etc, until the allocations are satisfied. If I custom
generate a nodemask, such that bits 1 through 7 are set, but bit 0 is
not, then I get proper interleaving, where the first hugepage is on node
1, the second is on node 2, etc. Similarly, if I set bits 0 through 6 in
a custom nodemask, interleaving works across the requested 7 nodes. But
it has yet to work across all 8.
I don't know if this is a libnuma bug (I extracted out the code from
libnuma, it looked sane; and even reimplemented it in libhugetlbfs for
testing purposes, but got the same results) or a NUMA kernel bug (mbind
is some hairy code...) or a ppc64 bug or maybe not a bug at all.
Regardless, I'm getting somewhat inconsistent behavior. I can provide
more debugging output, or whatever is requested, but I wasn't sure what
to include. I'm hoping someone has heard of or seen something similar?
The test application I'm using makes some mallopt calls then justs
mallocs large chunks in a loop (4096 * 100 bytes). libhugetlbfs is
LD_PRELOAD'd so that we can override malloc.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 4/4] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts
From: Kim Phillips @ 2006-08-29 23:13 UTC (permalink / raw)
To: linuxppc-dev
Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
Amended version of "[PATCH 4/4] Add MPC8349E MDS device tree source file to arch/powerpc/boot/dts": PCI senses are now correctly corrected to 8 (level low).
arch/powerpc/boot/dts/mpc8349emds.dts | 328 +++++++++++++++++++++++++++++++++
1 files changed, 328 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emds.dts b/arch/powerpc/boot/dts/mpc8349emds.dts
new file mode 100644
index 0000000..12f5dbf
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8349emds.dts
@@ -0,0 +1,328 @@
+/*
+ * MPC8349E MDS Device Tree Source
+ *
+ * Copyright 2005, 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/ {
+ model = "MPC8349EMDS";
+ compatible = "MPC834xMDS";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #cpus = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8349@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // from bootloader
+ bus-frequency = <0>; // from bootloader
+ clock-frequency = <0>; // from bootloader
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 10000000>; // 256MB at 0
+ };
+
+ soc8349@e0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0 e0000000 00100000>;
+ reg = <e0000000 00000200>;
+ bus-frequency = <0>;
+
+ wdt@200 {
+ device_type = "watchdog";
+ compatible = "mpc83xx_wdt";
+ reg = <200 100>;
+ };
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <e 8>;
+ interrupt-parent = <700>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3100 100>;
+ interrupts = <f 8>;
+ interrupt-parent = <700>;
+ dfsrr;
+ };
+
+ spi@7000 {
+ device_type = "spi";
+ compatible = "mpc83xx_spi";
+ reg = <7000 1000>;
+ interrupts = <10 8>;
+ interrupt-parent = <700>;
+ mode = <0>;
+ };
+
+ /* phy type (ULPI or SERIAL) are only types supportted for MPH */
+ /* port = 0 or 1 */
+ usb@22000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-mph";
+ reg = <22000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <27 2>;
+ phy_type = "ulpi";
+ port1;
+ };
+ /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
+ usb@23000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-dr";
+ reg = <23000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <26 2>;
+ phy_type = "ulpi";
+ };
+
+ mdio@24520 {
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ linux,phandle = <24520>;
+ ethernet-phy@0 {
+ linux,phandle = <2452000>;
+ interrupt-parent = <700>;
+ interrupts = <11 2>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@1 {
+ linux,phandle = <2452001>;
+ interrupt-parent = <700>;
+ interrupts = <12 2>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ address = [ 00 00 00 00 00 00 ];
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <20 8 21 8 22 8>;
+ interrupt-parent = <700>;
+ phy-handle = <2452000>;
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ address = [ 00 00 00 00 00 00 ];
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <23 8 24 8 25 8>;
+ interrupt-parent = <700>;
+ phy-handle = <2452001>;
+ };
+
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <9 8>;
+ interrupt-parent = <700>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <a 8>;
+ interrupt-parent = <700>;
+ };
+
+ pci@8500 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x11 */
+ 8800 0 0 1 700 14 8
+ 8800 0 0 2 700 15 8
+ 8800 0 0 3 700 16 8
+ 8800 0 0 4 700 17 8
+
+ /* IDSEL 0x12 */
+ 9000 0 0 1 700 16 8
+ 9000 0 0 2 700 17 8
+ 9000 0 0 3 700 14 8
+ 9000 0 0 4 700 15 8
+
+ /* IDSEL 0x13 */
+ 9800 0 0 1 700 17 8
+ 9800 0 0 2 700 14 8
+ 9800 0 0 3 700 15 8
+ 9800 0 0 4 700 16 8
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 700 14 8
+ a800 0 0 2 700 15 8
+ a800 0 0 3 700 16 8
+ a800 0 0 4 700 17 8
+
+ /* IDSEL 0x16 */
+ b000 0 0 1 700 17 8
+ b000 0 0 2 700 14 8
+ b000 0 0 3 700 15 8
+ b000 0 0 4 700 16 8
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 700 16 8
+ b800 0 0 2 700 17 8
+ b800 0 0 3 700 14 8
+ b800 0 0 4 700 15 8
+
+ /* IDSEL 0x18 */
+ b000 0 0 1 700 15 8
+ b000 0 0 2 700 16 8
+ b000 0 0 3 700 17 8
+ b000 0 0 4 700 14 8>;
+ interrupt-parent = <700>;
+ interrupts = <42 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 a0000000 a0000000 0 10000000
+ 42000000 0 80000000 80000000 0 10000000
+ 01000000 0 00000000 e2000000 0 00100000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8500 100>;
+ compatible = "83xx";
+ device_type = "pci";
+ };
+
+ pci@8600 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+
+ /* IDSEL 0x11 */
+ 8800 0 0 1 700 14 8
+ 8800 0 0 2 700 15 8
+ 8800 0 0 3 700 16 8
+ 8800 0 0 4 700 17 8
+
+ /* IDSEL 0x12 */
+ 9000 0 0 1 700 16 8
+ 9000 0 0 2 700 17 8
+ 9000 0 0 3 700 14 8
+ 9000 0 0 4 700 15 8
+
+ /* IDSEL 0x13 */
+ 9800 0 0 1 700 17 8
+ 9800 0 0 2 700 14 8
+ 9800 0 0 3 700 15 8
+ 9800 0 0 4 700 16 8
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 700 14 8
+ a800 0 0 2 700 15 8
+ a800 0 0 3 700 16 8
+ a800 0 0 4 700 17 8
+
+ /* IDSEL 0x16 */
+ b000 0 0 1 700 17 8
+ b000 0 0 2 700 14 8
+ b000 0 0 3 700 15 8
+ b000 0 0 4 700 16 8
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 700 16 8
+ b800 0 0 2 700 17 8
+ b800 0 0 3 700 14 8
+ b800 0 0 4 700 15 8
+
+ /* IDSEL 0x18 */
+ b000 0 0 1 700 15 8
+ b000 0 0 2 700 16 8
+ b000 0 0 3 700 17 8
+ b000 0 0 4 700 14 8>;
+ interrupt-parent = <700>;
+ interrupts = <42 8>;
+ bus-range = <0 0>;
+ ranges = <02000000 0 b0000000 b0000000 0 10000000
+ 42000000 0 90000000 90000000 0 10000000
+ 01000000 0 00000000 e2100000 0 00100000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8600 100>;
+ compatible = "83xx";
+ device_type = "pci";
+ };
+
+ /* May need to remove if on a part without crypto engine */
+ crypto@30000 {
+ device_type = "crypto";
+ model = "SEC2";
+ compatible = "talitos";
+ reg = <30000 10000>;
+ interrupts = <b 8>;
+ interrupt-parent = <700>;
+ num-channels = <4>;
+ channel-fifo-len = <18>;
+ exec-units-mask = <0000007e>;
+ /* desc mask is for rev2.0,
+ * we need runtime fixup for >2.0 */
+ descriptor-types-mask = <01010ebf>;
+ };
+
+ /* IPIC
+ * interrupts cell = <intr #, sense>
+ * sense values match linux IORESOURCE_IRQ_* defines:
+ * sense == 8: Level, low assertion
+ * sense == 2: Edge, high-to-low change
+ */
+ pic@700 {
+ linux,phandle = <700>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <700 100>;
+ built-in;
+ device_type = "ipic";
+ };
+ };
+};
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* libnuma interleaving oddness
From: Nishanth Aravamudan @ 2006-08-29 23:15 UTC (permalink / raw)
To: clameter, ak; +Cc: linux-mm, lnxninja, linuxppc-dev
[Sorry for the double-post, correcting Christoph's address]
Hi,
While trying to add NUMA-awareness to libhugetlbfs' morecore
functionality (hugepage-backed malloc), I ran into an issue on a
ppc64-box with 8 memory nodes, running SLES10. I am using two functions
from libnuma: numa_available() and numa_interleave_memory(). When I ask
numa_interleave_memory() to interleave over all nodes (numa_all_nodes is
the nodemask from libnuma), it exhausts node 0, then moves to node 1,
then node 2, etc, until the allocations are satisfied. If I custom
generate a nodemask, such that bits 1 through 7 are set, but bit 0 is
not, then I get proper interleaving, where the first hugepage is on node
1, the second is on node 2, etc. Similarly, if I set bits 0 through 6 in
a custom nodemask, interleaving works across the requested 7 nodes. But
it has yet to work across all 8.
I don't know if this is a libnuma bug (I extracted out the code from
libnuma, it looked sane; and even reimplemented it in libhugetlbfs for
testing purposes, but got the same results) or a NUMA kernel bug (mbind
is some hairy code...) or a ppc64 bug or maybe not a bug at all.
Regardless, I'm getting somewhat inconsistent behavior. I can provide
more debugging output, or whatever is requested, but I wasn't sure what
to include. I'm hoping someone has heard of or seen something similar?
The test application I'm using makes some mallopt calls then justs
mallocs large chunks in a loop (4096 * 100 bytes). libhugetlbfs is
LD_PRELOAD'd so that we can override malloc.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Linas Vepstas @ 2006-08-29 23:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17652.49904.419167.448821@cargo.ozlabs.ibm.com>
On Wed, Aug 30, 2006 at 08:42:56AM +1000, Paul Mackerras wrote:
> Geoff Levand writes:
>
> > I'm trying to understand the intended design of the inb()
> > and outb() macros in asm-powerpc/io.h. They are causing
> > me some grief when I set CONFIG_PCI=n:
> >
> > drivers/built-in.o: undefined reference to `pci_io_base'
> >
> > This is coming from drivers/char/mem.c, which is always
> > built in, and is referencing pci_io_base through inb()
> > and outb().
>
> Hmmm. inb and outb are designed for accessing PCI I/O space. I guess
> we could turn them into BUG() when CONFIG_PCI=n.
I just looked at drivers/char/mem.c and the code in question
is surrounded by
#if defined(CONFIG_ISA) || !defined(__mc68000__)
which seems just plain wrong.
It should probably be changed to
#if (defined(CONFIG_ISA) || defined(CONFIG_PCI)) && !defined(__mc68000__)
This code surrounds fileops to enale fileio on /dev/port
which maps to inb/outb.
Do we want to enable /dev/port for pci space ??
--linas
^ permalink raw reply
* Re: Help for building linux 2.6.15
From: Wolfgang Denk @ 2006-08-29 23:58 UTC (permalink / raw)
To: wei.li4; +Cc: linuxppc-embedded
In-Reply-To: <20060829171138.y9uuwvfi4gs48ws4@webmail.mcgill.ca>
In message <20060829171138.y9uuwvfi4gs48ws4@webmail.mcgill.ca> you wrote:
>
> I am working on ELDK 4.0 package with my evaluation board: A&M MPC875,
> after configuration for my board, and do 'make zImage', I got the
> following errors:
I cannot find any board support for this board in the 2.6 kernel
trees. Who ported Linux to this hardware? Please go and ask these
guys.
> CC arch/ppc/syslib/m8xx_setup.o
> arch/ppc/syslib/m8xx_setup.c:56: error: 'bd_t' undeclared here (not in
> a function)
Broken code, and/or a broken configuration, if you ask me.
> Can anyone help me? Thanks.
Which board configration are you using? And where is the board support
coming from?
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
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield",
stardate 5730.2
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Geoff Levand @ 2006-08-29 23:57 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060829232026.GC27372@austin.ibm.com>
Linas Vepstas wrote:
> On Wed, Aug 30, 2006 at 08:42:56AM +1000, Paul Mackerras wrote:
>> Geoff Levand writes:
>>
>> > I'm trying to understand the intended design of the inb()
>> > and outb() macros in asm-powerpc/io.h. They are causing
>> > me some grief when I set CONFIG_PCI=n:
>> >
>> > drivers/built-in.o: undefined reference to `pci_io_base'
>> >
>> > This is coming from drivers/char/mem.c, which is always
>> > built in, and is referencing pci_io_base through inb()
>> > and outb().
>>
>> Hmmm. inb and outb are designed for accessing PCI I/O space. I guess
>> we could turn them into BUG() when CONFIG_PCI=n.
>
> I just looked at drivers/char/mem.c and the code in question
> is surrounded by
>
> #if defined(CONFIG_ISA) || !defined(__mc68000__)
>
> which seems just plain wrong.
>
> It should probably be changed to
>
> #if (defined(CONFIG_ISA) || defined(CONFIG_PCI)) && !defined(__mc68000__)
>
> This code surrounds fileops to enale fileio on /dev/port
> which maps to inb/outb.
>
> Do we want to enable /dev/port for pci space ??
I found the same, but was thinking
#if defined(CONFIG_ISA) && !defined(__mc68000__)
So it is only built when CONFIG_ISA=y. Is there any
reason to always have it whit PCI?
Paul, can I send you that fix, or should I send it to
someone else?
-Geoff
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Paul Mackerras @ 2006-08-30 0:13 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <44F4D458.7030707@am.sony.com>
Geoff Levand writes:
> I found the same, but was thinking
>
> #if defined(CONFIG_ISA) && !defined(__mc68000__)
>
> So it is only built when CONFIG_ISA=y. Is there any
> reason to always have it whit PCI?
It's occasionally useful with PCI && !ISA. It's pretty useless with
!PCI && !ISA.
> Paul, can I send you that fix, or should I send it to
> someone else?
Send it to Andrew Morton.
Paul.
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Nishanth Aravamudan @ 2006-08-30 0:21 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, lnxninja, ak, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0608291655160.22397@schroedinger.engr.sgi.com>
On 29.08.2006 [16:57:35 -0700], Christoph Lameter wrote:
> On Tue, 29 Aug 2006, Nishanth Aravamudan wrote:
>
> > I don't know if this is a libnuma bug (I extracted out the code from
> > libnuma, it looked sane; and even reimplemented it in libhugetlbfs
> > for testing purposes, but got the same results) or a NUMA kernel bug
> > (mbind is some hairy code...) or a ppc64 bug or maybe not a bug at
> > all. Regardless, I'm getting somewhat inconsistent behavior. I can
> > provide more debugging output, or whatever is requested, but I
> > wasn't sure what to include. I'm hoping someone has heard of or seen
> > something similar?
>
> Are you setting the tasks allocation policy before the allocation or
> do you set a vma based policy? The vma based policies will only work
> for anonymous pages.
The order is (with necessary params filled in):
p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, );
numa_interleave_memory(p, newsize);
mlock(p, newsize); /* causes all the hugepages to be faulted in */
munlock(p,newsize);
>From what I gathered from the numa manpages, the interleave policy
should take effect on the mlock, as that is "fault-time" in this
context. We're forcing the fault, that is.
Does that answer your question? Sorry if I'm unclear, I'm a bit of a
newbie to the VM.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Christoph Lameter @ 2006-08-29 23:57 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linux-mm, lnxninja, ak, linuxppc-dev
In-Reply-To: <20060829231545.GY5195@us.ibm.com>
On Tue, 29 Aug 2006, Nishanth Aravamudan wrote:
> I don't know if this is a libnuma bug (I extracted out the code from
> libnuma, it looked sane; and even reimplemented it in libhugetlbfs for
> testing purposes, but got the same results) or a NUMA kernel bug (mbind
> is some hairy code...) or a ppc64 bug or maybe not a bug at all.
> Regardless, I'm getting somewhat inconsistent behavior. I can provide
> more debugging output, or whatever is requested, but I wasn't sure what
> to include. I'm hoping someone has heard of or seen something similar?
Are you setting the tasks allocation policy before the allocation or do
you set a vma based policy? The vma based policies will only work for
anonymous pages.
^ permalink raw reply
* RE: atomic operations in user space
From: Liu Dave-r63238 @ 2006-08-30 2:17 UTC (permalink / raw)
To: Li Yang-r58472, linuxppc-embedded, linuxppc-dev
[snip]
> I surely know all the theories you mentioned clearly. But=20
> please do look at the case I gave. Correct me if I missed=20
> anything. Thanks
>=20
> All the lwarx and stwcx operate on the same address.
>=20
> > Task A Task B
> > lwarx =09
> // Get RESERVATION
> > ......
> > lwarx
> > stwcx
>=20
> // RESERVATION cleared
> >
> > .....
> > .....
> > lwarx
>=20
> // Get RESERVATION again
> > stwcx =09
>=20
> //Note here: RESERVATION is valid, address is the same.
> So the result is commited, no retry for task A
>=20
> > .....
> > stwcx
> //RESERVATION is cleared, retry atomic op for task B
>=20
> Please be noted that reservation is only identified by=20
> reservation bit and address operated on. So different=20
> lwarx's on the same address, may be considered as the same=20
> reservation.
Is this your reason we cannot do atomic operation in user space?
How about the kernel space? You can image it.
The context switching as above also happen in kernel space,
Why we can do atomic operation in kernel space, not do in user space?
You are assuming the context switching cause the reservation broken.
but we can do atomic operation in kernel space. The context switching
really is the execption of processor, If we can clear the wrong
RESERVATION
before exception return, I think we can solve this problem. We can dummy
stwcx. before exception return or the processor automaticly clear the
reservation in exception.=20
Are you missing these important things?
-DAve
^ 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