headers
Sean MacLennan | 1 Jan 2011 23:06
Picon
Favicon
Gravatar

So long and thanks for all the fish.

Happy New Year!

I didn't survive the latest round of layoffs at Pika. So in two weeks
the smaclennan <at> pikatech.com email will be dead. I also will no longer
have access to a Warp.

I would like to thank all the people on this list that helped me with
with the PPC. Everybody gave freely of their time and experience. I
really appreciate all the help, it made working on the Warp very
enjoyable.

If you need to contact me for whatever reason, just use the reply
address on this email (seanm <at> seanm.ca). Who knows, maybe I will get
another job working with the PPC and we shall meet again!

Cheers,
   Sean
Permalink | Reply | 0 comments |
headers
K.Prasad | 2 Jan 2011 13:54
Picon

Re: ppc_set_hwdebug vs ptrace_set_debugreg

On Thu, Dec 16, 2010 at 06:07:47PM +0100, Andreas Schwab wrote:
> "K.Prasad" <prasad <at> linux.vnet.ibm.com> writes:
> 
> > How about the revised patch below? It is only compile-tested; have you
> > got a quick test case that I can run?
> 
> It crashes the kernel when running the watch-vfork test.
> 
> Andreas.
>

Hi Andreas,
	I tried running it multiple times but saw no crash (or error
messages in dmesg). Can you send me the crash logs? What's the behaviour
when the testcase is run on an unpatched kernel?

The watch-vfork test actually fails on my system (4 unexpected failures)
irrespective of the kernel containing the patch or not.

Thanks,
K.Prasad
P.S.: I'd been on vacation and couldn't look at this issue during then.
Permalink | Reply | 0 comments |
headers
Andreas Schwab | 2 Jan 2011 15:58

Re: ppc_set_hwdebug vs ptrace_set_debugreg

"K.Prasad" <prasad <at> linux.vnet.ibm.com> writes:

> The watch-vfork test actually fails on my system (4 unexpected failures)

It should pass all four tests.  If gdb cannot even set a watchpoint it
cannot trigger the crash, of course.

Andreas.

--

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Permalink | Reply | 0 comments |
headers
acrux | 3 Jan 2011 13:08
Picon
Favicon

PATA_WINBOND lost interrupt - linux-2.6.36.2 - ppc64

hi,
there is a problem using new pata drivers with an old IBM Intellistation POWER 275  (9114-275 pSeries POWER4+).
These boxes are equipped with an IDE dvd-rom drive (PATA_WINBOND driver). 
0000:00:03.1 IDE interface: Symphony Labs SL82c105 (rev 05)

I can report, instead, that the old ide-cd driver BLK_DEV_SL82C105 (i tested the same scenario but with
linux-2.6.32.7) works fine. Obviously it happens only when boot or try to read from the dvdrom drive.

[...]
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: CDB: Xdread, Read track info: 52 01 00 00 00 01 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
         res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
sr0: CDROM (ioctl) error, command: Xdread, Read track info 52 01 00 00 00 01 00 00 20 00
sr: Sense Key : Aborted Command [current] [descriptor]
sr: Add. Sense: No additional sense information
ata1: lost interrupt (Status 0x50)
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
sr 1:0:0:0: [sr0] CDB: Xpwrite, Read disk info: 51 00 00 00 00 00 00 00 20 00
ata1.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 16416 in
         res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for MWDMA2
ata1: EH complete
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 3 Jan 2011 14:49

[PATCH 02/32] powerpc/cell: use system_wq in cpufreq_spudemand

With cmwq, there's no reason to use a separate workqueue in
cpufreq_spudemand.  Use system_wq instead.  The work items are already
sync canceled on stop, so it's already guaranteed that no work is
running when spu_gov_exit() is entered.

Signed-off-by: Tejun Heo <tj <at> kernel.org>
Cc: Arnd Bergmann <arnd <at> arndb.de>
Cc: linuxppc-dev <at> lists.ozlabs.org
Cc: Dave Jones <davej <at> redhat.com>
Cc: cpufreq <at> vger.kernel.org
---
Only compile tested.  Please feel free to take it into the subsystem
tree or simply ack - I'll route it through the wq tree.

Thanks.

 arch/powerpc/platforms/cell/cpufreq_spudemand.c |   20 +++-----------------
 1 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index 968c1c0..d809836 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
 <at>  <at>  -39,8 +39,6  <at>  <at>  struct spu_gov_info_struct {
 };
 static DEFINE_PER_CPU(struct spu_gov_info_struct, spu_gov_info);

-static struct workqueue_struct *kspugov_wq;
-
 static int calc_freq(struct spu_gov_info_struct *info)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roman Fietze | 3 Jan 2011 14:45
Picon
Favicon

PowerPC MPC5200B ATA MWDMA regression

Hello,

