Sorry, I'm a late comer here, but I might have an idea. First off, I don't see
below what
kernel version you are using? I may have missed it somewhere.
[dj]
Sorry I should have mentioned that earlier. I'm using 2.6.29-rc5 (pulled couple
of days ago)
Hmm, well, the first thing I catch is this is
Hi Dushara,
Sorry, I'm a late comer here, but I might have an idea. First off, I don't
see below what
kernel version you are using? I may have missed it somewhere.
> The devices are successfully probed, but I'm getting this error on the
> debug console:
>
> [7.119389] m...@24520:00 not foun
Hi David,
> I should probably do this on sparc64 too.
>
> Why don't we just change this thing to CONFIG_64BIT?
I agree. How does this look?
Anton
--
On PowerPC we allocate large boot time hashes on node 0. This leads to
an imbalance in the free memory, for example on a 64GB box (4 x 16GB
node
On Fri, Feb 20, 2009 at 5:44 AM, Scott Wood wrote:
> See this thread:
> http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068467.html
>
Great, that's helped. Thanks Scott.
Now, I'm seeing these boot messages:
f0010d40:00 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth
When we introduced VSX, we changed the way FPRs are stored in the
thread_struct. Unfortunately we missed the load/store float double
alignment handler code when updating how we access FPRs in the
thread_struct.
Below fixes this and merges the little/big endian case.
Signed-off-by: Michael Neu
lfiwzx is a new floating point load instruction in 2.06 that needs an
alignment handler for Linux.
Turns out to be the worlds easiest handler to add.
Signed-off-by: Michael Neuling
---
Benh: this is for 2.6.30, but would be nice to be back in 2.6.27/28/29
too.
arch/powerpc/kernel/align.c |
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Friday, February 20, 2009 0:52 AM
> To: Zang Roy-R61911
> Cc: Ira Snyder; Arnd Bergmann; Jan-Bernd Themann;
> net...@vger.kernel.org; Rusty Russell;
> linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.o
> -Original Message-
> From: Ira Snyder [mailto:i...@ovro.caltech.edu]
> Sent: Friday, February 20, 2009 0:15 AM
> To: Zang Roy-R61911
> Cc: linux-ker...@vger.kernel.org; linuxppc-dev@ozlabs.org;
> net...@vger.kernel.org; Rusty Russell; Arnd Bergmann;
> Jan-Bernd Themann
> Subject: Re
Yes I now base it on mpc834x_mds.c and it works (almost) :-(
The devices are successfully probed, but I'm getting this error on the debug
console:
[7.119389] m...@24520:00 not found
[7.161370] eth0: Could not attach to PHY
[7.209600] IP-Config: Failed to open eth0
[7.258879] IP-C
Hi Scott,
Your issue may come from data setup (or corruption) instead of code path:
babbling error may occurs when a TSEC TX descriptor hasn't its "last frame"
bit set or when the data length is greated than max frame length.
--
sj
2009/2/19 Scott Coulter
>
>
> Kumar,
>
> >
> > can't think of
* Kumar Gala | 2009-02-19 14:49:17 [-0600]:
>Now that we set archdata for of_platform and platform devices via
>platform_notify() we no longer need to special case having a NULL device
>pointer or NULL archdata. It should be a driver error if this condition
>shows up and the driver should be fixe
* Kumar Gala | 2009-02-19 14:49:16 [-0600]:
>Since a number of powerpc chips are SoCs we end up having dma-able
>devices that are registered as platform or of_platform devices. We need
>to hook the archdata to setup proper dma_ops for these devices.
>
>In the short term the majority of these devi
* Kumar Gala | 2009-02-19 14:49:15 [-0600]:
>This will allow us to remove the ppc32 specific checks in get_dma_ops()
>that defaults to dma_direct_ops if the archdata is NULL. We really
>should always have archdata set to something going forward.
>
>Signed-off-by: Kumar Gala
Acked-by: Benjamin K
On Feb 19, 2009, at 2:49 PM, Kumar Gala wrote:
This will allow us to remove the ppc32 specific checks in
get_dma_ops()
that defaults to dma_direct_ops if the archdata is NULL. We really
should always have archdata set to something going forward.
Signed-off-by: Kumar Gala
---
arch/powerpc/k
This will allow us to remove the ppc32 specific checks in get_dma_ops()
that defaults to dma_direct_ops if the archdata is NULL. We really
should always have archdata set to something going forward.
Signed-off-by: Kumar Gala
---
arch/powerpc/kernel/pci-common.c |2 +-
1 files changed, 1 ins
Now that we set archdata for of_platform and platform devices via
platform_notify() we no longer need to special case having a NULL device
pointer or NULL archdata. It should be a driver error if this condition
shows up and the driver should be fixed.
Signed-off-by: Kumar Gala
---
arch/powerpc/
Since a number of powerpc chips are SoCs we end up having dma-able
devices that are registered as platform or of_platform devices. We need
to hook the archdata to setup proper dma_ops for these devices.
In the short term the majority of these devices only need the
direct_dma_ops as the platforms
On Thu, Feb 19, 2009 at 05:47:22PM +1100, Daniel Ng wrote:
> Or, perhaps it is ok for the 'of_platform' bus to have no devices on
> it, and so I might be using the wrong bus?? Why would this be?
>
> Or is it something else??
>
> Either way, I still get the following boot error message:
>
> IP-Co
On Thu, Feb 19, 2009 at 03:26:41PM +1100, Dushara Jayasinghe wrote:
> I get the following error during the boot sequence:
>
> IP-Config: Device `eth0' not found
>
> I also found that both gfar_init (in gianfar.c) and gfar_mdio_init (in
> gianfar_mii.c) are called but the probe handlers of either
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: February 19, 2009 12:04PM
> >
> > Your issue may come from data setup (or corruption) instead of code
> > path: babbling error may occurs when a TSEC TX descriptor hasn't its
> > "last frame" bit set or whe
On Thu, Feb 19, 2009 at 10:19:05AM -0600, Kumar Gala wrote:
>
> On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote:
>
>> On MPC837X CPUs Dual-Role USB isn't always available (for example DR
>> USB pins can be muxed away to eSDHC).
>>
>> U-Boot adds status = "disabled" property into the DR USB node
On Thu, 2009-02-19 at 17:21 +0530, Vijay Nikam wrote:
> Also is it possible to compile device tree on Linux host and genreate
> dtb for powerpc ? ? ? If yes, then how ? ? ? please let me know ...
> thanks ...
Uh, get a copy of the DTC using:
$ git clone git://git.jdl.com/software/dtc.git
OK, here is this patch again. You didn't think I'd let a 2% performance
improvement be forgotten? :)
Anyway, patch won't work well on architecture without lwsync, but I won't
bother fixing that kind of thing and making it merge worthy until you
guys say something positive about it.
20 runs of tbe
Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5 than
using sync for smp_mb. Although it takes more instructions.
Running tbench with 4 clients on my 4 core G5 (20 times) gives the
following:
unpatched AVG=920.33 STD=2.36
patched AVG=921.27 STD=2.77
So not a big imp
Setting G5's cpu frequency transition latency to CPUFREQ_ETERNAL stops
ondemand governor from working. I measured the latency using sched_clock
and haven't seen much higher than 11000ns, so I set this to 12000ns for
my configuration. Possibly other configurations will be different?
Ideally the gene
On Feb 19, 2009, at 10:48 AM, sjoy...@wanadoo.fr wrote:
Hi Scott,
Your issue may come from data setup (or corruption) instead of code
path: babbling error may occurs when a TSEC TX descriptor hasn't its
"last frame" bit set or when the data length is greated than max
frame length.
--
On Thu, Feb 19, 2009 at 10:51:43AM -0600, Kumar Gala wrote:
>
> On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote:
>
>>
>>
>>> -Original Message-
>>> From:
>>> linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org
>>> [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs
>>>
On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote:
-Original Message-
From:
linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs
.org] On Behalf Of Kumar Gala
Sent: Thursday, February 19, 2009 0:47 AM
To: Ira Snyd
On Thu, Feb 19, 2009 at 09:48:04PM +1030, Rusty Russell wrote:
> On Thursday 19 February 2009 03:08:35 Ira Snyder wrote:
> > On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote:
> > > don't restrict yourself to 32 feature bits (only PCI does this, and
> > > they're
> > > going to have to
On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote:
On MPC837X CPUs Dual-Role USB isn't always available (for example DR
USB pins can be muxed away to eSDHC).
U-Boot adds status = "disabled" property into the DR USB nodes to
indicate that we must not try to configure or probe Dual-Role USB,
o
On Feb 17, 2009, at 11:47 PM, > wrote:
From: Da Yu
Date: Wed, 18 Feb 2009 19:58:20 +0800
Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC
(2.6.25-2.6.28)
Description: The interrupt pending register is write 1 clear. If
there are more than one external interrupts pendin
On Feb 6, 2009, at 8:00 AM, Timur Tabi wrote:
The i2c_wait() function is using wait_event_interruptible_timeout()
to wait for
the I2C controller to signal that it has completed an I2C bus
operation. If
the process that causes the I2C operation terminated abruptly, the
wait will
be interru
>
> What specific processor & rev are you running on?
>
I've only been running the modified kernel with the added BUG_ON() code
on the 8568E processor, but I've seen the errors reported on the 8572E
as well.
According to the u-boot startup:
8568E, Version: 1.1, (0x807d0011)
Core: E500, Versio
On Feb 19, 2009, at 10:17 AM, Scott Coulter wrote:
Kumar,
can't think of any. How about adding a BUG_ON() in the tx path to
see
if the buffer size > MTU and re-run your tests.
So, here are the checks I've tried in gfar_start_xmit():
BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE)
BUG_ON
On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote:
On MPC837X CPUs Dual-Role USB isn't always available (for example DR
USB pins can be muxed away to eSDHC).
U-Boot adds status = "disabled" property into the DR USB nodes to
indicate that we must not try to configure or probe Dual-Role USB,
o
Turns out the problem was with the PSDMR register. We had a cas
latency of 3 and the memory stick required 2. Also, the MPTPR register
had a value of 0x1e00 and we changed it to 0x1f00. We use ECC memory
sticks.
Those 2 changes got rid of the error in the buffer descriptor
ready/empty bits. The in
Kumar,
>
> can't think of any. How about adding a BUG_ON() in the tx path to see
> if the buffer size > MTU and re-run your tests.
>
So, here are the checks I've tried in gfar_start_xmit():
BUG_ON(skb->len > DEFAULT_RX_BUFFER_SIZE)
BUG_ON(skb->len > priv->regs->maxfrm)
Neither produces a b
On Thu, Feb 19, 2009 at 02:10:08PM +0800, Zang Roy-R61911 wrote:
>
>
> > -Original Message-
> > From:
> > linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs.org
> > [mailto:linuxppc-dev-bounces+tie-fei.zang=freescale@ozlabs
> > .org] On Behalf Of Ira Snyder
> > Sent: Wednesday,
On MPC837X CPUs Dual-Role USB isn't always available (for example DR
USB pins can be muxed away to eSDHC).
U-Boot adds status = "disabled" property into the DR USB nodes to
indicate that we must not try to configure or probe Dual-Role USB,
otherwise we'll break eSDHC support on targets with MPC837
On Thu, Feb 19, 2009 at 12:58 AM, Dushara Jayasinghe
wrote:
> I based my board specific file on mpc834x_itx.c which had
>
> static struct of_device_id __initdata mpc834x_itx_ids[] = {
> { .compatible = "fsl,pq2pro-localbus", },
> { .compatible = "simple-bus", },
>
On Sun, 2009-02-15 at 01:00 +1100, Michael Ellerman wrote:
> On Fri, 2009-02-13 at 14:45 -0600, Dave Kleikamp wrote:
> > When identify_cpu() is called a second time with a logical PVR, it only
> > copies a subset of the cpu_spec structure to avoid overwriting the
> > performance monitor fields that
On Thu, Feb 19, 2009 at 7:09 AM, Grzegorz Bernacki wrote:
> Hi Grant,
>
> Could you tell me when you are going to apply this patch
> and "Defconfig for mpc5200 updates" patch into your repository?
soon. Busy putting out another fire at the moment, but I'll pick it up soon.
g.
--
Grant Likely
Hi Grant,
Could you tell me when you are going to apply this patch
and "Defconfig for mpc5200 updates" patch into your repository?
Thanks,
Grzesiek
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Geert Uytterhoeven wrote:
> When running 2.6.29-rc5+ on PS3 (ppc64), I got the following BUG once during
> bootup:
>
> | Freeing unused kernel memory: 3436k freed
> | BUG: MAX_STACK_TRACE_ENTRIES too low!
> | turning off the locking correctness validator.
> | Call Trace:
> | [c6e1b640] [c0
When running 2.6.29-rc5+ on PS3 (ppc64), I got the following BUG once during
bootup:
| Freeing unused kernel memory: 3436k freed
| BUG: MAX_STACK_TRACE_ENTRIES too low!
| turning off the locking correctness validator.
| Call Trace:
| [c6e1b640] [c000f850] .show_stack+0x6c/0x16c (un
> Because dtc will generate phandles automatically when you reference the
> node with the & operator.
Yes the same statement I found in dts-bindings for gpio txt, sorry I
missed it somehow ...
> Do you want your changes to ever make it into the upstream kernel?
Yes I would like to do that ... bu
Added missing set_bit() to disable data transfer when a memchange notification
is handled
Signed-off-by: Thomas Klein
---
diff -Nurp -X dontdiff linux-2.6.29-rc4/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.29-rc4/drivers/net/ehea/ehea.h2009-02-18 16:59:54.00
On Thursday 19 February 2009 03:08:35 Ira Snyder wrote:
> On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote:
> > don't restrict yourself to 32 feature bits (only PCI does this, and they're
> > going to have to hack when we reach feature 32).
>
> There isn't any problem adding more feat
* Steven Rostedt wrote:
> Ingo and Benjamin,
>
> As discussed, I made a branch called mainline/function-graph-tracer
> based off of Linus's commit:
>
> commit d2f8d7ee1a9b4650b4e43325b321801264f7c37a
> Author: Linus Torvalds
> Date: Fri Feb 13 15:31:30 2009 -0800
>
> Linux 2.6.29-rc5
I must have made a mistake when I tested the previous patch, I
discovered later it still had errors:
- I had accidentally removed the base address in the fec_mpc52xx driver.
- The priv->phydev pointer was sometimes not initialized (NULL) but
still passed by the fec_mpc52xx driver, this pointer is t
50 matches
Mail list logo
