* slow Kilauea TCP throughput?
From: Donasch, Ingo @ SDS @ 2008-03-12 11:59 UTC (permalink / raw)
To: linuxppc-dev
I have a project where I would like to use the AMC405EX under Linux for
high speed data acquisition. I have the Kilauea board in the lab but
measured only 150Mbit/s TCP throughput (outbound) with iperf. I need
twice of that and actually expecting 3x higher bandwidth from that
architecture.
what is it that I'm missing?
can anybody confirm my results or tell me what am I doing wrong?
any help is appreciated
sincerely
ingo
/home # uname -a
Linux kilauea 2.6.23-g1dfaad37 #1 Wed Nov 21 07:15:18 CET 2007 ppc
unknown
home # ./iperf -c 192.168.1.249 -t60 -i1
------------------------------------------------------------
Client connecting to 192.168.1.249, TCP port 5001 TCP window size: 16.0
KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.50 port 59035 connected with 192.168.1.249 port
5001
[ 5] 0.0- 1.0 sec 16.6 MBytes 139 Mbits/sec
[ 5] 1.0- 2.0 sec 16.6 MBytes 140 Mbits/sec
...
[ 5] 58.0-59.0 sec 18.0 MBytes 151 Mbits/sec
[ 5] 59.0-60.0 sec 18.0 MBytes 151 Mbits/sec
[ 5] 0.0-60.0 sec 1.04 GBytes 148 Mbits/sec
/home # ifconfig
eth0 Link encap:Ethernet HWaddr 00:06:4B:10:19:5B =20
inet addr:192.168.1.50 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:798928 errors:0 dropped:0 overruns:0 frame:0
TX packets:1634765 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000=20
RX bytes:53947650 (51.4 MiB) TX bytes:2341215308 (2.1 GiB)
lo Link encap:Local Loopback =20
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0=20
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
*********************************************************************
The information contained in this e-mail is intended only for the person
or entity to which it is addressed and may contain confidential and / or
privileged material. If you are not the intended recipient of this
e-mail, the use of this information or any disclosure, copying or
distribution is prohibited and may be unlawful.=20
If you received this in error, please contact the sender and delete the
material from any computer.=20
L-3 Communications Security Systems, manufacturer of the eXaminer 3DX
6000 Explosive Detection System - <http://www.l-3com.com>
**********************************************************************
^ permalink raw reply
* Using the loop feature of the DMA controller on MPC8544 DS
From: Sebastian Siewior @ 2008-03-12 12:34 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-embedded
Hello,
I have here a MPC8544 DS board and I tried to utilise the dma
controller. For the transfers I need set the [S|D]AHE bit in the Mode
Register. This seems to be implemented but is currently unused in the
driver. I haven't found a way how to set this bit except globally for
the whole channel.
Is it possible to solve this nicely except dedicating one channel for
such an operation?
thanks,
Sebastian
^ permalink raw reply
* 2.6.23.1 and more than 32MB, segfault
From: Petr Žejdl @ 2008-03-12 12:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm using MEMEC board ML300 compatible with 64MB SDRAM available and
vanilla kernel 2.6.23.1. The problem are random segfaults from init,
sometimes before init when using more than 32MB ram. Everything is OK
only when memory is limited to 32MB (mem=32M).
Thank You for any advice.
Petr
^ permalink raw reply
* [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Kamalesh Babulal @ 2008-03-12 12:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080311011434.ad8c8d7d.akpm@linux-foundation.org>
Hi Andrew,
The 2.6.25-rc5-mm1 kernel panics while bootup on powerpc
returning from prom_init
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc00000000000d5dc
cpu 0x0: Vector: 300 (Data Access) at [c0000000007636e0]
pc: c00000000000d5dc: .do_IRQ+0x74/0x1f4
lr: c00000000000d5a8: .do_IRQ+0x40/0x1f4
sp: c000000000763960
msr: 8000000000001032
dar: 0
dsisr: 40000000
current = 0xc000000000688e60
paca = 0xc000000000689900
pid = 0, comm = swapper
enter ? for help
[c000000000763a00] c000000000004c24 hardware_interrupt_entry+0x24/0x28
--- Exception: 501 (Hardware Interrupt) at c0000000006021b0 .free_bootmem_core+0x94/0xcc
[link register ] c00000000060373c .free_bootmem_with_active_regions+0x78/0xb8
[c000000000763cf0] c000000000602610 .init_bootmem_core+0x5c/0xfc (unreliable)
[c000000000763d80] c0000000005eb68c .do_init_bootmem+0x964/0xaf0
[c000000000763e50] c0000000005e03b0 .setup_arch+0x1a4/0x218
[c000000000763ee0] c0000000005d76bc .start_kernel+0xe8/0x424
[c000000000763f90] c000000000008590 .start_here_common+0x60/0xd0
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH] ppc: Export empty_zero_page
From: Theodore Tso @ 2008-03-12 14:42 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20080312034110.GT6887@bakeyournoodle.com>
On Wed, Mar 12, 2008 at 02:41:10PM +1100, Tony Breeds wrote:
>
> I suspect you meant arch/*powerpc* arch ppc, wont fix the problem ;P
>
Um, right. I didn't know about this:
> Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
> platforms. Currently there are efforts underway to port the remaining
> arch/ppc platforms to the merged tree. New submissions to the arch/ppc
> tree have been frozen with the 2.6.22 kernel release and that tree will
> remain in bug-fix only mode until its scheduled removal. Platforms
> that are not ported by June 2008 will be removed due to the lack of an
> interested maintainer.
Oops, sorry. So should I not bother with a patch to arch/ppc at all?
I guess it's somewhat likely that whatever is left in arch/ppc is not
likely to need to support ext4?
Back with a real patch in just a bit. :-)
- Ted
^ permalink raw reply
* XMD to debug Linux kernel 2.6
From: Ramkumar J @ 2008-03-12 15:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
Hi All,
I need to dump the TLB entries, i-cache and d-cache entries on a ML-403
board ( I use a PowerPc based design) using the Xilinx Parallel-4 Cable.
When I download the zImage.elf using dow command on XMD, I m not able to
access the TLB and cache address special memory mappings as displayed by the
XMD. I suspect that XMD only allows the dump for sections inside the elf
file. If its true, then how to access the sections of kernel.
Could XMD be used to debug a linux kernel by dumping the registers, TLBs,
cache entries,etc. Am I missing anything. Any pointers would be very
helpful.
Thanks and Regards,
Ramkumar
[-- Attachment #2: Type: text/html, Size: 664 bytes --]
^ permalink raw reply
* RE: XMD to debug Linux kernel 2.6
From: John Linn @ 2008-03-12 16:01 UTC (permalink / raw)
To: Ramkumar J, linuxppc-embedded
In-Reply-To: <4f8c3030803120815o7dcf5e8xb74650c8b993d26d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
Hi Ramkumar,
XMD can definitely be used to help debug a kernel. I use it to dump
registers and to dump memory. I'm not sure on the TLB entries yet but
will check into it. I'm sure that XMD does not handle any virtual
address to physical conversions.
I use it to dump the log buff sometimes when the kernel doesn't come up.
You may need to do a RST and then you need to use the physical address
rather than the virtual address (Address - 0xC0000000).
You can do a help in XMD.
Thanks,
John
________________________________
From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org] On
Behalf Of Ramkumar J
Sent: Wednesday, March 12, 2008 9:15 AM
To: linuxppc-embedded@ozlabs.org
Subject: XMD to debug Linux kernel 2.6
Hi All,
I need to dump the TLB entries, i-cache and d-cache entries on a ML-403
board ( I use a PowerPc based design) using the Xilinx Parallel-4 Cable.
When I download the zImage.elf using dow command on XMD, I m not able to
access the TLB and cache address special memory mappings as displayed by
the XMD. I suspect that XMD only allows the dump for sections inside the
elf file. If its true, then how to access the sections of kernel.
Could XMD be used to debug a linux kernel by dumping the registers,
TLBs, cache entries,etc. Am I missing anything. Any pointers would be
very helpful.
Thanks and Regards,
Ramkumar
[-- Attachment #2: Type: text/html, Size: 11267 bytes --]
^ permalink raw reply
* Re: Using the loop feature of the DMA controller on MPC8544 DS
From: Timur Tabi @ 2008-03-12 15:58 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded, Zhang Wei
In-Reply-To: <20080312123437.GA1589@Chamillionaire.breakpoint.cc>
Sebastian Siewior wrote:
> Hello,
>
> I have here a MPC8544 DS board and I tried to utilise the dma
> controller. For the transfers I need set the [S|D]AHE bit in the Mode
> Register. This seems to be implemented but is currently unused in the
> driver.
Which driver? Zhang's DMA driver?
I haven't looked at Zhang's driver, but I just spotted this code:
case FSL_DMA_IP_85XX:
new_fsl_chan->toggle_ext_start = fsl_chan_toggle_ext_start;
new_fsl_chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
case FSL_DMA_IP_83XX:
new_fsl_chan->set_src_loop_size = fsl_chan_set_src_loop_size;
new_fsl_chan->set_dest_loop_size = fsl_chan_set_dest_loop_size;
(Don't let the missing "break" from FSL_DMA_IP_85XX fool you)
So it looks like there already is a way to set the SAHE and DAHE bits. I guess
this is what you mean by "seems to be implemented but is currently unused"?
> I haven't found a way how to set this bit except globally for
> the whole channel.
Well, the SAHE bit is part of the MR register, so it can only apply to a whole
channel. This is a hardware limitation.
> Is it possible to solve this nicely except dedicating one channel for
> such an operation?
No.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 8/8] pseries: phyp dump: config file
From: Manish Ahuja @ 2008-03-12 16:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linasvepstas, mahuja
In-Reply-To: <18390.9443.218176.274640@cargo.ozlabs.ibm.com>
Thanks for the review. I will try and make the recommended changes and repost it soon.
Manish
Paul Mackerras wrote:
> Manish Ahuja writes:
>
>> +config PHYP_DUMP
>> + bool "Hypervisor-assisted dump (EXPERIMENTAL)"
>> + depends on PPC_PSERIES && EXPERIMENTAL
>> + default y
>
> I think this should default to n for now (i.e. leave out the default
> line entirely). We can make it default to y later.
>
> Paul.
^ permalink raw reply
* Re: Using the loop feature of the DMA controller on MPC8544 DS
From: Sebastian Siewior @ 2008-03-12 17:20 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded, Zhang Wei
In-Reply-To: <47D7FD9D.2040202@freescale.com>
* Timur Tabi | 2008-03-12 10:58:21 [-0500]:
>Sebastian Siewior wrote:
>> Hello,
>>
>> I have here a MPC8544 DS board and I tried to utilise the dma
>> controller. For the transfers I need set the [S|D]AHE bit in the Mode
>> Register. This seems to be implemented but is currently unused in the
>> driver.
>
>Which driver? Zhang's DMA driver?
Yes, fsldma.c, that's the only one in tree for the CPU unless there are
some hidden trees :)
>I haven't looked at Zhang's driver, but I just spotted this code:
>
>case FSL_DMA_IP_85XX:
> new_fsl_chan->toggle_ext_start = fsl_chan_toggle_ext_start;
> new_fsl_chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
>case FSL_DMA_IP_83XX:
> new_fsl_chan->set_src_loop_size = fsl_chan_set_src_loop_size;
> new_fsl_chan->set_dest_loop_size = fsl_chan_set_dest_loop_size;
>
>(Don't let the missing "break" from FSL_DMA_IP_85XX fool you)
>
>So it looks like there already is a way to set the SAHE and DAHE bits. I guess
>this is what you mean by "seems to be implemented but is currently unused"?
Yes it is :)
>> I haven't found a way how to set this bit except globally for
>> the whole channel.
>
>Well, the SAHE bit is part of the MR register, so it can only apply to a whole
>channel. This is a hardware limitation.
Argh, I hoped that could be hidden at the offset 0x1c in the link
descriptor which is marked as reserved.
>> Is it possible to solve this nicely except dedicating one channel for
>> such an operation?
>
>No.
I need to hold src & dst each with one and two bytes makes four
channels. And then I need one for normal transfers. So I guess I have to
talk to my HW ppl that we have to change something :)
Sebastian
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Linas Vepstas @ 2008-03-12 17:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, mahuja
In-Reply-To: <18390.9137.626123.104628@cargo.ozlabs.ibm.com>
On 11/03/2008, Paul Mackerras <paulus@samba.org> wrote:
>
> > ------
>
> This line needs to be exactly 3 dashes, because otherwise the tools
> include the diffstat into the commit message. Putting 4 or more
> dashes was an annoying habit Linas had, and it means I have to fix it
> manually (usually after I have committed the patches, and then notice
> that the commit message has the extra stuff in it, so I have to go
> back and fix the separators, reset my tree and re-commit the patches.)
Sorry, I had no idea! If I didn't have enough dashes, then quilt would
sometimes wipe out the comment at the top, so paranoia made me
add lots of dashes.
--linas
^ permalink raw reply
* Re: [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Andrew Morton @ 2008-03-12 17:46 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Matthew Wilcox, linux-kernel
In-Reply-To: <47D7D2C9.4090001@linux.vnet.ibm.com>
On Wed, 12 Mar 2008 18:25:37 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> The 2.6.25-rc5-mm1 kernel panics while bootup on powerpc
>
> returning from prom_init
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc00000000000d5dc
> cpu 0x0: Vector: 300 (Data Access) at [c0000000007636e0]
> pc: c00000000000d5dc: .do_IRQ+0x74/0x1f4
> lr: c00000000000d5a8: .do_IRQ+0x40/0x1f4
> sp: c000000000763960
> msr: 8000000000001032
> dar: 0
> dsisr: 40000000
> current = 0xc000000000688e60
> paca = 0xc000000000689900
> pid = 0, comm = swapper
> enter ? for help
> [c000000000763a00] c000000000004c24 hardware_interrupt_entry+0x24/0x28
> --- Exception: 501 (Hardware Interrupt) at c0000000006021b0 .free_bootmem_core+0x94/0xcc
> [link register ] c00000000060373c .free_bootmem_with_active_regions+0x78/0xb8
> [c000000000763cf0] c000000000602610 .init_bootmem_core+0x5c/0xfc (unreliable)
> [c000000000763d80] c0000000005eb68c .do_init_bootmem+0x964/0xaf0
> [c000000000763e50] c0000000005e03b0 .setup_arch+0x1a4/0x218
> [c000000000763ee0] c0000000005d76bc .start_kernel+0xe8/0x424
> [c000000000763f90] c000000000008590 .start_here_common+0x60/0xd0
>
Beats me. Maybe we're still enabling interrupts too early. But the new
semaphore code got fixed (didn't it?)
^ permalink raw reply
* Re: [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Matthew Wilcox @ 2008-03-12 17:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, Kamalesh Babulal
In-Reply-To: <20080312104645.34e58319.akpm@linux-foundation.org>
On Wed, Mar 12, 2008 at 10:46:45AM -0700, Andrew Morton wrote:
> On Wed, 12 Mar 2008 18:25:37 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Beats me. Maybe we're still enabling interrupts too early. But the new
> semaphore code got fixed (didn't it?)
On the 7th, according to my records. Easy to check -- look in
kernel/semaphore.c and see whether down() is using spin_lock_irqsave
(good) or spin_lock_irq (bad).
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-12 17:51 UTC (permalink / raw)
To: Jens Osterkamp
Cc: linuxppc-dev, Paul Mackerras, Roland McGrath, Arnd Bergmann,
Jan Kratochvil
In-Reply-To: <200803101501.34439.jens@de.ibm.com>
Hi,
> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
> already did this. Uli Weigand found this back in November. I submitted
> a patch for this which went into 2.6.25-rc4.
> Can you please try again with rc4 ?
> Gruß,
>
> Jens
Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It
still fails. So this is really an open bug for PPC.
--
Luis Machado
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Linas Vepstas @ 2008-03-12 17:52 UTC (permalink / raw)
To: michael; +Cc: mahuja, linuxppc-dev, paulus
In-Reply-To: <1205197341.8656.5.camel@concordia.ozlabs.ibm.com>
On 10/03/2008, Michael Ellerman <michael@ellerman.id.au> wrote:
> On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote:
> > +
> > +/* Global, used to communicate data between early boot and late boot */
> > +static struct phyp_dump phyp_dump_global;
> > +struct phyp_dump *phyp_dump_info = &phyp_dump_global;
>
> I don't see the point of this. You have a static (ie. non-global) struct
> called phyp_dump_global, then you create a pointer to it and pass that
> around.
I did this. This is a style used to minimize disruption due to future
design changes. Basically, the idea is that, at some later time, for
some unknown reason, we decide that this structure shouldn't
be global, or maybe shouldn't be statically allocated, or maybe
should be per-cpu, or who knows. By creating a pointer, and
just passing that around, you isolate other code from this change.
I learned this trick after spending too many months of my life hunting
down globals and replacing them by dynamically allocated structs.
Its a long and painful process, on many levels, often requiring major
code restructuring. Code that touches globals directly is often
poorly thought out, designed. But going in the opposite direction
is easy: if your code always passes everything it needs as args
to subroutines, then you are free & clear ... if one of those args
just happens to be a pointer to a global, there's no loss (not even
a performance loss -- the arg passing overhead is about the same
as a global TOC lookup!)
So it may look weird if you're not used to seeing it; but the alternative
is almost always worse.
--linas
^ permalink raw reply
* fsldma seems to be buggy, noticed in loop mode
From: Sebastian Siewior @ 2008-03-12 18:04 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a little kmod where I dma data from one place to another (can
post it if someone wants to see it). It works in general according to
memcmp :)
If I set the DAHE flag (DAHTS = 0, for one byte transfers) everything
seems to work as well (I see only the last byte which has the correct
value).
Now if I change the destination address to my FIFO I get the requested
transfer size plus some extra bytes. The extra bytes are looking like
exactly the same DMA transfer once again. Then my FIFO overruns.
Enabling some printks in the kernel gave me the following log:
|of-fsl-dma-channel e0021100.dma-channe: new link desc alloc df32a000
|of-fsl-dma-channel e0021100.dma-channe: --memcpy issue--
|of-fsl-dma-channel e0021100.dma-channe: Ch 0, LD 1f32a000
|of-fsl-dma-channel e0021100.dma-channe: LD offset 0: 00050000
|of-fsl-dma-channel e0021100.dma-channe: LD offset 1: 1f0be000
|of-fsl-dma-channel e0021100.dma-channe: LD offset 2: 00050000
|of-fsl-dma-channel e0021100.dma-channe: LD offset 3: 1f36c000
|of-fsl-dma-channel e0021100.dma-channe: LD offset 4: 00000000
|of-fsl-dma-channel e0021100.dma-channe: LD offset 5: 00000001
|of-fsl-dma-channel e0021100.dma-channe: LD offset 6: 00000100
|of-fsl-dma-channel e0021100.dma-channe: LD offset 7: 00000000
|of-fsl-dma-channel e0021100.dma-channe: ----------------
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: xfer LDs staring from 0x000000001f32a000
|of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie = 1
|of-fsl-dma-channel e0021100.dma-channe: link descriptor df32a000 will be recycle.
|of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie = 1
|of-fsl-dma-channel e0021100.dma-channe: chan completed_cookie = 1
done.
I have one list entry which is df32a000. According to the output that
single request gets started a couple of times what would explain why the
FIFO overruns.
Is it possible that the driver does not properly recognize that the
transfer is finished _and_ that is the last one in line? Enabling the
dma self test Kconfig option shows no error message but the number of
interrupts that have been generated differ from channel to channel,
from boot to boot.
btw: It is a MPC8544 DS with -rc5.
thanks,
Sebastian
^ permalink raw reply
* Re: [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Badari Pulavarty @ 2008-03-12 18:14 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andrew Morton, lkml
In-Reply-To: <47D7D2C9.4090001@linux.vnet.ibm.com>
On Wed, 2008-03-12 at 18:25 +0530, Kamalesh Babulal wrote:
> Hi Andrew,
>
> The 2.6.25-rc5-mm1 kernel panics while bootup on powerpc
>
> returning from prom_init
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc00000000000d5dc
> cpu 0x0: Vector: 300 (Data Access) at [c0000000007636e0]
> pc: c00000000000d5dc: .do_IRQ+0x74/0x1f4
> lr: c00000000000d5a8: .do_IRQ+0x40/0x1f4
> sp: c000000000763960
> msr: 8000000000001032
> dar: 0
> dsisr: 40000000
> current = 0xc000000000688e60
> paca = 0xc000000000689900
> pid = 0, comm = swapper
> enter ? for help
> [c000000000763a00] c000000000004c24 hardware_interrupt_entry+0x24/0x28
> --- Exception: 501 (Hardware Interrupt) at c0000000006021b0 .free_bootmem_core+0x94/0xcc
> [link register ] c00000000060373c .free_bootmem_with_active_regions+0x78/0xb8
> [c000000000763cf0] c000000000602610 .init_bootmem_core+0x5c/0xfc (unreliable)
> [c000000000763d80] c0000000005eb68c .do_init_bootmem+0x964/0xaf0
> [c000000000763e50] c0000000005e03b0 .setup_arch+0x1a4/0x218
> [c000000000763ee0] c0000000005d76bc .start_kernel+0xe8/0x424
> [c000000000763f90] c000000000008590 .start_here_common+0x60/0xd0
Is this only on one machine ? happens all the time ?
I ran into similar issues on rc3-mm1. rc5-mm1 seems to be working fine
for me on ppc64.
Thanks,
Badari
^ permalink raw reply
* Re: Using the loop feature of the DMA controller on MPC8544 DS
From: Timur Tabi @ 2008-03-12 18:47 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080312172024.GB7255@Chamillionaire.breakpoint.cc>
Sebastian Siewior wrote:
> I need to hold src & dst each with one and two bytes makes four
> channels. And then I need one for normal transfers. So I guess I have to
> talk to my HW ppl that we have to change something :)
What kind of driver are you writing that needs four simultaneous DMA transfers?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] Linux >=2.6.24 support for FEC on MPC5200 (not B!)
From: René Bürgel @ 2008-03-12 18:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
Here is a patch for the lite5200 to get the FEC working again for kernel
>=2.6.24. It was created against Linux 2.6.24.
The FEC driver is also compatible with the MPC5200, not only with the
MPC5200B, so an according entry was added to the drivers matching list.
Furthermore the settings for the PHY were entered in the dts file for
the Lite5200. Note, that this is not exactly the same as in the
Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
at :00 for the 5200B. I could test the patch on a Lite5200 and a
Lite5200B, both booted a kernel via tftp and mounted the root via nfs
successfully.
I hope, you can include the patch into the official tree.
Kind regards, René Bürgel
--
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenberg
Tel.: 03 72 06/ 88 73 - 12
Fax: 03 72 06/ 88 73 - 60
E-Mail: r.buergel@unicontrol.de
Internet: www.unicontrol.de
[-- Attachment #2: lite5200_fec_on_linux_2.6.24.patch --]
[-- Type: text/plain, Size: 1514 bytes --]
--- ../kernel/current/arch/powerpc/boot/dts/lite5200.dts 2008-03-12 18:26:02.000000000 +0100
+++ linux-2.6.24-uc/arch/powerpc/boot/dts/lite5200.dts 2008-03-12 17:44:06.000000000 +0100
@@ -273,6 +273,22 @@
mac-address = [ 02 03 04 05 06 07 ]; // Bad!
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "mpc5200-fec-phy";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0:ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
};
ata@3a00 {
--- ../kernel/linux-2.6.24-uc/drivers/net/fec_mpc52xx.c 2008-03-12 15:25:27.000000000 +0100
+++ linux-2.6.24-uc/drivers/net/fec_mpc52xx.c 2008-03-12 18:39:30.000000000 +0100
@@ -1059,6 +1059,10 @@
static struct of_device_id mpc52xx_fec_match[] = {
{
.type = "network",
+ .compatible = "mpc5200b-fec",
+ },
+ {
+ .type = "network",
.compatible = "mpc5200-fec",
},
{ }
--- ../kernel/linux-2.6.24-uc/drivers/net/fec_mpc52xx_phy.c 2008-03-12 15:12:11.000000000 +0100
+++ linux-2.6.24-uc/drivers/net/fec_mpc52xx_phy.c 2008-03-12 19:47:39.000000000 +0100
@@ -181,6 +181,10 @@
.type = "mdio",
.compatible = "mpc5200b-fec-phy",
},
+ {
+ .type = "mdio",
+ .compatible = "mpc5200-fec-phy",
+ },
{},
};
^ permalink raw reply
* [PATCH] [POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts
From: Anton Vorontsov @ 2008-03-12 20:02 UTC (permalink / raw)
To: linuxppc-dev
Due to chip constraint MPC837x USB DR module can only use
ULPI and serial PHY interfaces. The patch fixes the wrong
type in dts.
This patch fixes USB malfunctioning on the MPC837xE-RDB boards.
Similar patch has been already applied for the MDS boards:
commit 28b958859206b7010d03129611c2e444898e3ee4
Author: Li Yang <leoli@freescale.com>
Date: Thu Mar 6 18:42:26 2008 +0800
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xmds dts
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8377_rdb.dts | 3 +--
arch/powerpc/boot/dts/mpc8378_rdb.dts | 3 +--
arch/powerpc/boot/dts/mpc8379_rdb.dts | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 440aa4d..5bc09ad 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -143,7 +143,6 @@
mode = "cpu";
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
@@ -151,7 +150,7 @@
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
- phy_type = "utmi";
+ phy_type = "ulpi";
};
mdio@24520 {
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 9271153..711f9a3 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -143,7 +143,6 @@
mode = "cpu";
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
@@ -151,7 +150,7 @@
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
- phy_type = "utmi";
+ phy_type = "ulpi";
};
mdio@24520 {
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index 0dda2fc..c11ceb7 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -143,7 +143,6 @@
mode = "cpu";
};
- /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
@@ -151,7 +150,7 @@
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
- phy_type = "utmi";
+ phy_type = "ulpi";
};
mdio@24520 {
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] ppc: Export empty_zero_page
From: Theodore Tso @ 2008-03-12 20:24 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20080312144239.GY15804@mit.edu>
Once again, this time with feeling....
- Ted
>From c91cfaabc17f8a53807a2f31f067a732e34a1550 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Wed, 12 Mar 2008 11:50:39 -0400
Subject: [PATCH] [PATCH] powerpc: Export empty_zero_page
The empty_zero_page symbol is exported by most other architectures
(s390, ia64, x86, um), and an upcoming ext4 patch needs it because
ZERO_PAGE() references empty_zero_page, and we need it to zero out an
unitialized extents in ext4 files.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
arch/powerpc/kernel/ppc_ksyms.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index aa9ff35..885a723 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -58,6 +58,7 @@ extern void program_check_exception(struct pt_regs *regs);
extern void single_step_exception(struct pt_regs *regs);
extern int sys_sigreturn(struct pt_regs *regs);
+EXPORT_SYMBOL(empty_zero_page);
EXPORT_SYMBOL(clear_pages);
EXPORT_SYMBOL(copy_page);
EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
--
1.5.4.1.144.gdfee-dirty
^ permalink raw reply related
* Re: Using the loop feature of the DMA controller on MPC8544 DS
From: Sebastian Siewior @ 2008-03-12 20:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded
In-Reply-To: <47D82542.8020000@freescale.com>
* Timur Tabi | 2008-03-12 13:47:30 [-0500]:
>Sebastian Siewior wrote:
>
>> I need to hold src & dst each with one and two bytes makes four
>> channels. And then I need one for normal transfers. So I guess I have to
>> talk to my HW ppl that we have to change something :)
>
>What kind of driver are you writing that needs four simultaneous DMA transfers?
Multiple drivers and those transfers may or may not happen
simultaneously. I have an USB driver that does slave dma only. For that
one I need the normal memcpy. Than there is the FPGA. That one gives me
a few components, for instance a few SPI channels. Every SPI channel has
two FIFOs, one for write and one for read. Those FIFOs have either 8, 16
or 32 bits. For those few I need the (different) [S|D]AHTS bits. I thing
you have the picture.
Now. My understanding of the DMA engine API is that multiple clients may
use the same channel simultaneously and they rebalence oneself. The xHE
bits are one per channel so the USB driver can't share the DMA channel
with the SPI driver.
In order to share them, I have to lock a channel, set the required bits
and after the transfer is done, the channel could be unlocked again.
Locking channels isn't currently possible because everyone can call
dma_async_client_chan_request() and get every channel that is suitable.
Adding DMA_MEMCPY_HOLD_[S|D]_{8|16|32} creates more possibilities than
available channel. A nicer solution would be to add DMA_MEMCPY_HOLD and
set the required bits for every request but this is unfortunately not
possible.
What is left... Ah I could lock the channel via DMA_RESOURCE_REMOVED, do
my transfer and then give it back. The channels are not freed
immediately so transfers from the interrupt handler could be
problematic.
Do you recommend another solution? Or did I miss an important part of
the API that solves this kind of problem.
>Timur Tabi
>Linux kernel developer at Freescale
Sebastian
^ permalink raw reply
* Early Debug message on MPC8568MDS
From: mike zheng @ 2008-03-12 20:46 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
How can I enable the early debug message on 2.6.23 kernel for
MPC8568MDS board? What is the first line shall be displayed on the
serial port? The board uses the first port of UART, where does it
defined?
Thanks for your help,
Mike
^ permalink raw reply
* Re: Using the loop feature of the DMA controller on MPC8544 DS
From: Timur Tabi @ 2008-03-12 20:49 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080312204451.GA11426@Chamillionaire.breakpoint.cc>
Sebastian Siewior wrote:
> Do you recommend another solution? Or did I miss an important part of
> the API that solves this kind of problem.
Well, I need to solve this problem myself, but I wasn't planning on doing it for
a while since I have a higher priority assignment at the moment. My 8610 sound
driver does DMA all on its own and completely ignores Zhang's driver, so I need
to fix that.
Unfortunately, I'm not familiar with Zhang's driver at all (it's changed too
much since I last looked at it), so I don't know what the *best* way is. For my
sound driver, I don't even know if I'll be able to leverage Zhang's driver at
all, since I need to use a specific DMA channel, and I need to control each of
the link descriptors. Zhang's driver abstracts DMA too much. So all I was
going to do is come up with a way to reserve channels.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Early Debug message on MPC8568MDS
From: mike zheng @ 2008-03-12 20:52 UTC (permalink / raw)
To: linuxppc-dev
Hello,
How can I enable the early debug message on 2.6.23 kernel for
MPC8568MDS board? What is the first line shall be displayed on the
serial port? The board uses the first port of UART, where does it
defined?
Thanks for your help,
Mike
^ 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