When merging more recent kernel versions, tried that using v2.6.35 and
v2.6.36, into our tree (branched at v2.6.34), I detected, that MWDMA2
on the HW listed in the subject does no longer work.

So I bisected that using the original, standard kernel tree using a
minimum config using

   git bisect start v2.6.35 v2.6.34

The final result is:

360ff7833098e944e5003618b03894251e937802 is the first bad commit
commit 360ff7833098e944e5003618b03894251e937802
Author: Tejun Heo <tj <at> kernel.org>
Date:   Mon May 10 21:41:42 2010 +0200

    libata-sff: separate out BMDMA qc_issue

...

I double checked the failure with the latest torvalds/master as well
(b518a64983cbf2ff31), still the same issue.

The HW is an own board very close to the original Freescale
Lite5200/Lite5200B. The relevant part of the device tree source file
contains "mwdma-mode = <2>;" inside the ata section.

In the bad case the log always shows (the exact drive or drive type
(Continue reading)

Permalink | Reply | 0 comments |
headers
acrux | 3 Jan 2011 15:27
Picon
Favicon

Re: PowerPC MPC5200B ATA MWDMA regression

hi,

my MPC5200B (Genesi EFIKA PowerPC) works fine with linux-2.6.36.2 and these two patches:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-December/087632.html
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-December/087633.html

i hope this helps,
cheers
--acrux

--

-- 
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/
Permalink | Reply | 0 comments |
headers
Jiri Kosina | 3 Jan 2011 16:10
Picon

Re: [PATCH 1/5]arch:powerpc:platforms:85xx:mpc85xx_mds.c Typo change singal to signal

On Thu, 30 Dec 2010, Justin P. Mattock wrote:

> The patches below fixes a typo "singal" to "signal". Please let me 
> know if anything needs to be changed.
> 
> Signed-off-by: Justin P. Mattock <justinmattock <at> gmail.com>
> 
> ---
>  arch/powerpc/platforms/85xx/mpc85xx_mds.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> index aa34cac..747d1ee 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
>  <at>  <at>  -309,7 +309,7  <at>  <at>  static void __init mpc85xx_mds_qe_init(void)
>  			/* P1021 has pins muxed for QE and other functions. To
>  			 * enable QE UEC mode, we need to set bit QE0 for UCC1
>  			 * in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
> -			 * and QE12 for QE MII management singals in PMUXCR
> +			 * and QE12 for QE MII management signals in PMUXCR
>  			 * register.
>  			 */

Applied.

--

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Zyngier | 3 Jan 2011 16:57

[PATCH] Make auto-loading of therm_pm72 possible

The therm_pm72 driver, used on the PowerMac G5 range, cannot be
auto-loaded, since the driver itself creates both the device node
and the driver instance.

Moving the device node creation to the platform setup code and
adding the necessary MODULE_DEVICE_TABLE() information allows the
driver to be automatically loaded by udev on any semi-modern
distribution.

It "fixes" a major source of problem on G5 machines where the
driver wasn't explicitely loaded by default, and the system
would automatically shutdown under load.

Tested on an Xserve G5.

Signed-off-by: Marc Zyngier <maz <at> misterjones.org>
Cc: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
---
 arch/powerpc/platforms/powermac/setup.c |    9 +++++++++
 drivers/macintosh/therm_pm72.c          |   30 +++++-------------------------
 2 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 9deb274..d5aceb7 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
 <at>  <at>  -506,6 +506,15  <at>  <at>  static int __init pmac_declare_of_platform_devices(void)
 		of_platform_device_create(np, "smu", NULL);
 		of_node_put(np);
 	}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Wood | 3 Jan 2011 20:51
Favicon

Re: [RFC] MPIC Bindings and Bindings for AMP Systems

On Thu, 23 Dec 2010 15:33:25 -0700
Grant Likely <grant.likely <at> secretlab.ca> wrote:

> On Thu, Dec 23, 2010 at 03:49:54PM -0600, Meador Inge wrote:
> > How do you
> > see this working in terms of processing the data?  It seems like we
> > are going to have to be aware of N values instead of 1, which seems
> > worse.
> 
> This argument has been rehashed many times, but it basically comes
> down to compatible values should ideally be anchored to a real
> implemented device, not to a family of devices, or to an unversioned
> specification.

Freescale MPICs do have version numbers (version registers, even).  We
should put that version (possibly along with a compatible version) in
the compatible, though, for blocks such as this which don't include the
main MPIC registers and thus the version registers.

> In practise, the implementation doesn't actually look any different
> except that the 'reference' version specifies a specific
> implementation instead of a generic name.  To use a concrete example,
> if there are two parts using this MPIC, like the freescale p2040 and
> p4080, and say for argument that the p2040 was implemented first, then
> the compatible values would look like:
> 
> for the p2040:   compatible = "fsl,p2040-msgr";
> for the p4080:   compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";

While I don't think it affected the message unit, p4080 rev 1 has a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane