* Re: [PATCH][Resend 2][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Grant Likely @ 2009-06-17 17:29 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 Wed, Jun 17, 2009 at 7:34 AM, Stephen Rothwell<sfr@canb.auug.org.au> wro=
te:
> 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? =A0Linus' tree, and linux-next, do not ha=
ve
>> 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 fu=
nction)
> drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is report=
ed 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 =A0 =A0 =A0 =A02009-06-1=
0 11:58:39.000000000 -0500
> +++ linux-2.6.30-rc8/drivers/net/ucc_geth.c =A0 =A0 2009-06-10 22:28:13.0=
00000000 -0500
> @@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
>
> =A0static int ucc_geth_probe(struct of_device* ofdev, const struct of_dev=
ice_id *match)
> =A0{
> + =A0 =A0 =A0 struct device_node *mdio;
> + =A0 =A0 =A0 const phandle *ph;
> =A0 =A0 =A0 =A0struct device *device =3D &ofdev->dev;
> =A0 =A0 =A0 =A0struct device_node *np =3D ofdev->node;
> =A0 =A0 =A0 =A0struct net_device *dev =3D NULL;
Ah, this might not be the right fix then. I'll look.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-17 17:17 UTC (permalink / raw)
To: Ira Snyder; +Cc: linuxppc-dev@ozlabs.org, Li Yang
In-Reply-To: <20090616201256.GG15955@ovro.caltech.edu>
Ira Snyder wrote:
>> Using EXPORT_SYMBOL would defeat the purpose of conforming to the
>> dmaengine api which should allow other subsystems to generically
>> discover an fsldma resource.
>>
>
> Any driver would still use dma_request_channel(), etc. to get access to
> a DMA channel. AFAICT, DMA_SLAVE is intended for doing something
> completely hardware-specific with the DMA controller.
Yes. Specifically DMA_SLAVE operations imply a pre-established context
with a 3rd device (the other 2 devices being system memory and the dma
channel), as compared to plain memcpy. The assumption is that a dma
device with this capability may not be shared with other requesters
until the context is torn down.
[..]
> What I've implemented is this: (sorry about the poor drawing)
>
> scatterlist fsl_dma_hw_addr
> +--------+ +-------+
> | DATA | --------> | DEST1 |
> | DATA | ----+ +-------+
> | DATA | |
> | DATA | | +-------+
> | DATA | +---> | DEST2 |
> | DATA | +-------+
> +--------+
> .
> .
> .
>
> Of course, the reverse works as well. You can copy from a list of
> hardware address/length pairs to a scatterlist.
>
> So, using my implementation of the DMA_SLAVE feature, you can take a big
> chunk of data (which is organized into a scatterlist) and DMA it
> directly to a set of hardware addresses, all in a single, unbroken
> transaction.
Could the same effect be achieved by calling ->prep_slave_sg multiple
times? Once you need to add dma-driver specific helper routines you are
effectively extending the dmaengine interface in an fsldma specific
fashion. Can we reduce this to just the existing primitives? If it
turns out that this is untenable can we extend dmaengine to make this a
generic capability? My preference is the former.
> I've inlined the driver for the FPGA programmer below. I don't think it
> is appropriate to push into mainline, since it will only work for our
> board, and nothing else.
If we find that we need to extend the dmaengine interface we will need
an in-tree user. In my opinion, as long as it passes the Voyager test
[1] then I do not see why it should be barred from upstream.
[..]
> He also used platform data to get the register addresses. I'm unaware of
> a way to put arbitrary platform data into the OF tree used on PowerPC.
>
Anybody else on ppc-dev know if this is possible??
> I didn't want to force other users to implement the allocation routines
> for the struct fsl_dma_hw_addr themselves, so I provided routines to do
> so.
It depends on how many users of this feature there ends up being,
pushing this into each driver that needs it would not be too horrible
especially if it just the three straightforward routines
(fsl_dma_slave_append, fsl_dma_slave_free, and fsl_dma_slave_alloc).
So, the three options in order of preference are:
1/ arrange to call ->prep multiple times to handle each dma address
2/ push the functionality down into the individual drivers that need it
3/ up level the functionality into dmaengine to make it generically
available
Thanks,
Dan
[1]: The Voyager test refers to James Bottomley's maintenance of the
Voyager x86-sub-architecture. If at least one person cares about a
feature, is willing to maintain the code, and it does not impose a
maintenance burden on other parts of the tree then it can go upstream.
^ permalink raw reply
* Re: 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
From: Leon Woestenberg @ 2009-06-17 16:07 UTC (permalink / raw)
To: Linux PPC, Kumar Gala, linux-ide
In-Reply-To: <c384c5ea0906080759n24a66d21ob9076518cec41755@mail.gmail.com>
Hello Kumar, all,
On Mon, Jun 8, 2009 at 4:59 PM, Leon
Woestenberg<leon.woestenberg@gmail.com> wrote:
> using 2.6.30-rc6, I get the following problems when I read from a SSD
> disk, connected to the
> 3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6.
>
Result on a first batch of bisects. I decided to go with the kernel
releases rather than git-bisect (still too scary for me).
All kernel releases 2.6.25 through -30 kernel gave the same error.
2.6.25 crashed on it, whereas 2.6.26+ recovered after each "dd" run.
The BSP 2.6.24.3-rt3 kernel did not give the error.
So on my todo is diff between 2.6.25 and .2.6.24.3-rt3 from the BSP.
Regards,
--
Leon
^ permalink raw reply
* ethernet packet drop
From: Mehul Chadha @ 2009-06-17 14:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
Hello everyone,
I am working on a project for router development.
The basic specifications of the router are as follows:
· Supports MPC8248 - 32-bit PowerQUICC II Communication Processor
running at 400 MHz (Max) core frequency, 200 MHz (Max) CPM, and 100MHz (Max)
external bus frequency.
· 64-bit wide 256-MByte synchronous DRAM (soldered on-board),
consisting
of 4 no. devices of 8M x 16 x 4, residing on 60X bus (PBI mode), controlled
by SDRAM machine.
· 256 MB NAND Flash, organized as 256M x 8, buffered from 60X bus,
controlled by UPM machine.
· Upto 8MB NOR Flash, Boot sector (bottom) type, organized as 8M x
8, buffered from 60X bus, controlled by GPCM machine.
· Linux Kernel version: linux-2.6.16.40
While testing my router with the spirent test equipment, the 2 ethernet
ports of the router are connected to the testing equipment. I send data from
the testing equipment through the ethernet port , the router forwards the
packet to the other ethernet port again connected to the testing equipment.
When I increase the throughput to 70 mbps the testing equipment starts
showing packet losses which should not happen as its a 10/100 mbps link. I
am not able to understand where would the problem lie. Pls if someone can
list the different issues due to which this problem is occurring, it will be
really helpful
Regards,
Mehul
[-- Attachment #2: Type: text/html, Size: 7896 bytes --]
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Neil Horman @ 2009-06-17 14:40 UTC (permalink / raw)
To: M. Mohan Kumar; +Cc: linuxppc-dev, Simon Horman, kexec, miltonm
In-Reply-To: <20090617142652.GC4059@in.ibm.com>
On Wed, Jun 17, 2009 at 07:56:52PM +0530, M. Mohan Kumar wrote:
> 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
Yes, and as Michael has noted, that is likey an indication of a compiler bug.
You shouldn't get differing behavior in a kdump kernel by removing an unused
variable in kexec. Which is why I'm unconvinced this patch is really fixing
anything, but rather just avoiding the real problem.
> send objdump of fs2dt.o with and without this assignment.
>
That would be a fine thing to do, and I'd be happy to compare them. My though
regarding the comparison of the device tree on a good and bad run was meant to
expidite what change in the assembly we'd be looking for. If its the kdump
kernel boot thats hanging, Its likely hanging on something in the device tree,
as thats whats being manipulated by this code. So I figure that understanding
whats changed there will point us toward what change in the assembly might be
responsible for the hang. The assmebly's going to be signficantly different
(lots of optimization might be lost from no longer inlining a function), so
anything that helps us narrow down whats changed will be good
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: Ingo Molnar @ 2009-06-17 14:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Peter Zijlstra, linux-kernel
In-Reply-To: <8C6954A9-BE4C-47F5-AD87-A1D0EAF43F8A@kernel.crashing.org>
* Kumar Gala <galak@kernel.crashing.org> wrote:
> 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.
I think it would be nice to have more platform support in .31.
Perfcounters is a brand-new feature so there's no risk of
regression. In the end it will depend on Linus to pull of course,
and BenH can veto it too if he'd like no more PowerPC changes in
this cycle. Worst-case it's all .32 material.
Ingo
^ 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
* 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 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 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: 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] 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: 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
* [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: 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
* 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: 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: 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: [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 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][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: 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: 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: [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
* [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
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