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
* Steven Rostedt rost...@goodmis.org 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 torva...@linux-foundation.org
Date: Fri Feb 13
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 feature
Added missing set_bit() to disable data transfer when a memchange notification
is handled
Signed-off-by: Thomas Klein tkl...@de.ibm.com
---
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.h
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 ... but
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
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
On Thu, Feb 19, 2009 at 7:09 AM, Grzegorz Bernacki g...@semihalf.com 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.
--
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 were
On Thu, Feb 19, 2009 at 12:58 AM, Dushara Jayasinghe
dusha...@optiscan.com 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 =
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 MPC837X
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, February 18,
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 bug check
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
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,
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)
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, Version:
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
On Feb 17, 2009, at 11:47 PM, d...@datangmobile.cn d...@datangmobile.cn
wrote:
From: Da Yu d...@datangmobile.cn
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
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,
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 hack when
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
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
.org] On Behalf Of
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
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.
--
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
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
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
$
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 nodes to
-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 when the data
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 of
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-Config:
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
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
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 ga...@kernel.crashing.org
---
arch/powerpc/kernel/pci-common.c |2
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
* 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 ga...@kernel.crashing.org
* 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 devices
* 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 fixed.
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 scott.coul...@cyclone.com
Kumar,
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]
-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: [RFC
-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.org
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 mi...@neuling.org
---
Benh: this is for 2.6.30, but would be nice to be back in 2.6.27/28/29
too.
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
On Fri, Feb 20, 2009 at 5:44 AM, Scott Wood scottw...@freescale.com 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
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
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 found
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
49 matches
Mail list logo
