* Re: MPC83xx watchdog reset board dead lock
From: Norbert van Bolhuis @ 2009-06-17 12:16 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: Linux PPC
In-Reply-To: <c384c5ea0906170309j6fdf28f5qc38129e82649ef28@mail.gmail.com>
Hi Leon,
...
> Most designs do not care about the watchdog, or only pet in their
> non-critical paths... That's not what the watchdog is for.
> Also, I don't care about u-boot.
>
> I care about a design where the Flash NOR could be in write mode at
> any time when the watchdog triggers, when the hardware is running
> critical software.
> No lifes in danger when it happens, only jobs, so no biggy :-)
>
true, I was just looking from SW/u-boot perspective.
Ideally the dead-lock is prevented on board/HW level.
>
> David has been helpful in thinking this through, but we followed-up
> offline, and we independently came up with the following design, so
> this must therefore work (disclaimer applies).
>
> Note, it DOES require a NOR flash that has a RY/BUSY# pin.
>
> Quoting David Hawkins, who gave a very clear explanation:
> ---
> How about using the RDY/BUSY# pin on the Flash in conjunction
> with PORESET#. If the flash is busy, then the processor gets
> PORESET#, otherwise, the HRESET# just does its normal thing.
>
> That way PORESET# only ever asserts when you have the
> combo of the Flash being busy and HRESET# asserting.
>
> <...>
>
> If you have the Flash BUSY# signal, then this scheme works
> great, since using HRESET# low and BUSY# low to create a
> PORESET# source is only active until the Flash RESET#
> is asserted long enough for it to get out of the BUSY#
> state and back into read-array mode.
> ---
>
> Kudos to David.
>
> I'll be testing the design tomorrow on the reference board, I'll
> report results in this thread.
>
Interesting.
Looking forward to the results.
---
N. van Bolhuis.
^ permalink raw reply
* Re: [BUG] lib/kernel_lock.c:126 with cgroups regression ltp tests
From: Sachin Sant @ 2009-06-17 12:16 UTC (permalink / raw)
To: michael
Cc: linux-kernel, chrisw, linuxppc-dev, Al Viro, menage, abogani,
Balbir Singh
In-Reply-To: <1245237613.4269.13.camel@concordia>
Michael Ellerman wrote:
> On Wed, 2009-06-17 at 16:21 +0530, Sachin Sant wrote:
>
>> While executing cgroups regression tests from LTP May 2009
>> release on a Power6 box came across the following bug.
>>
>
>
>> This is with 2.6.30-git10 (300df7dc89cc276377fc020704e34875d5c473b6)
>>
>
> Looks like 337eb00a2 missed some return paths in do_remount_sb()?
>
> $ git log -p -U13 337eb00a2c3a421999c39c94ce7e33545ee8baa7 fs/super.c
> commit 337eb00a2c3a421999c39c94ce7e33545ee8baa7
> Author: Alessio Igor Bogani <abogani@texware.it>
Thanks Michael.
The following submitted patch from Chris fixes this issue.
http://patchwork.kernel.org/patch/30675/
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Michael Ellerman @ 2009-06-17 12:26 UTC (permalink / raw)
To: mohan; +Cc: linuxppc-dev, Simon Horman, kexec, miltonm
In-Reply-To: <20090617115917.GD31595@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
On Wed, 2009-06-17 at 17:29 +0530, M. Mohan Kumar wrote:
> Do not inline putprops function
>
> With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
> kexec -l and kexec -p respectively). This happened after the patch "ppc64:
> cleanups" commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
> reverting each hunk and then found out that retaining following lines in
> fs2dt.c makes kexec/kdump work.
>
> -static unsigned *dt_len; /* changed len of modified cmdline
> - in flat device-tree */
>
> [....]
>
> - dt_len = dt;
>
> I don't have any clue why removing a unused variable would cause the kexec
> kernel to hang. After further investigation, I observed that if the putprops
> function is not inlined, kexec/kdump kernel would work even after removing
> the above lines.
>
> This patch directs gcc to not inline the putprops function. Now we could
> invoke kexec and kdump kernels.
What compiler version are you using? Does the behaviour change if you
use a newer/older compiler? It sounds to me like there's some deeper bug
and your patch is just papering over it.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
From: Paul Mackerras @ 2009-06-17 12:27 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, Peter Zijlstra, linux-kernel
In-Reply-To: <20090617120831.GB26454@elte.hu>
Ingo Molnar writes:
> ah, it does this:
>
> /*
> * This is here because we used to use l64 for 64bit powerpc
> * and we don't want to impact user mode with our change to ll64
> * in the kernel.
> */
> #if defined(__powerpc64__) && !defined(__KERNEL__)
> # include <asm-generic/int-l64.h>
> #else
> # include <asm-generic/int-ll64.h>
> #endif
>
> That's crappy really.
We were concerned that changing the userland-visible type of __u64
from unsigned long to unsigned long long, etc., would be breaking the
ABI, even if only in a small way - I thought it could possibly change
C++ mangled function names, for instance, and it would cause fresh
compile warnings on existing user code that prints __u64 with %lx,
which has always been the correct thing to do on ppc64.
A counter-argument would be, I guess, that __u64 et al. are purely for
use in describing the kernel/user interface, so we have a little more
latitude than with the type of e.g. u_int64_t. I dunno. I don't
recall getting much of an answer from the glibc guys about what they
thought of the idea of changing it.
Anyway, of the 64-bit architectures, alpha, ia64, and mips64 also have
__u64 as unsigned long in userspace, so this issue will still crop up
even if we change it on powerpc.
Paul.
^ permalink raw reply
* Trouble porting a USB gadget serial UDC driver from 2.6.14 to 2.6.27
From: Daniel Ng @ 2009-06-17 12:39 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm having trouble porting our in-house UDC driver to 2.6.27. It
originally worked on 2.6.14 as an CDC-ACM driver. The hardware
platform is a mpc8272-based board.
I notice a lot of changes since 2.6.14. For starters, instead of the
single serial.c file, there is now f_serial.c, u_serial.c and f_acm.c.
Currently, the UDC driver in 2.6.27 seems to work if I simply plug the
USB cable in between our gadget serial Linux device and a Windows PC.
However, if I unplug, then replug the cable, the 'Out' Endpoint seems
fine, but the 'In' Endpoint doesn't seem to come up properly.
In other words, data only seems to be getting through in the direction
from the PC to the gadget serial Linux device, but not vice versa.
Is there some sort of architecture document to show how the
f_serial.c, u_serial.c and f_acm.c files all fit together? I've
searched in the Documentation directory and I've read the
usb-gadget-serial docbook document but it doesn't really tell me this.
Also, it seems that for some reason composite.c is being compiled and
used, but my CDC-ACM gadget serial driver is *not* a composite driver.
Is it possible to prevent linking with this composite driver?
Cheers,
Daniel
^ permalink raw reply
* [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-17 12:51 UTC (permalink / raw)
To: netdev, Li Yang
Cc: Sachin P Sant, Stephen Rothwell, Linux-Kernel, Linuxppc-dev,
Linux-Next, Nathan Lynch, Balbir Singh
In-Reply-To: <1245048719.5239.10.camel@subratamodak.linux.ibm.com>
On Mon, 2009-06-15 at 12:22 +0530, Subrata Modak wrote:
> Hi Li/Nathan,
>
> On Thu, 2009-06-11 at 09:07 +0530, Subrata Modak wrote:
> > Hi Nathan,
> >
> > >On Wed, 2009-06-10 at 21:28 -0500, Nathan Lynch wrote:
> > >Subrata Modak <subrata@linux.vnet.ibm.com> writes:
> > >
> > > > On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > > >> Hi Subrata,
> > > >>
> > > >> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > > >> >
> > > >> > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > > >> > - ph = of_get_property(np, "tbi-handle", NULL);
> > > >> > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> > > >>
> > > >> You don't need this cast because of_get_property() returns "void *".
> > > >
> > > > Stephen,
> > > >
> > > > True. But without this gcc complains:
> > > >
> > > > CC [M] drivers/net/ucc_geth.o
> > > > drivers/net/ucc_geth.c: In function b\x18ucc_geth_probeb\x19:
> > > > drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
> > > > from pointer target type
> > >
> > > ph should be declared const phandle *. Look at other uses of
> > > of_get_property.
> > >
> >
> > Ok fine. Here is a revised patch again.
> >
> > Subject: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
> > Reference(s):
> > http://lkml.org/lkml/2009/6/4/241,
> > http://lkml.org/lkml/2009/6/10/338,
> >
> > Fix the following build error:
> >
> > drivers/net/ucc_geth.c: In function bucc_geth_probeb:
> > drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
> > drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once
> > drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
> > drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this function)
> > make[2]: *** [drivers/net/ucc_geth.o] Error 1
> >
> > Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> > ---
>
> Is there anything else to be done in this patch. If this is OK, can this
> be applied. I am not sure, but, i find Li Yang as the maintainer for
> this in linux*/MAINTAINERS file. Kindly let me know if this patch needs
> to be revisited for some other issue(s).
Li,
Any thoughts on this patch ?
Regards--
Subrata
>
> Regards--
> Subrata
>
> >
> > --- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10 11:58:39.000000000 -0500
> > +++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 22:28:13.000000000 -0500
> > @@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
> >
> > static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
> > {
> > + struct device_node *mdio;
> > + const phandle *ph;
> > struct device *device = &ofdev->dev;
> > struct device_node *np = ofdev->node;
> > struct net_device *dev = NULL;
> >
> > ---
> > Regards--
> > Subrata
> >
^ permalink raw reply
* [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Subrata Modak @ 2009-06-17 12:53 UTC (permalink / raw)
To: David Brownell
Cc: Sachin P Sant, Randy Dunlap, Arnd Bergmann, Stephen Rothwell,
linux-usb, Linux-Kernel, Linuxppc-dev, Linux-Next, kernel
In-Reply-To: <1245048679.5239.8.camel@subratamodak.linux.ibm.com>
On Mon, 2009-06-15 at 12:21 +0530, Subrata Modak wrote:
> On Fri, 2009-06-12 at 15:05 +0530, Subrata Modak wrote:
> > On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote:
> > > On Friday 05 June 2009, Subrata Modak wrote:
> > > > Correct, it fixes the issue. However, since few changes might have gone
> > > > to the Kconfig, the patch does not apply cleanly. Below is the patch, just
> > > > a retake of the earlier one, but on the latest code.
> > >
> > > And it got mangled a bit along the way. Plus, the original one
> > > goofed up Kconfig dependency displays ... both issues fixed in
> > > this version, against current mainline GIT.
> > >
> > > If someone can verify all four PPC/OF/OHCI configs build on
> > > on PPC64, I'm OK with it.
> > >
> > > - Dave
> >
> > Dave,
> >
> > Sorry for being late. The patch fixes the issue on the latest git for
> > PPC64. Infact, the whole drivers/usb/host/ builds just fine:
> >
> > linux-2.6 # make drivers/usb/host/
> > CHK include/linux/version.h
> > CHK include/linux/utsrelease.h
> > SYMLINK include/asm -> include/asm-powerpc
> > CALL scripts/checksyscalls.sh
> > CC drivers/usb/host/ohci-hcd.o
> > CC drivers/usb/host/pci-quirks.o
> > CC drivers/usb/host/uhci-hcd.o
> > LD drivers/usb/host/built-in.o
> > CC [M] drivers/usb/host/isp116x-hcd.o
> > CC [M] drivers/usb/host/u132-hcd.o
> >
> > You can check in the patch now.
>
> Dave,
>
> Have you checked in this patch ? Or, does it require some more
> modification/updates from somebody´s side ?
>
Dave,
Would you consider checking in this patch ?
Regards--
Subrata
> Regards--
> Subrata
>
> >
> > Regards--
> > Subrata
> >
> > >
> > >
> > > ========== CUT HERE
> > > From: Arnd Bergmann <arnd@arndb.de>
> > > Subject: fix build failure for PPC64 randconfig [usb/ohci]
> > >
> > > We could just make the USB_OHCI_HCD_PPC_OF option implicit
> > > and selected only if at least one of USB_OHCI_HCD_PPC_OF_BE
> > > and USB_OHCI_HCD_PPC_OF_LE are set.
> > >
> > > [ dbrownell@users.sourceforge.net: fix patch manglation and dependencies ]
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Resent-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> > > Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> > > ---
> > > drivers/usb/host/Kconfig | 29 +++++++++++++++--------------
> > > 1 file changed, 15 insertions(+), 14 deletions(-)
> > >
> > > --- a/drivers/usb/host/Kconfig
> > > +++ b/drivers/usb/host/Kconfig
> > > @@ -180,26 +180,27 @@ config USB_OHCI_HCD_PPC_SOC
> > > Enables support for the USB controller on the MPC52xx or
> > > STB03xxx processor chip. If unsure, say Y.
> > >
> > > -config USB_OHCI_HCD_PPC_OF
> > > - bool "OHCI support for PPC USB controller on OF platform bus"
> > > - depends on USB_OHCI_HCD && PPC_OF
> > > - default y
> > > - ---help---
> > > - Enables support for the USB controller PowerPC present on the
> > > - OpenFirmware platform bus.
> > > -
> > > config USB_OHCI_HCD_PPC_OF_BE
> > > - bool "Support big endian HC"
> > > - depends on USB_OHCI_HCD_PPC_OF
> > > - default y
> > > + bool "OHCI support for OF platform bus (big endian)"
> > > + depends on USB_OHCI_HCD && PPC_OF
> > > select USB_OHCI_BIG_ENDIAN_DESC
> > > select USB_OHCI_BIG_ENDIAN_MMIO
> > > + ---help---
> > > + Enables support for big-endian USB controllers present on the
> > > + OpenFirmware platform bus.
> > >
> > > config USB_OHCI_HCD_PPC_OF_LE
> > > - bool "Support little endian HC"
> > > - depends on USB_OHCI_HCD_PPC_OF
> > > - default n
> > > + bool "OHCI support for OF platform bus (little endian)"
> > > + depends on USB_OHCI_HCD && PPC_OF
> > > select USB_OHCI_LITTLE_ENDIAN
> > > + ---help---
> > > + Enables support for little-endian USB controllers present on the
> > > + OpenFirmware platform bus.
> > > +
> > > +config USB_OHCI_HCD_PPC_OF
> > > + bool
> > > + depends on USB_OHCI_HCD && PPC_OF
> > > + default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE
> > >
> > > config USB_OHCI_HCD_PCI
> > > bool "OHCI support for PCI-bus USB controllers"
> > >
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Neil Horman @ 2009-06-17 13:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, kexec, miltonm, Simon Horman
In-Reply-To: <1245241595.4269.15.camel@concordia>
On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote:
> On Wed, 2009-06-17 at 17:29 +0530, M. Mohan Kumar wrote:
> > Do not inline putprops function
> >
> > With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
> > kexec -l and kexec -p respectively). This happened after the patch "ppc64:
> > cleanups" commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
> > reverting each hunk and then found out that retaining following lines in
> > fs2dt.c makes kexec/kdump work.
> >
> > -static unsigned *dt_len; /* changed len of modified cmdline
> > - in flat device-tree */
> >
> > [....]
> >
> > - dt_len = dt;
> >
> > I don't have any clue why removing a unused variable would cause the kexec
> > kernel to hang. After further investigation, I observed that if the putprops
> > function is not inlined, kexec/kdump kernel would work even after removing
> > the above lines.
> >
> > This patch directs gcc to not inline the putprops function. Now we could
> > invoke kexec and kdump kernels.
>
> What compiler version are you using? Does the behaviour change if you
> use a newer/older compiler? It sounds to me like there's some deeper bug
> and your patch is just papering over it.
>
Agreed, this doesn't make any sense. Try changing the compiler version to see if
the problem goes away or stops. It might also be worthwhile to dump the
contents of the device tree at the start and end of the kexec process. If the
changing of how a function is inlined is causing a hang, its likely changing how
the putprops function is writing information to the device tree. Understanding
what that change is will likely provide clues to how the code has changed.
Neil
> cheers
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Kumar Gala @ 2009-06-17 13:07 UTC (permalink / raw)
To: subrata
Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
Linuxppc-dev, Linux-Next, Nathan Lynch, Li Yang, Balbir Singh
In-Reply-To: <1245243097.4870.3.camel@subratamodak.linux.ibm.com>
On Jun 17, 2009, at 7:51 AM, Subrata Modak wrote:
> On Mon, 2009-06-15 at 12:22 +0530, Subrata Modak wrote:
>> Hi Li/Nathan,
>>
>> On Thu, 2009-06-11 at 09:07 +0530, Subrata Modak wrote:
>>> Hi Nathan,
>>>
>>>> On Wed, 2009-06-10 at 21:28 -0500, Nathan Lynch wrote:
>>>> Subrata Modak <subrata@linux.vnet.ibm.com> writes:
>>>>
>>>>> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
>>>>>> Hi Subrata,
>>>>>>
>>>>>> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak =
<subrata@linux.vnet.ibm.com=20
>>>>>> > wrote:
>>>>>>>
>>>>>>> /* Find the TBI PHY. If it's not there, we don't =
support =20
>>>>>>> SGMII */
>>>>>>> - ph =3D of_get_property(np, "tbi-handle", NULL);
>>>>>>> + ph =3D (phandle *)of_get_property(np, "tbi-handle", =
NULL);
>>>>>>
>>>>>> You don't need this cast because of_get_property() returns =20
>>>>>> "void *".
>>>>>
>>>>> Stephen,
>>>>>
>>>>> True. But without this gcc complains:
>>>>>
>>>>> CC [M] drivers/net/ucc_geth.o
>>>>> drivers/net/ucc_geth.c: In function b=18ucc_geth_probeb=19:
>>>>> drivers/net/ucc_geth.c:3824: warning: assignment discards =20
>>>>> qualifiers
>>>>> from pointer target type
>>>>
>>>> ph should be declared const phandle *. Look at other uses of
>>>> of_get_property.
>>>>
>>>
>>> Ok fine. Here is a revised patch again.
>>>
>>> Subject: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 =20=
>>> randconfig [drivers/net/ucc_geth.o]
>>> Reference(s):
>>> http://lkml.org/lkml/2009/6/4/241,
>>> http://lkml.org/lkml/2009/6/10/338,
>>>
>>> Fix the following build error:
>>>
>>> drivers/net/ucc_geth.c: In function bucc_geth_probeb:
>>> drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in =20=
>>> this function)
>>> drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is =20=
>>> reported only once
>>> drivers/net/ucc_geth.c:3822: error: for each function it appears =20
>>> in.)
>>> drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use =20
>>> in this function)
>>> make[2]: *** [drivers/net/ucc_geth.o] Error 1
>>>
>>> Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
>>> ---
>>
>> Is there anything else to be done in this patch. If this is OK, can =20=
>> this
>> be applied. I am not sure, but, i find Li Yang as the maintainer for
>> this in linux*/MAINTAINERS file. Kindly let me know if this patch =20
>> needs
>> to be revisited for some other issue(s).
>
> Li,
>
> Any thoughts on this patch ?
>
>
> Regards--
> Subrata
>
>>
>> Regards--
>> Subrata
>>
>>>
>>> --- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10 =20
>>> 11:58:39.000000000 -0500
>>> +++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 =20
>>> 22:28:13.000000000 -0500
>>> @@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
>>>
>>> static int ucc_geth_probe(struct of_device* ofdev, const struct =20
>>> of_device_id *match)
>>> {
>>> + struct device_node *mdio;
>>> + const phandle *ph;
>>> struct device *device =3D &ofdev->dev;
>>> struct device_node *np =3D ofdev->node;
>>> struct net_device *dev =3D NULL;
>>>
>>> ---
>>> Regards--
>>> Subrata
>>>
I'm confused by the proposed fix as we already have *mdio & *ph =20
defined in this function:
static int ucc_geth_probe(struct of_device* ofdev, const struct =20
of_device_id *match)
{
struct device *device =3D &ofdev->dev;
struct device_node *np =3D ofdev->node;
struct device_node *mdio;
struct net_device *dev =3D NULL;
struct ucc_geth_private *ugeth =3D NULL;
struct ucc_geth_info *ug_info;
struct resource res;
struct device_node *phy;
int err, ucc_num, max_speed =3D 0;
const phandle *ph;
const u32 *fixed_link;
const unsigned int *prop;
const char *sprop;
const void *mac_addr;
...
- k=
^ permalink raw reply
* Re: PowerPC PCI DMA issues (prefetch/coherency?)
From: Chris Pringle @ 2009-06-17 13:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list, linux-kernel
In-Reply-To: <4A38A21B.5060306@oxtel.com>
Chris Pringle wrote:
>> You could enable CONFIG_NOT_COHERENT_CACHE.
>>
> I've just tried this (I had to edit Kconfig in power/platforms to make
> the build system accept it), and interestingly it's making no
> difference. I'm using streaming mappings, and are using the pci_map_sg
> functions to ensure the memory is mapped/flushed correctly. I've also
> explicitly put in a pci_dma_sync_sg_for_device, however that's also
> not made any difference. Turning the cpu cache snoop off has the same
> affect as it did without CONFIG_NOT_COHERENT_CACHE; it gets much
> worse. Any other ideas?
>
> Will back off the low latency patches next, and give 2.6.30 a try -
> see if that makes any difference.
>
Low latency patches made no difference. Tried it with 2.6.30 and it now
works. There are a couple of commits contributing to the fix, including
one introduced between 2.6.29-rc8 and 2.6.29 proper in
powerpc/kernel/head_32.S (couple of commits with the name "Fix Respect
_PAGE_COHERENT on classic ppc32 SW TLB load machines"). I've tried
backporting this to 2.6.29-rc8 and it then worked. Backporting to 2.6.26
made no difference however, so I suspect there are other things fixed
which are also contributing.
I'm going to move to 2.6.29/2.6.30 which should resolve our issue.
Thanks to all who have contributed to this thread.
Chris
--
______________________________
Chris Pringle
Software Engineer
Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK
Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com
____________________________
Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ
^ permalink raw reply
* Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Stephen Rothwell @ 2009-06-17 13:23 UTC (permalink / raw)
To: Kumar Gala
Cc: Sachin P Sant, netdev, Linux-Kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Tony, Li Yang, subrata, Balbir Singh
In-Reply-To: <6E26D0A1-0FE5-4179-9DA8-FDF0E3D417DA@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Hi Kumar,
On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
>
> I'm confused by the proposed fix as we already have *mdio & *ph
> defined in this function:
Which tree are you looking at? Linus' tree, and linux-next, do not have
those local variables ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
From: Ingo Molnar @ 2009-06-17 13:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Peter Zijlstra, linux-kernel
In-Reply-To: <19000.57673.618229.523229@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> Ingo Molnar writes:
>
> > ah, it does this:
> >
> > /*
> > * This is here because we used to use l64 for 64bit powerpc
> > * and we don't want to impact user mode with our change to ll64
> > * in the kernel.
> > */
> > #if defined(__powerpc64__) && !defined(__KERNEL__)
> > # include <asm-generic/int-l64.h>
> > #else
> > # include <asm-generic/int-ll64.h>
> > #endif
> >
> > That's crappy really.
>
> We were concerned that changing the userland-visible type of __u64
> from unsigned long to unsigned long long, etc., would be breaking
> the ABI, even if only in a small way - I thought it could possibly
> change C++ mangled function names, for instance, and it would
> cause fresh compile warnings on existing user code that prints
> __u64 with %lx, which has always been the correct thing to do on
> ppc64.
>
> A counter-argument would be, I guess, that __u64 et al. are purely
> for use in describing the kernel/user interface, so we have a
> little more latitude than with the type of e.g. u_int64_t. I
> dunno. I don't recall getting much of an answer from the glibc
> guys about what they thought of the idea of changing it.
>
> Anyway, of the 64-bit architectures, alpha, ia64, and mips64 also
> have __u64 as unsigned long in userspace, so this issue will still
> crop up even if we change it on powerpc.
Having crap elsewhere is no reason to spread it further really. We
need consistent types. Can we define __KERNEL__ perhaps to get to
the real types?
Ingo
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: M. Mohan Kumar @ 2009-06-17 13:34 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, Simon Horman, kexec, miltonm
In-Reply-To: <20090617130413.GB2774@localhost.localdomain>
On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote:
> On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote:
> >
> > What compiler version are you using? Does the behaviour change if you
> > use a newer/older compiler? It sounds to me like there's some deeper bug
> > and your patch is just papering over it.
> >
I tried with gcc 4.3.2. Let me try with a recent version and update.
> Agreed, this doesn't make any sense. Try changing the compiler version to see if
> the problem goes away or stops. It might also be worthwhile to dump the
> contents of the device tree at the start and end of the kexec process. If the
> changing of how a function is inlined is causing a hang, its likely changing how
> the putprops function is writing information to the device tree. Understanding
> what that change is will likely provide clues to how the code has changed.
Neil, there was no code change in fs2dt.c
Regards,
M. Mohan Kumar
^ permalink raw reply
* Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Stephen Rothwell @ 2009-06-17 13:34 UTC (permalink / raw)
To: Kumar Gala
Cc: Sachin P Sant, netdev, Linux-Kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Tony, Li Yang, subrata,
David S. Miller, Balbir Singh
In-Reply-To: <20090617232341.c4543ff2.sfr@canb.auug.org.au>
On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Kumar,
>
> On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> >
> > I'm confused by the proposed fix as we already have *mdio & *ph
> > defined in this function:
>
> Which tree are you looking at? Linus' tree, and linux-next, do not have
> those local variables ...
Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 ("net: Rework
ucc_geth driver to use of_mdio infrastructure") removed the locals along
with their usages, then commit 047584ce94108012288554a5f84585d792cc7f8f
("net/ucc_geth: Add SGMII support for UEC GETH driver") added more uses
without adding the variables back.
Here is the patch again:
From: Subrata Modak <subrata@linux.vnet.ibm.com>
Subject: [PATCH] Fix build error in ucc_geth.c
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10 11:58:39.000000000 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 22:28:13.000000000 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = &ofdev->dev;
struct device_node *np = ofdev->node;
struct net_device *dev = NULL;
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: linux-next: kvm/powerpc tree build failure
From: Avi Kivity @ 2009-06-17 13:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <20090617150419.e406a69a.sfr@canb.auug.org.au>
On 06/17/2009 08:04 AM, Stephen Rothwell wrote:
> From: Stephen Rothwell<sfr@canb.auug.org.au>
> Date: Wed, 17 Jun 2009 14:57:29 +1000
> Subject: [PATCH] kvm/powerpc: make 32 bit constant unsigned long
>
> KVM_PAGES_PER_HPAGE needs to be unsigned long since its value is 2^31.
>
> Eliminates this compiler warning:
>
>
Thanks, applied. For some reason my own build testing didn't fail on this.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply
* Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Kumar Gala @ 2009-06-17 13:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Sachin P Sant, netdev, Linux-Kernel, Linuxppc-dev, Linux-Next,
Nathan Lynch, Haiying Wang, Li Yang, subrata, David S. Miller,
Balbir Singh
In-Reply-To: <20090617233452.03ac78d5.sfr@canb.auug.org.au>
On Jun 17, 2009, at 8:34 AM, Stephen Rothwell wrote:
> On Wed, 17 Jun 2009 23:23:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au
> > wrote:
>>
>> Hi Kumar,
>>
>> On Wed, 17 Jun 2009 08:07:47 -0500 Kumar Gala <galak@kernel.crashing.org
>> > wrote:
>>>
>>>
>>> I'm confused by the proposed fix as we already have *mdio & *ph
>>> defined in this function:
>>
>> Which tree are you looking at? Linus' tree, and linux-next, do not
>> have
>> those local variables ...
>
> Hmmm, commit 0b9da337dca972e7a4144e298ec3adb8f244d4a4 ("net: Rework
> ucc_geth driver to use of_mdio infrastructure") removed the locals
> along
> with their usages, then commit
> 047584ce94108012288554a5f84585d792cc7f8f
> ("net/ucc_geth: Add SGMII support for UEC GETH driver") added more
> uses
> without adding the variables back.
>
> Here is the patch again:
>
> From: Subrata Modak <subrata@linux.vnet.ibm.com>
> Subject: [PATCH] Fix build error in ucc_geth.c
>
> Fix the following build error:
>
> drivers/net/ucc_geth.c: In function bucc_geth_probeb:
> drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in
> this function)
> drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is
> reported only once
> drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
> drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in
> this function)
> make[2]: *** [drivers/net/ucc_geth.o] Error 1
>
> Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
>
> --- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10
> 11:58:39.000000000 -0500
> +++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10
> 22:28:13.000000000 -0500
> @@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
>
> static int ucc_geth_probe(struct of_device* ofdev, const struct
> of_device_id *match)
> {
> + struct device_node *mdio;
> + const phandle *ph;
> struct device *device = &ofdev->dev;
> struct device_node *np = ofdev->node;
> struct net_device *dev = NULL;
ah... was looking at powerpc next which hasn't pulled in linus's
latest tree w/netdev updates.
- k
^ permalink raw reply
* Re: linux-next: kvm/powerpc tree build failure
From: Stephen Rothwell @ 2009-06-17 13:55 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <4A38F47F.509@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
Hi Avi,
On Wed, 17 Jun 2009 16:49:51 +0300 Avi Kivity <avi@redhat.com> wrote:
>
> Thanks, applied. For some reason my own build testing didn't fail on this.
Thanks. It could be a different compiler version doesn't complain (I am
currently using 4.4.0) and the powerpc tree has a patch to build parts of
arch/powerpc with -Werror which makes it stand out a bit :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] net/ucc_geth: Fix compile errors
From: Kumar Gala @ 2009-06-17 13:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Subrata Modak, linux-kernel, linuxppc-dev
From: Subrata Modak <subrata@linux.vnet.ibm.com>
drivers/net/ucc_geth.c: In function 'ucc_geth_probe':
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this function)
Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/net/ucc_geth.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..31da996 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_geth_netdev_ops = {
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
{
+ struct device_node *mdio;
+ const phandle *ph;
struct device *device = &ofdev->dev;
struct device_node *np = ofdev->node;
struct net_device *dev = NULL;
--
1.6.0.6
^ permalink raw reply related
* Re: linux-next: kvm/powerpc tree build failure
From: Avi Kivity @ 2009-06-17 14:04 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <20090617235546.95aa39a5.sfr@canb.auug.org.au>
On 06/17/2009 04:55 PM, Stephen Rothwell wrote:
> Hi Avi,
>
> On Wed, 17 Jun 2009 16:49:51 +0300 Avi Kivity<avi@redhat.com> wrote:
>
>> Thanks, applied. For some reason my own build testing didn't fail on this.
>>
>
> Thanks. It could be a different compiler version doesn't complain (I am
> currently using 4.4.0) and the powerpc tree has a patch to build parts of
> arch/powerpc with -Werror which makes it stand out a bit :-)
>
Ah yes, you did mention it was a warning.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Neil Horman @ 2009-06-17 14:05 UTC (permalink / raw)
To: M. Mohan Kumar; +Cc: linuxppc-dev, Simon Horman, kexec, miltonm
In-Reply-To: <20090617133435.GB4059@in.ibm.com>
On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote:
> On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote:
> > On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote:
> > >
> > > What compiler version are you using? Does the behaviour change if you
> > > use a newer/older compiler? It sounds to me like there's some deeper bug
> > > and your patch is just papering over it.
> > >
>
> I tried with gcc 4.3.2. Let me try with a recent version and update.
>
> > Agreed, this doesn't make any sense. Try changing the compiler version to see if
> > the problem goes away or stops. It might also be worthwhile to dump the
> > contents of the device tree at the start and end of the kexec process. If the
> > changing of how a function is inlined is causing a hang, its likely changing how
> > the putprops function is writing information to the device tree. Understanding
> > what that change is will likely provide clues to how the code has changed.
>
> Neil, there was no code change in fs2dt.c
>
Sure there was, by modifying the code to tell it to not inline the putprops
function, you changed how the complier optimizes that code block. There may not
be any source level code change, but the assembly is certainly different, and it
must be so in a way thats causing a hang. The putpops function changes the
contents of the ppc64 device-tree, so if this is a compiler bug, and its causing
a hang, I imagine we'll see some manifestation in a change in the device tree
contents.
Neil
> Regards,
> M. Mohan Kumar
^ permalink raw reply
* Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
From: Kumar Gala @ 2009-06-17 14:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Ingo Molnar, Peter Zijlstra, linux-kernel, linuxppc-dev
In-Reply-To: <19000.55404.103840.393470@cargo.ozlabs.ibm.com>
On Jun 17, 2009, at 6:50 AM, Paul Mackerras wrote:
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/
> platforms/Kconfig.cputype
> index cca6b4f..dd9f3ec 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -1,7 +1,7 @@
> config PPC64
> bool "64-bit kernel"
> default n
> - select HAVE_PERF_COUNTERS
> + select PPC_HAVE_PMU_SUPPORT
> help
> This option selects whether a 32-bit or a 64-bit kernel
> will be built.
> @@ -243,6 +243,15 @@ config VIRT_CPU_ACCOUNTING
>
> If in doubt, say Y here.
>
> +config PPC_HAVE_PMU_SUPPORT
> + bool
what does this mean?
> +
> +config PPC_PERF_CTRS
> + def_bool y
> + depends on PERF_COUNTERS && PPC_HAVE_PMU_SUPPORT
> + help
> + This enables the powerpc-specific perf_counter back-end.
Can we distinguish between the two different architected perf counters
programming models to start with. Maybe something like:
PPC_BOOK3S_PERF_CTRS and PPC_BOOK3E_PERF_CTRS (or
PPC_SERVER_PERF_CTRS / PPC_EMB_PERF_CTRS)
>
> +
> config SMP
> depends on PPC_STD_MMU || FSL_BOOKE
> bool "Symmetric multi-processing support"
> --
> 1.6.0.4
>
^ permalink raw reply
* Re: [PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
From: Kumar Gala @ 2009-06-17 14:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, linux-kernel
In-Reply-To: <19000.55631.802122.696927@cargo.ozlabs.ibm.com>
On Jun 17, 2009, at 6:53 AM, Paul Mackerras wrote:
> This adds support for the performance monitor hardware on the
> MPC7450 family of processors (7450, 7451, 7455, 7447/7457, 7447A,
> 7448), used in the later Apple G4 powermacs/powerbooks and other
> machines. These machines have 6 hardware counters with a unique
> set of events which can be counted on each counter, with some
> events being available on multiple counters.
>
> Raw event codes for these processors are (PMC << 8) + PMCSEL.
> If PMC is non-zero then the event is that selected by the given
> PMCSEL value for that PMC (hardware counter). If PMC is zero
> then the event selected is one of the low-numbered ones that are
> common to several PMCs. In this case PMCSEL must be <= 22 and
> the event is what that PMCSEL value would select on PMC1 (but
> it may be placed any other PMC that has the same event for that
> PMCSEL value).
>
> For events that count cycles or occurrences that exceed a threshold,
> the threshold requested can be specified in the 0x3f000 bits of the
> raw event codes. If the event uses the threshold multiplier bit
> and that bit should be set, that is indicated with the 0x40000 bit
> of the raw event code.
>
> This fills in some of the generic cache events. Unfortunately there
> are quite a few blank spaces in the table, partly because these
> processors tend to count cache hits rather than cache accesses.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/kernel/Makefile | 2 +
> arch/powerpc/kernel/mpc7450-pmu.c | 417 +++++++++++++++++++++++
> +++++++++
> arch/powerpc/platforms/Kconfig.cputype | 1 +
> 3 files changed, 420 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/kernel/mpc7450-pmu.c
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/
> Makefile
> index c5f93f0..a9f8829 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -98,6 +98,7 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
> obj-$(CONFIG_PPC_PERF_CTRS) += perf_counter.o
> obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o power5-
> pmu.o \
> power5+-pmu.o power6-pmu.o power7-pmu.o
This should be something like:
obj64-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_64)
> +obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
obj32-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_32)
Or use new Kconfig types as I suggested on patch 1/6
> obj-$(CONFIG_8XX_MINIMAL_FPEMU) += softemu8xx.o
>
> @@ -106,6 +107,7 @@ obj-y += iomap.o
> endif
>
> obj-$(CONFIG_PPC64) += $(obj64-y)
> +obj-$(CONFIG_PPC32) += $(obj32-y)
>
> ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC),)
> obj-y += ppc_save_regs.o
> diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/pow
^ permalink raw reply
* Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
From: Ingo Molnar @ 2009-06-17 14:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Peter Zijlstra, linux-kernel
In-Reply-To: <19000.55404.103840.393470@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> This depends on the generic atomic64_t patches, which are now in
> Linus' tree. Ingo, if you're putting these in, please pull Linus'
> tree in first.
Note, i've created a new branch, tip:perfcounters/powerpc, so we can
keep these things separate and Ben can pull them too. I see there
was some review feedback - do you want to send a v2 version perhaps?
Ingo
^ permalink raw reply
* Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
From: Kumar Gala @ 2009-06-17 14:24 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linuxppc-dev, Paul Mackerras, Peter Zijlstra, linux-kernel
In-Reply-To: <20090617142151.GB6846@elte.hu>
On Jun 17, 2009, at 9:21 AM, Ingo Molnar wrote:
>
> * Paul Mackerras <paulus@samba.org> wrote:
>
>> This depends on the generic atomic64_t patches, which are now in
>> Linus' tree. Ingo, if you're putting these in, please pull Linus'
>> tree in first.
>
> Note, i've created a new branch, tip:perfcounters/powerpc, so we can
> keep these things separate and Ben can pull them too. I see there
> was some review feedback - do you want to send a v2 version perhaps?
Out of interest, is the intent to try and get these changes into .31?
I ask because I want to know if I should try to find time to add
support for the FSL embedded perfmon ASAP or not.
- k
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: M. Mohan Kumar @ 2009-06-17 14:26 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, Simon Horman, kexec, miltonm
In-Reply-To: <20090617140514.GB31383@hmsreliant.think-freely.org>
On Wed, Jun 17, 2009 at 10:05:14AM -0400, Neil Horman wrote:
> On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote:
> > On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote:
> > > On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote:
> > > >
> > > > What compiler version are you using? Does the behaviour change if you
> > > > use a newer/older compiler? It sounds to me like there's some deeper bug
> > > > and your patch is just papering over it.
> > > >
> >
> > I tried with gcc 4.3.2. Let me try with a recent version and update.
> >
> > > Agreed, this doesn't make any sense. Try changing the compiler version to see if
> > > the problem goes away or stops. It might also be worthwhile to dump the
> > > contents of the device tree at the start and end of the kexec process. If the
> > > changing of how a function is inlined is causing a hang, its likely changing how
> > > the putprops function is writing information to the device tree. Understanding
> > > what that change is will likely provide clues to how the code has changed.
> >
> > Neil, there was no code change in fs2dt.c
> >
> Sure there was, by modifying the code to tell it to not inline the putprops
> function, you changed how the complier optimizes that code block. There may not
> be any source level code change, but the assembly is certainly different, and it
> must be so in a way thats causing a hang. The putpops function changes the
> contents of the ppc64 device-tree, so if this is a compiler bug, and its causing
> a hang, I imagine we'll see some manifestation in a change in the device tree
> contents.
As I mentioned in the patch description, when I retained the variable dt_len
and dt_len = dt assignment, kexec/kdump kernel would work. But even if I
comment the "dt_len = dt" assignment kernel would hang. If you need I can
send objdump of fs2dt.o with and without this assignment.
Regards,
M. Mohan Kumar.
^ 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