Either use the stock ticker, in UPPER CASE, or use a nice
descriptive name. The lower case space is free for all,
using shortened names (like mrvl) there only increases
the chances of collisions.
Frankly Segher, it doesn't matter to me. However, NONE of the
existing DTS files use upper-case
Kamalesh Babulal writes:
The Kernel oopses is seen while running the kernbench followed by tbench with
2.6.25-rc2-git4
kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel
(http://lkml.org/lkml/2008/1/18/71)
and is visible with almost all of the main line ,rc(s) and
Scott Wood schrieb:
On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote:
Kernel starts and crashes with unable to handle kernel paging request @
.
After turning debug on in some files I can see that the initrd memory
gets reserved and the dtb is parsed correctly.
PCI
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts.
There are several limitations in this support:
1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
This is straightforward to implement
Are you using uartlite? Try console=ttyUL0.
Thanks, I didn't know that.
But Stephen is right, the first thing you should do is look at
__log_buf. You can find its address in the System.map file.
Unfortunately, the installation of the cable driver failed for some reason.
I'll have to work
sorry - forgot Kim + List
Original-Nachricht
Betreff:Re: MPC8343 - unable to handle paging request @ 0
Datum: Tue, 08 Apr 2008 13:29:20 +0200
Von:Andre Schwarz [EMAIL PROTECTED]
An: Scott Wood [EMAIL PROTECTED]
Referenzen: [EMAIL PROTECTED]
[EMAIL PROTECTED]
On Tue, Apr 08, 2008 at 11:01:53AM +0200, Laurent Pinchart wrote:
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts.
There are several limitations in this support:
1. Cascaded (32 bit)
Paul Mackerras wrote:
Kamalesh Babulal writes:
The Kernel oopses is seen while running the kernbench followed by tbench
with 2.6.25-rc2-git4
kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel
(http://lkml.org/lkml/2008/1/18/71)
and is visible with almost all of the
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
[...]
I had a first go at hacking the FHCI driver to make it run on a CPM2
platform.
Results so far are quite good. After getting rid of qe-specific APIs as
explained above, and adding SOF token generation support, I've been
Kamalesh Babulal writes:
The kernel oops after applying the patch. Some time it takes more than
one run to reproduce it, it was reproducible in the second run this
time.
Unrecoverable exception 4100 at c0008c8c
Oops: Unrecoverable exception, sig: 6 [#1]
SMP NR_CPUS=128 NUMA
Bartlomiej Zolnierkiewicz wrote:
Fix kernel oops due to machine check occuring in init_chipset_siimage() on PPC
44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O and
memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in ioremap()
that creates an illusion
Scott Wood schrieb:
On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote:
Kernel starts and crashes with unable to handle kernel paging request @
.
After turning debug on in some files I can see that the initrd memory
gets reserved and the dtb is parsed correctly.
PCI
Paul,
Here's my take on the current status of the patchset:
[POWERPC] bootwrapper: Allow specifying of image physical offset
reworked to look at PHDR (needs linker script update patch). Still
open question on how best to do that (objdump, readelf, C program,
suggestions)
[POWERPC]
On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-04-07 at 11:20 -0500, Scott Wood wrote:
Another possible use is a BAT/TLB1 mapping for SoC registers (or
anything
else on the board which is frequently accessed), which can be reused
by
ioremap() to avoid wasting normal
Sergei Shtylyov wrote:
A very late comment but nevertheless... :-)
Better late than never.
Those functions are going to break on 32-bit platforms with extended
physical address (well, that's starting with Pentiums which had 36-bit
PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC
On Tue, Apr 8, 2008 at 3:37 AM, Matt Sealey [EMAIL PROTECTED] wrote:
I'd not thank Grant.
I think the prom_init fixes are bordering on disgusting.. it would
make it's way into commercial code for sure, but only because nobody
would see what a hideous mess it is :)
The best solution by
Tejun Heo wrote:
A very late comment but nevertheless... :-)
Better late than never.
:-)
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums which
had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
Sergei Shtylyov wrote:
Yeah, right please go ahead. But I wonder whether any BIOS was
actually crazy enough to map mmio region above 4G on 32bit machine.
This is a *hardware* mapping on some non-x86 platforms (like PPC 44x
or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have
On Mon, 2008-04-07 at 10:14 -0700, Dale Farnsworth wrote:
Add the low level irq tracing hooks for 32-bit powerpc needed
to enable full lockdep functionality.
Dale Farnsworth [EMAIL PROTECTED]
---
This version fixes the clobbering of r12 by the call to
trace_hardirqs_off() that was pointed
On Tue, Apr 08, 2008 at 09:28:12AM -0500, Kumar Gala wrote:
On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote:
As far as the above is concerned, I'm not too fan of fixed virtual
addresses. I'd rather dynamically assign it. But we can do it.
I'm in agreement with Ben here. On Freescale
On Tue, Apr 08, 2008 at 10:51:18AM +0200, Andre Schwarz wrote:
Call Trace:
[c01f9ef0] [c001c190] (unreliable)
[c01f9f10] [c0140c84]
[c01f9f20] [c0140ccc]
[c01f9f40] [c014145c]
[c01f9f60] [c0014014]
[c01f9fa0] [c01d1a40]
[c01f9fb0] [c01ce64c]
[c01f9fc0] [c01c55ac]
[c01f9ff0] [3438]
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during console_init() ...
Does your device tree have a /chosen node after u-boot is done with it?
find_legacy_serial_ports() can crash
2 files changed, 77 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile |2
arch/powerpc/platforms/44x/idle.c | 76 +++
Updates: Now setting MSR_WE is now default
Tested on hardware platforms bamboo sequioa and appears
things
Paul Mackerras wrote:
Kamalesh Babulal writes:
The kernel oops after applying the patch. Some time it takes more than
one run to reproduce it, it was reproducible in the second run this
time.
Unrecoverable exception 4100 at c0008c8c
Oops: Unrecoverable exception, sig: 6 [#1]
SMP
The driver stores the the PCI resource addresses into 'unsigned long' variable
before calling ioremap() on them. This warrants kernel oops when the registers
are accesse on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in
On Tuesday 08 April 2008 11:49:14 Jerone Young wrote:
2 files changed, 77 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile |2
arch/powerpc/platforms/44x/idle.c | 76
+++
Updates: Now setting MSR_WE is now default
Tested on
Scott Wood wrote:
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during console_init() ...
Does your device tree have a /chosen node after u-boot is done with it?
The driver stores the the PCI resource address into 'unsigned long' variable
before calling ioremap() on it. This warrants kernel oops when the registers
are accessed on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap()
On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote:
It may be ideal, but I don't think it is realistic. I'm now of the
firm opinion that device trees and firmware are *never* perfect.
Especially when the definition of perfect is a moving target.
Well observed; isn't this the prove
Robert Schwebel wrote:
Well observed; isn't this the prove of the assumption that the whole
device tree idea is not working? It is *always* inconsistent and it is
*maintenance hell* because out-of-tree ports do *always* breakt because
of string inconsistencies. We have just ported a 8260 board
Robert Schwebel wrote:
The ARM method of using just a device number is so much easier ...
And I was going to suggest that the ARM guys should use device trees, too.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
On Fri, 2008-04-04 at 08:38 +0200, Arnd Bergmann wrote:
On Wednesday 02 April 2008, Carl Love wrote:
On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
On Tuesday 25 March 2008, Carl Love wrote:
This patch fixes a bug in the code that records the SPU data and
context switches.
On Tue, Apr 8, 2008 at 1:45 PM, Robert Schwebel
[EMAIL PROTECTED] wrote:
On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote:
It may be ideal, but I don't think it is realistic. I'm now of the
firm opinion that device trees and firmware are *never* perfect.
Especially when the
Commit 0f436eff54f90419ac1b8accfb3e6e17c4b49a4e breaks build on
arch/ppc as it doesn't implement the machine_is() macro.
This fixes it by using CONFIG_PPC_MERGE instead which represents
arch/powerpc only, while CONFIG_PPC is set for both.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
I was thinking it might be good to have the kernel initialize these
cache control registers in it's own start up code. Or perhaps this
could be done in the kernel's simple bootloader. We could probably put
this change in a Xilinx specific
On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
I was thinking it might be good to have the kernel initialize these
cache control registers in it's own start up code. Or perhaps this
could be done in
On Tue, Apr 08, 2008 at 03:07:58PM -0500, Scott Wood wrote:
Robert Schwebel wrote:
Well observed; isn't this the prove of the assumption that the whole
device tree idea is not working? It is *always* inconsistent and it is
*maintenance hell* because out-of-tree ports do *always* breakt because
On Tue, 8 Apr 2008 17:15:44 -0600
Grant Likely [EMAIL PROTECTED] wrote:
On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
I was thinking it might be good to have the kernel initialize these
cache
On Tuesday 08 April 2008, Carl Love wrote:
On Fri, 2008-04-04 at 08:38 +0200, Arnd Bergmann wrote:
Our first thought to fix the bug was to just grab the mutex lock when
adding the switch notification data to the queue. The kernel gives us
an oops message saying something along the line of
Why? Because:
A) It's not modified and so it can be made const. const is good.
B) If one has a function that was given a const pci_bus pointer and you
want to get a pointer to its pci_controller, you'll get a warning from gcc
when you use pci_bus_to_host(). This is the right way to stop that
On Mon, 2008-04-07 at 16:36 -0500, Kumar Gala wrote:
On Apr 6, 2008, at 8:06 AM, Josh Boyer wrote:
Hi All,
Unless someone screams loudly and has reasons why this shouldn't go
in,
the following commit should hit the 4xx next branch in the next day or
so.
josh
If this is
On Tue, 2008-04-08 at 19:19 -0700, Trent Piepho wrote:
Why? Because:
A) It's not modified and so it can be made const. const is good.
B) If one has a function that was given a const pci_bus pointer and you
want to get a pointer to its pci_controller, you'll get a warning from gcc
when you
Paul Mackerras wrote:
Kamalesh Babulal writes:
The kernel oops after applying the patch. Some time it takes more than
one run to reproduce it, it was reproducible in the second run this
time.
Unrecoverable exception 4100 at c0008c8c
Oops: Unrecoverable exception, sig: 6 [#1]
SMP
43 matches
Mail list logo
