* linux-next: build failure after merge of the final tree (powerpc related)
From: Stephen Rothwell @ 2012-06-20 7:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-next, ppc-dev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2914 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word':
(.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_half':
(.text+0xe0): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_byte':
(.text+0x130): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_byte_msh':
(.text+0x180): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_word_negative_offset':
(.text+0x1dc): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_half_negative_offset':
(.text+0x238): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_byte_negative_offset':
(.text+0x294): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern
powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_byte_msh_negative_offset':
(.text+0x2f0): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern
powerpc64-linux-ld: final link failed: Bad value
I started building with gcc 4.6.3/binutils 2.22 today. gcc
4.6.0/binutils 2.21 do not produce this error, it produces this instead
(which has been happening for a long time):
powerpc64-linux-ld: TOC section size exceeds 64k
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] MIPS: fix bug.h MIPS build regression
From: John Crispin @ 2012-06-20 7:09 UTC (permalink / raw)
To: Yoichi Yuasa
Cc: Linuxppc-dev, Linux-sh list, linux-kernel,
Linux MIPS Mailing List
In-Reply-To: <20120620152759.2caceb8c.yuasa@linux-mips.org>
On 20/06/12 08:27, Yoichi Yuasa wrote:
> Commit: 3777808873b0c49c5cf27e44c948dfb02675d578 breaks all MIPS builds.
>
Hi Yoichi,
I stumbled across the same build regression last night and came up with
almost the same fix :-)
Tested-by: John Crispin <blogic@openwrt.org>
Thanks,
John
^ permalink raw reply
* [PATCH] MIPS: fix bug.h MIPS build regression
From: Yoichi Yuasa @ 2012-06-20 6:27 UTC (permalink / raw)
To: Geert Uytterhoeven, Paul Mundt
Cc: Chris Zankel, Linux-sh list, linux-kernel, Ralf Baechle,
Linuxppc-dev, Linux MIPS Mailing List, yuasa
In-Reply-To: <CAMuHMdVfLjgrtWoPpvbLf12+=ApE6W9dNcweqD-_2Benr-D7NQ@mail.gmail.com>
Commit: 3777808873b0c49c5cf27e44c948dfb02675d578 breaks all MIPS builds.
CC arch/mips/kernel/machine_kexec.o
In file included from include/linux/kernel.h:20:0,
from include/asm-generic/bug.h:35,
from /home/yuasa/src/linux/kernel/git/linux-2.6/arch/mips/include/asm/bug.h:41,
from /home/yuasa/src/linux/kernel/git/linux-2.6/arch/mips/include/asm/bitops.h:20,
from include/linux/bitops.h:22,
from include/linux/signal.h:38,
from include/linux/elfcore.h:5,
from include/linux/kexec.h:60,
from arch/mips/kernel/machine_kexec.c:9:
include/linux/log2.h: In function '__ilog2_u32':
include/linux/log2.h:34:2: error: implicit declaration of function 'fls' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__ilog2_u64':
include/linux/log2.h:42:2: error: implicit declaration of function 'fls64' [-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__roundup_pow_of_two':
include/linux/log2.h:63:2: error: implicit declaration of function 'fls_long' [-Werror=implicit-function-declaration]
In file included from include/linux/bitops.h:22:0,
from include/linux/signal.h:38,
from include/linux/elfcore.h:5,
from include/linux/kexec.h:60,
from arch/mips/kernel/machine_kexec.c:9:
/home/yuasa/src/linux/kernel/git/linux-2.6/arch/mips/include/asm/bitops.h: At top level:
/home/yuasa/src/linux/kernel/git/linux-2.6/arch/mips/include/asm/bitops.h:615:19: error: static declaration of 'fls' follows non-static declaration
include/linux/log2.h:34:9: note: previous implicit declaration of 'fls' was here
In file included from /home/yuasa/src/linux/kernel/git/linux-2.6/arch/mips/include/asm/bitops.h:651:0,
from include/linux/bitops.h:22,
from include/linux/signal.h:38,
from include/linux/elfcore.h:5,
from include/linux/kexec.h:60,
from arch/mips/kernel/machine_kexec.c:9:
include/asm-generic/bitops/fls64.h:18:28: error: static declaration of 'fls64' follows non-static declaration
include/linux/log2.h:42:9: note: previous implicit declaration of 'fls64' was here
In file included from include/linux/signal.h:38:0,
from include/linux/elfcore.h:5,
from include/linux/kexec.h:60,
from arch/mips/kernel/machine_kexec.c:9:
include/linux/bitops.h:160:24: error: conflicting types for 'fls_long'
include/linux/log2.h:63:16: note: previous implicit declaration of 'fls_long' was here
cc1: all warnings being treated as errors
make[2]: *** [arch/mips/kernel/machine_kexec.o] Error 1
Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
---
arch/mips/include/asm/bitops.h | 1 -
arch/mips/include/asm/io.h | 1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/mips/include/asm/bitops.h b/arch/mips/include/asm/bitops.h
index 2e1ad4c..82ad35c 100644
--- a/arch/mips/include/asm/bitops.h
+++ b/arch/mips/include/asm/bitops.h
@@ -17,7 +17,6 @@
#include <linux/irqflags.h>
#include <linux/types.h>
#include <asm/barrier.h>
-#include <asm/bug.h>
#include <asm/byteorder.h> /* sigh ... */
#include <asm/cpu-features.h>
#include <asm/sgidefs.h>
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 37a8379..100f9a3 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -17,6 +17,7 @@
#include <linux/types.h>
#include <asm/addrspace.h>
+#include <asm/bug.h>
#include <asm/byteorder.h>
#include <asm/cpu.h>
#include <asm/cpu-features.h>
--
1.7.0.4
^ permalink raw reply related
* [PATCH] powerpc: fix uninitialised error in numa.c
From: Michael Neuling @ 2012-06-20 6:01 UTC (permalink / raw)
To: benh, Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <27235.1340171166@neuling.org>
chroma_defconfig currently gives me this with gcc 4.6:
arch/powerpc/mm/numa.c:638:13: error: 'dm' may be used uninitialized in this function [-Werror=uninitialized]
It's a bogus warning/error since of_get_drconf_memory() only writes it
anyway.
Signed-off-by: Michael Neuling <mikey@neuling.org>
cc: stable@kernel.org
---
> > > static void __init parse_drconf_memory(struct device_node *memory)
> > > {
> > > - const u32 *dm, *usm;
> > > + const u32 *dm = NULL, *usm;
> >
> > Woot bikeshed! I think that's what the uninitialized_var() macro is for.
>
> Doesn't work here. Produces the same error.
My bad.. I was using it wrong
Still affects 3.4 and 3.3 stable.
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 5ca3a15..7c28589 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -637,7 +637,7 @@ static inline int __init read_usm_ranges(const u32 **usm)
*/
static void __init parse_drconf_memory(struct device_node *memory)
{
- const u32 *dm, *usm;
+ const u32 *uninitialized_var(dm), *usm;
unsigned int n, rc, ranges, is_kexec_kdump = 0;
unsigned long lmb_size, base, size, sz;
int nid;
^ permalink raw reply related
* Re: [PATCH] powerpc: fix uninitialised error in numa.c
From: Michael Neuling @ 2012-06-20 5:46 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20120620053808.GD11330@thor.bakeyournoodle.com>
Tony Breeds <tony@bakeyournoodle.com> wrote:
> On Wed, Jun 20, 2012 at 02:17:47PM +1000, Michael Neuling wrote:
> > chroma_defconfig currently gives me this with gcc 4.6:
> > arch/powerpc/mm/numa.c:638:13: error: 'dm' may be used uninitialized in this function [-Werror=uninitialized]
> >
> > It's a bogus warning since of_get_drconf_memory() only writes it
> > anyway.
> >
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> > cc: stable@kernel.org
> > ---
> > Also affects 3.4 and 3.3 stable.
> >
> > diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> > index 5ca3a15..880acde 100644
> > --- a/arch/powerpc/mm/numa.c
> > +++ b/arch/powerpc/mm/numa.c
> > @@ -637,7 +637,7 @@ static inline int __init read_usm_ranges(const u32 **usm)
> > */
> > static void __init parse_drconf_memory(struct device_node *memory)
> > {
> > - const u32 *dm, *usm;
> > + const u32 *dm = NULL, *usm;
>
> Woot bikeshed! I think that's what the uninitialized_var() macro is for.
Doesn't work here. Produces the same error.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: fix uninitialised error in numa.c
From: Tony Breeds @ 2012-06-20 5:38 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <20741.1340165867@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
On Wed, Jun 20, 2012 at 02:17:47PM +1000, Michael Neuling wrote:
> chroma_defconfig currently gives me this with gcc 4.6:
> arch/powerpc/mm/numa.c:638:13: error: 'dm' may be used uninitialized in this function [-Werror=uninitialized]
>
> It's a bogus warning since of_get_drconf_memory() only writes it
> anyway.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> cc: stable@kernel.org
> ---
> Also affects 3.4 and 3.3 stable.
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 5ca3a15..880acde 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -637,7 +637,7 @@ static inline int __init read_usm_ranges(const u32 **usm)
> */
> static void __init parse_drconf_memory(struct device_node *memory)
> {
> - const u32 *dm, *usm;
> + const u32 *dm = NULL, *usm;
Woot bikeshed! I think that's what the uninitialized_var() macro is for.
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] powerpc: fix uninitialised error in numa.c
From: Michael Neuling @ 2012-06-20 4:17 UTC (permalink / raw)
To: benh, Jimi Xenidis; +Cc: linuxppc-dev
chroma_defconfig currently gives me this with gcc 4.6:
arch/powerpc/mm/numa.c:638:13: error: 'dm' may be used uninitialized in this function [-Werror=uninitialized]
It's a bogus warning since of_get_drconf_memory() only writes it
anyway.
Signed-off-by: Michael Neuling <mikey@neuling.org>
cc: stable@kernel.org
---
Also affects 3.4 and 3.3 stable.
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 5ca3a15..880acde 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -637,7 +637,7 @@ static inline int __init read_usm_ranges(const u32 **usm)
*/
static void __init parse_drconf_memory(struct device_node *memory)
{
- const u32 *dm, *usm;
+ const u32 *dm = NULL, *usm;
unsigned int n, rc, ranges, is_kexec_kdump = 0;
unsigned long lmb_size, base, size, sz;
int nid;
^ permalink raw reply related
* Re: Build regressions/improvements in v3.5-rc3
From: Paul Mundt @ 2012-06-20 3:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Chris Zankel, Linux-sh list, linux-kernel, Linuxppc-dev,
Linux MIPS Mailing List, Giuseppe Cavallaro
In-Reply-To: <CAMuHMdVfLjgrtWoPpvbLf12+=ApE6W9dNcweqD-_2Benr-D7NQ@mail.gmail.com>
On Sun, Jun 17, 2012 at 09:56:59PM +0200, Geert Uytterhoeven wrote:
> On Sun, Jun 17, 2012 at 9:46 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > JFYI, when comparing v3.5-rc3 to v3.5-rc2[3], the summaries are:
> > ??- build errors: +235/-10
>
> Truckloads of powerpc "Unrecognized opcode" breakage, and
>
That was my fault, should be fixed up by 2603efa31a.
> + drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implicit
> declaration of function 'pci_iomap'
> [-Werror=implicit-function-declaration]: => 90:3
> + drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implicit
> declaration of function 'pci_iounmap'
> [-Werror=implicit-function-declaration]: => 142:2
>
Not sure about this one, it should find everything alright via:
linux/io.h -> asm/io.h -> asm-generic/iomap.h -> asm-generic/pci_iomap.h
in the case that PCI is enabled. None of allyesconfig/modconfig enable
PCI for me though, so I'm unsure of how you got in to this configuration
to begin with?
> xtensa
>
> + error: "__ashrdi3" [fs/ntfs/ntfs.ko] undefined!: => N/A
> + error: "__lshrdi3" [fs/ntfs/ntfs.ko] undefined!: => N/A
>
> sh4/landisk_defconfig
>
> + error: "__ashrdi3" [fs/xfs/xfs.ko] undefined!: => N/A
> + error: "__lshrdi3" [drivers/mtd/mtd.ko] undefined!: => N/A
> + error: "__lshrdi3" [fs/xfs/xfs.ko] undefined!: => N/A
>
These seem to be the same issue on both platforms, EXPORT_SYMBOL()
doesn't work from lib-y. While it's straightforward to fix, I'm not able
to reproduce __lshrdi3/__ashrdi3 references in any of the above, which
compiler are you using?
^ permalink raw reply
* RE: [PATCH 0/6] Description for PCI patches using platform driver
From: Jia Hongtao-B38951 @ 2012-06-20 2:33 UTC (permalink / raw)
To: Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org,
galak@kernel.crashing.org, benh@kernel.crashing.org
Cc: Wood Scott-B07421, Li Yang-R58472
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D03D84C22@039-SN2MPN1-022.039d.mgd.msft.net>
Hello Ben, Kumar, others:
This series of patches had been pending for a long time on upstream.
We fixed some issues we found and there still some issues should be
discussed like swiotlb init thing. Do you have time for a review?
Thanks.
-Jia Hongtao.
> -----Original Message-----
> From: Bhushan Bharat-R65777
> Sent: Thursday, June 14, 2012 5:52 PM
> To: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org;
> galak@kernel.crashing.org; benh@kernel.crashing.org
> Cc: Li Yang-R58472; Wood Scott-B07421
> Subject: RE: [PATCH 0/6] Description for PCI patches using platform
> driver
>=20
> Hello Ben, Kumar, others
>=20
> Please provide your comments/thoughts on this ?
>=20
> Thanks
> -Bharat
>=20
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jia Hongtao-B38951
> > > > > > Sent: Friday, June 08, 2012 3:12 PM
> > > > > > To: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> > > > > > Cc: Li Yang-R58472; benh@kernel.crashing.org; Wood Scott-B07421=
;
> > > > > Bhushan Bharat-
> > > > > > R65777; Jia Hongtao-B38951
> > > > > > Subject: [PATCH 0/6] Description for PCI patches using platform
> > > > > > driver
> > > > > >
> > > > > > This series of patches are to unify pci initialization code and
> > > > > > add PM
> > > > > support
> > > > > > for all 85xx/86xx powerpc boards. But two side effects are
> > > > > > introduced
> > > > > by this
> > > > > > mechanism which listed below:
> > > > > >
> > > > > > 1. of_platform_bus_probe() will be called twice but in some
> > > > > > cases
> > > > > duplication
> > > > > > warning occured. We fix this in [PATCH 5/6].
> > > > > >
> > > > > > 2. Edac driver failed to register pci nodes as platform devices=
.
> > > > > > We fix
> > > > > this
> > > > > > in [PATCH 6/6].
> > > > >
> > > > > With these patches will not the SWIOTLB will not be initialized
> > > > > even if PCI/PCIe demanded?
> > > > >
> > > > > Thanks
> > > > > -Bharat
> > > > >
> > > >
> > > > These patches still have the swiotlb init problem if
> > > "ppc_swiotlb_enable" is
> > > > only demanded by PCI/PCIe. One of the purposes of sending out these
> > > patches is
> > > > to let us start a discussion for this problem in upstream.
> > >
> > > Ok, I did not find any mention of that, so I thought that you have
> > > resolved the issue by some means in these patches which I did not
> catch.
> > >
> > > So, these patches introduces the issue, that SWIOTLB will not be
> > > initialized if requested by pci/pcie. The request is raised by
> setting
> > > the flag ppc_swiotlb_enable. The swiotlb_init() will be called in
> > > mem_init() if ppc_swiotlb_enable is set. Now with these patches, the
> > > request is raised after mem_init() is called. So request not
> handled :).
> > >
> > > Following are the solutions we have thought of during our internal
> > > discussions (if I did not missed any):
> > >
> > > 1. These patches move the code from platform init to device init
> > > (arch_initcall()). Rather than moving the whole code, let us divide
> > > the code into two. First, which is needed to raise the swiotlb init
> > > request and second the rest. Define this first as an function in
> > > arch/powerpc/sysdev/fsl_pci.c and call this from platform init code
> of
> > > the SOCs.
> > >
> > > 2. All known devices, the lowest PCIe outbound range starts at
> > > 0x80000000, but there's nothing above 0xc0000000. So the inbound of
> > > size 0x8000_0000 is always availbe on all devices. Hardcode the check
> > > in platform code to check memblock_end_of_DRAM() to 0x80000000.
> > >
> > > Something like this:
> > >
> > > diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
> > > b/arch/powerpc/platforms/85xx/corenet_ds.c
> > > index 1f7028e..ef4e215 100644
> > > --- a/arch/powerpc/platforms/85xx/corenet_ds.c
> > > +++ b/arch/powerpc/platforms/85xx/corenet_ds.c
> > > @@ -79,7 +79,7 @@ void __init corenet_ds_setup_arch(void) #endif
> > >
> > > #ifdef CONFIG_SWIOTLB
> > > - if (memblock_end_of_DRAM() > 0xffffffff)
> > > + if (memblock_end_of_DRAM() > 0xff000000)
> > > ppc_swiotlb_enable =3D 1; #endif
> > > pr_info("%s board from Freescale Semiconductor\n",
> > > ppc_md.name);
> > >
> > > -------------
> > >
> > > 3. Always do swiotlb_init() in mem_init() and later after PCI init,
> if
> > > the swiotlb is not needed then free it (swiotlb_free()).
> > >
> > > 4. etc, please provide some other better way.
> > >
> > > Thanks
> > > -Bharat
> >
> > Thanks.
> > In my point of view the 2nd solution is better for it does not treat
> PCI/PCIe as
> > the special kind of devices from others.
> >
> > -Jia Hongtao.
^ permalink raw reply
* Re: [PATCH] USB: FHCI: Reusing the QUICC Engine USB Controller registers struct from immap_qe.h.
From: Kumar Gala @ 2012-06-19 20:45 UTC (permalink / raw)
To: guilherme.maciel.ferreira; +Cc: linuxppc-dev
In-Reply-To: <CAF=5bWf_fzj2ZV8dLJFdffqQ7J5spepBi3qp7NN8SqUfkm1mMQ@mail.gmail.com>
On Jun 19, 2012, at 8:12 AM, Guilherme Maciel Ferreira wrote:
> The struct fhci_regs (in fhci.h) is basically a redefinition
> of the struct qe_usb_ctlr (in immap_qe.h). The later struct is
> preferrable once it uses the registers names found at the
> Freescale's QUICC Engine manual. Thus it is easier to map the
> driver to the manual.
>=20
> Also, the FHCI driver uses the USB controller registers, so
> the name qe_usb_ctlr maps better to the hardware than fhci_regs.
>=20
> Signed-off-by: Guilherme Maciel Ferreira =
<guilherme.maciel.ferreira@gmail.com>
> ---
> drivers/usb/host/fhci-dbg.c | 12 ++++++------
> drivers/usb/host/fhci-hcd.c | 32 ++++++++++++++++----------------
> drivers/usb/host/fhci-hub.c | 16 ++++++++--------
> drivers/usb/host/fhci-sched.c | 30 +++++++++++++++---------------
> drivers/usb/host/fhci-tds.c | 14 +++++++-------
> drivers/usb/host/fhci.h | 22 ++--------------------
> 6 files changed, 54 insertions(+), 72 deletions(-)
This should be sent to the USB maintainers.
- k=
^ permalink raw reply
* Re: RCU stalls on 32-bit pmac SMP
From: Paul E. McKenney @ 2012-06-19 14:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20120618215857.GG2400@linux.vnet.ibm.com>
On Mon, Jun 18, 2012 at 02:58:57PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 19, 2012 at 06:45:31AM +1000, Benjamin Herrenschmidt wrote:
> > Hi Paul !
> >
> > On Mon, 2012-06-18 at 10:05 -0700, Paul E. McKenney wrote:
> >
> > > > sd 0:0:0:0: Attached scsi generic sg0 type 0
> > > > sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15
> > > > sd 0:0:0:0: [sda] Attached SCSI disk
> > > > scsi 0:0:1:0: Direct-Access ATA ST380021A 3.75 PQ: 0 ANSI: 5
> > > > sd 0:0:1:0: [sdb] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
> > > > sd 0:0:1:0: [sdb] Write Protect is off
> > > > sd 0:0:1:0: Attached scsi generic sg1 type 0
> > > > sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
> > > > sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > > > INFO: rcu_sched self-detected stall on CPU { 0} (t=16163 jiffies)
> > > > Call Trace:
> > > > INFO: rcu_sched self-detected stall on CPU { 1} (t=16163 jiffies)
> > > > Call Trace:
> > > > [ef877d30] [c0008d04] show_stack+0x50/0x158 (unreliable)
> > > > [ef877d70] [c0097fe4] __rcu_pending+0x184/0x46c
> > > > [ef877da0] [c00991a0] rcu_check_callbacks+0x7c/0x168
> > > > [ef877dc0] [c0044a40] update_process_times+0x3c/0x70
> > > > [ef877de0] [c0083a3c] tick_sched_timer+0x88/0x100
> > > > [ef877e10] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> > > > [ef877e30] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> > > > [ef877ea0] [c000b5c4] timer_interrupt+0x1cc/0x204
> > > > [ef877ed0] [c0011b88] ret_from_except+0x0/0x1c
> > > > --- Exception: 901 at cpu_idle+0xe4/0x188
> > >
> > > Am I reading this correctly? Did the system really take a scheduling-clock
> > > interrupt from within another scheduling-clock interrupt?
> >
> > Not that I can see. I see only one interrupt on that CPU. It was idle,
> > took a timer interrupt -> hrtimer ... etc... RCU boom !
> >
> > > If so, my first question is "Why did the scheduling-clock interrupt
> > > run for so long?" ;-)
> >
> > This is still that CPU:
> >
> > > LR = cpu_idle+0xc8/0x188
> > > > [ef877f90] [c00097e8] cpu_idle+0x60/0x188 (unreliable)
> > > > [ef877fc0] [c046531c] start_secondary+0x2c8/0x2cc
> > > > [ef877ff0] [00003278] 0x3278
> >
> > And now we have the other one:
> >
> > > > [ef873b60] [c0008d04] show_stack+0x50/0x158 (unreliable)
> > > > [ef873ba0] [c0097fe4] __rcu_pending+0x184/0x46c
> > > > [ef873bd0] [c0099240] rcu_check_callbacks+0x11c/0x168
> > > > [ef873bf0] [c0044a40] update_process_times+0x3c/0x70
> > > > [ef873c10] [c0083a3c] tick_sched_timer+0x88/0x100
> > > > [ef873c40] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> > > > [ef873c60] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> > > > [ef873cd0] [c000b5c4] timer_interrupt+0x1cc/0x204
> > > > [ef873d00] [c0011b88] ret_from_except+0x0/0x1c
> > > > --- Exception: 901 at wake_up_new_task+0x134/0x16c
> > > > LR = wake_up_new_task+0x134/0x16c
> > > > [ef873dc0] [c0065f08] wake_up_new_task+0xfc/0x16c (unreliable)
> > > > [ef873df0] [c0035530] do_fork+0xe8/0x2bc
> > > > [ef873e30] [c0008a4c] sys_clone+0x50/0x90
> > > > [ef873e50] [c00114b8] ret_from_syscall+0x0/0x40
> > > > --- Exception: c00 at kernel_thread+0x28/0x68
> > > > LR = __call_usermodehelper+0x40/0xdc
> > > > [ef873f10] [c005f5c8] async_run_entry_fn+0x128/0x1e4 (unreliable)
> > > > [ef873f20] [ef878c00] 0xef878c00
> > > > [ef873f40] [c004e668] process_one_work+0x150/0x3f0
> > > > [ef873f70] [c00514f0] worker_thread+0x18c/0x37c
> > > > [ef873fb0] [c00567bc] kthread+0x84/0x88
> > > > [ef873ff0] [c000f514] kernel_thread+0x4c/0x68
> >
> > Here what we have is a kernel thread trying to call_usermodehelper
> > (probably the hotplug stuff from discovering the disk) taking a timer
> > interrupt from wake_up_new_task.
> >
> > Looks like the hang has to be with some RCU stuff update_process_times
> > does vs. taking the interrupt in wake_up_new_task ? Hard to tell...
>
> The RCU stuff from update_process_times() is usually the diagnostic.
>
> > This happens more/less reliably once at boot on this machine, then no
> > more (after the long pause the machine moves on, apparently fine).
>
> What happens if you reduce the stall-warning timeout? You can use either
> the CONFIG_RCU_CPU_STALL_TIMEOUT kernel config parameter or the
> rcutree.rcu_cpu_stall_timeout boot parameter.
>
> If you can get two stall-warning messages to appear during the hang,
> comparing the stacks is usually informative.
Also, would you be willing to send along your .config?
Thanx, Paul
^ permalink raw reply
* [PATCH] USB: FHCI: Reusing the QUICC Engine USB Controller registers struct from immap_qe.h.
From: Guilherme Maciel Ferreira @ 2012-06-19 13:12 UTC (permalink / raw)
To: linuxppc-dev
The struct fhci_regs (in fhci.h) is basically a redefinition
of the struct qe_usb_ctlr (in immap_qe.h). The later struct is
preferrable once it uses the registers names found at the
Freescale's QUICC Engine manual. Thus it is easier to map the
driver to the manual.
Also, the FHCI driver uses the USB controller registers, so
the name qe_usb_ctlr maps better to the hardware than fhci_regs.
Signed-off-by: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
---
drivers/usb/host/fhci-dbg.c | 12 ++++++------
drivers/usb/host/fhci-hcd.c | 32 ++++++++++++++++----------------
drivers/usb/host/fhci-hub.c | 16 ++++++++--------
drivers/usb/host/fhci-sched.c | 30 +++++++++++++++---------------
drivers/usb/host/fhci-tds.c | 14 +++++++-------
drivers/usb/host/fhci.h | 22 ++--------------------
6 files changed, 54 insertions(+), 72 deletions(-)
diff --git a/drivers/usb/host/fhci-dbg.c b/drivers/usb/host/fhci-dbg.c
index 6fe5500..f238cb3 100644
--- a/drivers/usb/host/fhci-dbg.c
+++ b/drivers/usb/host/fhci-dbg.c
@@ -41,7 +41,7 @@ void fhci_dbg_isr(struct fhci_hcd *fhci, int usb_er)
static int fhci_dfs_regs_show(struct seq_file *s, void *v)
{
struct fhci_hcd *fhci = s->private;
- struct fhci_regs __iomem *regs = fhci->regs;
+ struct qe_usb_ctlr __iomem *regs = fhci->regs;
seq_printf(s,
"mode: 0x%x\n" "addr: 0x%x\n"
@@ -50,11 +50,11 @@ static int fhci_dfs_regs_show(struct seq_file *s, void *v)
"status: 0x%x\n" "SOF timer: %d\n"
"frame number: %d\n"
"lines status: 0x%x\n",
- in_8(®s->usb_mod), in_8(®s->usb_addr),
- in_8(®s->usb_comm), in_be16(®s->usb_ep[0]),
- in_be16(®s->usb_event), in_be16(®s->usb_mask),
- in_8(®s->usb_status), in_be16(®s->usb_sof_tmr),
- in_be16(®s->usb_frame_num),
+ in_8(®s->usb_usmod), in_8(®s->usb_usadr),
+ in_8(®s->usb_uscom), in_be16(®s->usb_usep[0]),
+ in_be16(®s->usb_usber), in_be16(®s->usb_usbmr),
+ in_8(®s->usb_usbs), in_be16(®s->usb_ussft),
+ in_be16(®s->usb_usfrn),
fhci_ioports_check_bus_state(fhci));
return 0;
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index d262374..7da1a26 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -40,8 +40,8 @@ void fhci_start_sof_timer(struct fhci_hcd *fhci)
/* clear frame_n */
out_be16(&fhci->pram->frame_num, 0);
- out_be16(&fhci->regs->usb_sof_tmr, 0);
- setbits8(&fhci->regs->usb_mod, USB_MODE_SFTE);
+ out_be16(&fhci->regs->usb_ussft, 0);
+ setbits8(&fhci->regs->usb_usmod, USB_MODE_SFTE);
fhci_dbg(fhci, "<- %s\n", __func__);
}
@@ -50,7 +50,7 @@ void fhci_stop_sof_timer(struct fhci_hcd *fhci)
{
fhci_dbg(fhci, "-> %s\n", __func__);
- clrbits8(&fhci->regs->usb_mod, USB_MODE_SFTE);
+ clrbits8(&fhci->regs->usb_usmod, USB_MODE_SFTE);
gtm_stop_timer16(fhci->timer);
fhci_dbg(fhci, "<- %s\n", __func__);
@@ -58,7 +58,7 @@ void fhci_stop_sof_timer(struct fhci_hcd *fhci)
u16 fhci_get_sof_timer_count(struct fhci_usb *usb)
{
- return be16_to_cpu(in_be16(&usb->fhci->regs->usb_sof_tmr) / 12);
+ return be16_to_cpu(in_be16(&usb->fhci->regs->usb_ussft) / 12);
}
/* initialize the endpoint zero */
@@ -88,8 +88,8 @@ void fhci_usb_enable_interrupt(struct fhci_usb *usb)
enable_irq(fhci_to_hcd(fhci)->irq);
/* initialize the event register and mask register */
- out_be16(&usb->fhci->regs->usb_event, 0xffff);
- out_be16(&usb->fhci->regs->usb_mask, usb->saved_msk);
+ out_be16(&usb->fhci->regs->usb_usber, 0xffff);
+ out_be16(&usb->fhci->regs->usb_usbmr, usb->saved_msk);
/* enable the timer interrupts */
enable_irq(fhci->timer->irq);
@@ -109,7 +109,7 @@ void fhci_usb_disable_interrupt(struct fhci_usb *usb)
/* disable the usb interrupt */
disable_irq_nosync(fhci_to_hcd(fhci)->irq);
- out_be16(&usb->fhci->regs->usb_mask, 0);
+ out_be16(&usb->fhci->regs->usb_usbmr, 0);
}
usb->intr_nesting_cnt++;
}
@@ -119,9 +119,9 @@ static u32 fhci_usb_enable(struct fhci_hcd *fhci)
{
struct fhci_usb *usb = fhci->usb_lld;
- out_be16(&usb->fhci->regs->usb_event, 0xffff);
- out_be16(&usb->fhci->regs->usb_mask, usb->saved_msk);
- setbits8(&usb->fhci->regs->usb_mod, USB_MODE_EN);
+ out_be16(&usb->fhci->regs->usb_usber, 0xffff);
+ out_be16(&usb->fhci->regs->usb_usbmr, usb->saved_msk);
+ setbits8(&usb->fhci->regs->usb_usmod, USB_MODE_EN);
mdelay(100);
@@ -141,7 +141,7 @@ static u32 fhci_usb_disable(struct fhci_hcd *fhci)
usb->port_status == FHCI_PORT_LOW)
fhci_device_disconnected_interrupt(fhci);
- clrbits8(&usb->fhci->regs->usb_mod, USB_MODE_EN);
+ clrbits8(&usb->fhci->regs->usb_usmod, USB_MODE_EN);
return 0;
}
@@ -285,13 +285,13 @@ static int fhci_usb_init(struct fhci_hcd *fhci)
USB_E_IDLE_MASK |
USB_E_RESET_MASK | USB_E_SFT_MASK | USB_E_MSF_MASK);
- out_8(&usb->fhci->regs->usb_mod, USB_MODE_HOST | USB_MODE_EN);
+ out_8(&usb->fhci->regs->usb_usmod, USB_MODE_HOST | USB_MODE_EN);
/* clearing the mask register */
- out_be16(&usb->fhci->regs->usb_mask, 0);
+ out_be16(&usb->fhci->regs->usb_usbmr, 0);
/* initialing the event register */
- out_be16(&usb->fhci->regs->usb_event, 0xffff);
+ out_be16(&usb->fhci->regs->usb_usber, 0xffff);
if (endpoint_zero_init(usb, DEFAULT_DATA_MEM, DEFAULT_RING_LEN) != 0) {
fhci_usb_free(usb);
@@ -745,8 +745,8 @@ static int __devinit of_fhci_probe(struct
platform_device *ofdev)
}
/* Clear and disable any pending interrupts. */
- out_be16(&fhci->regs->usb_event, 0xffff);
- out_be16(&fhci->regs->usb_mask, 0);
+ out_be16(&fhci->regs->usb_usber, 0xffff);
+ out_be16(&fhci->regs->usb_usbmr, 0);
ret = usb_add_hcd(hcd, usb_irq, 0);
if (ret < 0)
diff --git a/drivers/usb/host/fhci-hub.c b/drivers/usb/host/fhci-hub.c
index 348fe62..6af2512 100644
--- a/drivers/usb/host/fhci-hub.c
+++ b/drivers/usb/host/fhci-hub.c
@@ -97,7 +97,7 @@ void fhci_port_disable(struct fhci_hcd *fhci)
/* Enable IDLE since we want to know if something comes along */
usb->saved_msk |= USB_E_IDLE_MASK;
- out_be16(&usb->fhci->regs->usb_mask, usb->saved_msk);
+ out_be16(&usb->fhci->regs->usb_usbmr, usb->saved_msk);
/* check if during the disconnection process attached new device */
if (port_status == FHCI_PORT_WAITING)
@@ -158,21 +158,21 @@ void fhci_port_reset(void *lld)
fhci_stop_sof_timer(fhci);
/* disable the USB controller */
- mode = in_8(&fhci->regs->usb_mod);
- out_8(&fhci->regs->usb_mod, mode & (~USB_MODE_EN));
+ mode = in_8(&fhci->regs->usb_usmod);
+ out_8(&fhci->regs->usb_usmod, mode & (~USB_MODE_EN));
/* disable idle interrupts */
- mask = in_be16(&fhci->regs->usb_mask);
- out_be16(&fhci->regs->usb_mask, mask & (~USB_E_IDLE_MASK));
+ mask = in_be16(&fhci->regs->usb_usbmr);
+ out_be16(&fhci->regs->usb_usbmr, mask & (~USB_E_IDLE_MASK));
fhci_io_port_generate_reset(fhci);
/* enable interrupt on this endpoint */
- out_be16(&fhci->regs->usb_mask, mask);
+ out_be16(&fhci->regs->usb_usbmr, mask);
/* enable the USB controller */
- mode = in_8(&fhci->regs->usb_mod);
- out_8(&fhci->regs->usb_mod, mode | USB_MODE_EN);
+ mode = in_8(&fhci->regs->usb_usmod);
+ out_8(&fhci->regs->usb_usmod, mode | USB_MODE_EN);
fhci_start_sof_timer(fhci);
fhci_dbg(fhci, "<- %s\n", __func__);
diff --git a/drivers/usb/host/fhci-sched.c b/drivers/usb/host/fhci-sched.c
index 2df851b..2dc8a40 100644
--- a/drivers/usb/host/fhci-sched.c
+++ b/drivers/usb/host/fhci-sched.c
@@ -132,8 +132,8 @@ void fhci_flush_all_transmissions(struct fhci_usb *usb)
u8 mode;
struct td *td;
- mode = in_8(&usb->fhci->regs->usb_mod);
- clrbits8(&usb->fhci->regs->usb_mod, USB_MODE_EN);
+ mode = in_8(&usb->fhci->regs->usb_usmod);
+ clrbits8(&usb->fhci->regs->usb_usmod, USB_MODE_EN);
fhci_flush_bds(usb);
@@ -147,9 +147,9 @@ void fhci_flush_all_transmissions(struct fhci_usb *usb)
usb->actual_frame->frame_status = FRAME_END_TRANSMISSION;
/* reset the event register */
- out_be16(&usb->fhci->regs->usb_event, 0xffff);
+ out_be16(&usb->fhci->regs->usb_usber, 0xffff);
/* enable the USB controller */
- out_8(&usb->fhci->regs->usb_mod, mode | USB_MODE_EN);
+ out_8(&usb->fhci->regs->usb_usmod, mode | USB_MODE_EN);
}
/*
@@ -414,7 +414,7 @@ static void sof_interrupt(struct fhci_hcd *fhci)
usb->port_status = FHCI_PORT_FULL;
/* Disable IDLE */
usb->saved_msk &= ~USB_E_IDLE_MASK;
- out_be16(&usb->fhci->regs->usb_mask, usb->saved_msk);
+ out_be16(&usb->fhci->regs->usb_usbmr, usb->saved_msk);
}
gtm_set_exact_timer16(fhci->timer, usb->max_frame_usage, false);
@@ -433,14 +433,14 @@ void fhci_device_disconnected_interrupt(struct
fhci_hcd *fhci)
fhci_dbg(fhci, "-> %s\n", __func__);
fhci_usb_disable_interrupt(usb);
- clrbits8(&usb->fhci->regs->usb_mod, USB_MODE_LSS);
+ clrbits8(&usb->fhci->regs->usb_usmod, USB_MODE_LSS);
usb->port_status = FHCI_PORT_DISABLED;
fhci_stop_sof_timer(fhci);
/* Enable IDLE since we want to know if something comes along */
usb->saved_msk |= USB_E_IDLE_MASK;
- out_be16(&usb->fhci->regs->usb_mask, usb->saved_msk);
+ out_be16(&usb->fhci->regs->usb_usbmr, usb->saved_msk);
usb->vroot_hub->port.wPortStatus &= ~USB_PORT_STAT_CONNECTION;
usb->vroot_hub->port.wPortChange |= USB_PORT_STAT_C_CONNECTION;
@@ -473,7 +473,7 @@ void fhci_device_connected_interrupt(struct fhci_hcd *fhci)
}
usb->port_status = FHCI_PORT_LOW;
- setbits8(&usb->fhci->regs->usb_mod, USB_MODE_LSS);
+ setbits8(&usb->fhci->regs->usb_usmod, USB_MODE_LSS);
usb->vroot_hub->port.wPortStatus |=
(USB_PORT_STAT_LOW_SPEED |
USB_PORT_STAT_CONNECTION);
@@ -491,7 +491,7 @@ void fhci_device_connected_interrupt(struct fhci_hcd *fhci)
}
usb->port_status = FHCI_PORT_FULL;
- clrbits8(&usb->fhci->regs->usb_mod, USB_MODE_LSS);
+ clrbits8(&usb->fhci->regs->usb_usmod, USB_MODE_LSS);
usb->vroot_hub->port.wPortStatus &=
~USB_PORT_STAT_LOW_SPEED;
usb->vroot_hub->port.wPortStatus |=
@@ -535,7 +535,7 @@ static void abort_transmission(struct fhci_usb *usb)
/* issue stop Tx command */
qe_issue_cmd(QE_USB_STOP_TX, QE_CR_SUBBLOCK_USB, EP_ZERO, 0);
/* flush Tx FIFOs */
- out_8(&usb->fhci->regs->usb_comm, USB_CMD_FLUSH_FIFO | EP_ZERO);
+ out_8(&usb->fhci->regs->usb_uscom, USB_CMD_FLUSH_FIFO | EP_ZERO);
udelay(1000);
/* reset Tx BDs */
fhci_flush_bds(usb);
@@ -555,11 +555,11 @@ irqreturn_t fhci_irq(struct usb_hcd *hcd)
usb = fhci->usb_lld;
- usb_er |= in_be16(&usb->fhci->regs->usb_event) &
- in_be16(&usb->fhci->regs->usb_mask);
+ usb_er |= in_be16(&usb->fhci->regs->usb_usber) &
+ in_be16(&usb->fhci->regs->usb_usbmr);
/* clear event bits for next time */
- out_be16(&usb->fhci->regs->usb_event, usb_er);
+ out_be16(&usb->fhci->regs->usb_usber, usb_er);
fhci_dbg_isr(fhci, usb_er);
@@ -573,7 +573,7 @@ irqreturn_t fhci_irq(struct usb_hcd *hcd)
/* Turn on IDLE since we want to disconnect */
usb->saved_msk |= USB_E_IDLE_MASK;
- out_be16(&usb->fhci->regs->usb_event,
+ out_be16(&usb->fhci->regs->usb_usber,
usb->saved_msk);
} else if (usb->port_status == FHCI_PORT_DISABLED) {
if (fhci_ioports_check_bus_state(fhci) == 1)
@@ -611,7 +611,7 @@ irqreturn_t fhci_irq(struct usb_hcd *hcd)
/* XXX usb->port_status = FHCI_PORT_WAITING; */
/* Disable IDLE */
usb->saved_msk &= ~USB_E_IDLE_MASK;
- out_be16(&usb->fhci->regs->usb_mask,
+ out_be16(&usb->fhci->regs->usb_usbmr,
usb->saved_msk);
} else {
fhci_dbg_isr(fhci, -1);
diff --git a/drivers/usb/host/fhci-tds.c b/drivers/usb/host/fhci-tds.c
index c5ed881..1498061 100644
--- a/drivers/usb/host/fhci-tds.c
+++ b/drivers/usb/host/fhci-tds.c
@@ -249,7 +249,7 @@ void fhci_init_ep_registers(struct fhci_usb *usb,
struct endpoint *ep,
u8 rt;
/* set the endpoint registers according to the endpoint */
- out_be16(&usb->fhci->regs->usb_ep[0],
+ out_be16(&usb->fhci->regs->usb_usep[0],
USB_TRANS_CTR | USB_EP_MF | USB_EP_RTE);
out_be16(&usb->fhci->pram->ep_ptr[0],
cpm_muram_offset(ep->ep_pram_ptr));
@@ -463,7 +463,7 @@ u32 fhci_host_transaction(struct fhci_usb *usb,
cq_put(&ep->conf_frame_Q, pkt);
if (cq_howmany(&ep->conf_frame_Q) == 1)
- out_8(&usb->fhci->regs->usb_comm, USB_CMD_STR_FIFO);
+ out_8(&usb->fhci->regs->usb_uscom, USB_CMD_STR_FIFO);
return 0;
}
@@ -535,8 +535,8 @@ void fhci_flush_actual_frame(struct fhci_usb *usb)
struct endpoint *ep = usb->ep0;
/* disable the USB controller */
- mode = in_8(&usb->fhci->regs->usb_mod);
- out_8(&usb->fhci->regs->usb_mod, mode & ~USB_MODE_EN);
+ mode = in_8(&usb->fhci->regs->usb_usmod);
+ out_8(&usb->fhci->regs->usb_usmod, mode & ~USB_MODE_EN);
tb_ptr = in_be16(&ep->ep_pram_ptr->tx_bd_ptr);
td = cpm_muram_addr(tb_ptr);
@@ -571,9 +571,9 @@ void fhci_flush_actual_frame(struct fhci_usb *usb)
usb->actual_frame->frame_status = FRAME_TIMER_END_TRANSMISSION;
/* reset the event register */
- out_be16(&usb->fhci->regs->usb_event, 0xffff);
+ out_be16(&usb->fhci->regs->usb_usber, 0xffff);
/* enable the USB controller */
- out_8(&usb->fhci->regs->usb_mod, mode | USB_MODE_EN);
+ out_8(&usb->fhci->regs->usb_usmod, mode | USB_MODE_EN);
}
/* handles Tx confirm and Tx error interrupt */
@@ -613,7 +613,7 @@ void fhci_host_transmit_actual_frame(struct fhci_usb *usb)
/* start transmit only if we have something in the TDs */
if (in_be16(&td->status) & TD_R)
- out_8(&usb->fhci->regs->usb_comm, USB_CMD_STR_FIFO);
+ out_8(&usb->fhci->regs->usb_uscom, USB_CMD_STR_FIFO);
if (in_be32(&ep->conf_td->buf_ptr) == DUMMY_BD_BUFFER) {
out_be32(&old_td->buf_ptr, 0);
diff --git a/drivers/usb/host/fhci.h b/drivers/usb/host/fhci.h
index dc6939a..8a4cb8b74 100644
--- a/drivers/usb/host/fhci.h
+++ b/drivers/usb/host/fhci.h
@@ -28,6 +28,7 @@
#include <linux/usb.h>
#include <linux/usb/hcd.h>
#include <asm/qe.h>
+#include <asm/immap_qe.h>
#define USB_CLOCK 48000000
@@ -173,25 +174,6 @@
#define USB_E_TXB_MASK 0x0002
#define USB_E_RXB_MASK 0x0001
-/* Freescale USB Host controller registers */
-struct fhci_regs {
- u8 usb_mod; /* mode register */
- u8 usb_addr; /* address register */
- u8 usb_comm; /* command register */
- u8 reserved1[1];
- __be16 usb_ep[4]; /* endpoint register */
- u8 reserved2[4];
- __be16 usb_event; /* event register */
- u8 reserved3[2];
- __be16 usb_mask; /* mask register */
- u8 reserved4[1];
- u8 usb_status; /* status register */
- __be16 usb_sof_tmr; /* Start Of Frame timer */
- u8 reserved5[2];
- __be16 usb_frame_num; /* frame number register */
- u8 reserved6[1];
-};
-
/* Freescale USB HOST */
struct fhci_pram {
__be16 ep_ptr[4]; /* Endpoint porter reg */
@@ -267,7 +249,7 @@ struct fhci_hcd {
int gpios[NUM_GPIOS];
bool alow_gpios[NUM_GPIOS];
- struct fhci_regs __iomem *regs; /* I/O memory used to communicate */
+ struct qe_usb_ctlr __iomem *regs; /* I/O memory used to communicate */
struct fhci_pram __iomem *pram; /* Parameter RAM */
struct gtm_timer *timer;
--
1.7.5.4
^ permalink raw reply related
* Re: CPU-local TLB flushing
From: Michael Ellerman @ 2012-06-19 0:47 UTC (permalink / raw)
To: Seth Jennings; +Cc: Robert Jennings, linuxppc-dev, Nitin Gupta, Minchan Kim
In-Reply-To: <4FDF95C5.3090903@linux.vnet.ibm.com>
On Mon, 2012-06-18 at 15:55 -0500, Seth Jennings wrote:
> This is a continuation of a thread a few months ago:
...
>
> With local_flush_tlb_kernel_range() being a stub,
> the new function local_unmap_kernel_range() is exactly
> the same as unmap_kernel_range() since
> local_flush_tlb_kernel_range() and flush_tlb_kernel_range()
> are both stubs on ppc64.
>
> My knowledge of the ppc64 hashing tlb design is almost
> nothing, but it seems like this should work, albeit slowly
> since it would be a global flush rather than cpu-local.
>
> I was wondering if anyone could tell me why this doesn't work,
> and what needs to be done to make it work.
Hi Seth,
I don't know it that well either, but the way I think it should be
working is:
unmap_kernel_range()
-> vunmap_page_range()
-> vunmap_pud/pmd/pte_range()
-> ptep_get_and_clear() (arch/powerpc/include/asm/pgtable-ppc64.h)
-> pte_update() (arch/powerpc/include/asm/pgtable-ppc64.h)
-> hpte_need_flush()
-> flush_hash_page() (because you don't have a batch active - I assume)
-> pSeries_lpar_hpte_invalidate()
So step one would be to confirm you're getting that far, that would at
least confirm we are doing the invalidate.
cheers
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/PCI: move DMA & IRQ init to device_add() notification path
From: Benjamin Herrenschmidt @ 2012-06-18 22:55 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Michal Simek, Hiroo Matsumoto, microblaze-uclinux,
Kenji Kaneshige, Jesse Larrew, jbarnes, Dominik Brodowski,
linux-pci, linuxppc-dev
In-Reply-To: <CAErSpo6mbzqMuewBySk5kA8E9RwOVZqOEcnM4Hy541B3pta9SQ@mail.gmail.com>
On Mon, 2012-06-18 at 15:06 -0600, Bjorn Helgaas wrote:
> We're moving the CardBus IRQ config from before pci_bus_add_devices()
> to after. I see why you did that: we're proposing to do the powerpc
> DMA & IRQ setup in pci_bus_add_devices(), so we don't want to have the
> powerpc IRQ init clobber the CardBus IRQ config.
>
> But a driver can claim the device as soon as we call
> pci_bus_add_devices(), so we're potentially changing dev->irq after a
> driver has already looked at it, which sounds like a bug.
>
> There are only five possibilities for powerpc pci_irq_fixup:
>
> ppc47x_pci_irq_fixup
> mpc85xx_cds_pci_irq_fixup
> maple_pci_irq_fixup
> pmac_pci_irq_fixup
> rtas_msi_pci_irq_fixup
>
> If these were normal PCI header quirks instead, they could run
> earlier, and we wouldn't need to move this
> cardbus_config_irq_and_cls() call. Is it possible to make these
> quirks, Ben?
Wait ... why are those fixups relevant ? They have to run after
pci_read_irq_line() (which should have been called pcibios_read_irq_line
really) but that's fine, we call both back to back....
The problem has to do with the fact that we setup pdev->irq inside
pci_bus_add_devices() with the new proposed code (the fixup itself is
just a detail).
You want cardbus to "quirk" the irq after that's been fixed up... maybe
that's a case for moving cardbus_config_irq_and_cls() to
pci_enable_device() ? Or add another hook inside
pci_bus_add_devices()...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Benjamin Herrenschmidt @ 2012-06-18 22:45 UTC (permalink / raw)
To: Ben Collins; +Cc: Bjorn Helgaas, Paul Mackerras, linuxppc-dev
In-Reply-To: <0F5B9B19-CC65-4DF0-92FB-C34767C42E80@servergy.com>
On Mon, 2012-06-18 at 16:04 -0500, Ben Collins wrote:
> On Jun 18, 2012, at 3:39 PM, Benjamin Herrenschmidt wrote:
>
> > On Mon, 2012-06-18 at 09:23 -0600, Bjorn Helgaas wrote:
> >> Ooh, sorry about that. Who's going to push this fix? I don't see it
> >> in Linus' tree yet. If you want me to, please forward me the original
> >> patch.
> >
> > I want to double check something. We are still printing something wrong
> > in the kernel log, so it looks like we have some incorrect carry in some
> > arithmetic happening somewhere.
>
> Can we at least get this patch in to get things working again? It's still a regression either way.
Sure, I'm only just back from my sick leave, I haven't had a chance to
go through the pending patches yet.
Cheers,
Ben.
> > Cheers,
> > Ben.
> >
> >
>
> --
> Ben Collins
> Servergy, Inc.
> (757) 243-7557
>
> CONFIDENTIALITY NOTICE: This communication contains privileged and/or confidential information; and should be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy.
^ permalink raw reply
* Re: RCU stalls on 32-bit pmac SMP
From: Paul E. McKenney @ 2012-06-18 21:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1340052331.2372.32.camel@pasglop>
On Tue, Jun 19, 2012 at 06:45:31AM +1000, Benjamin Herrenschmidt wrote:
> Hi Paul !
>
> On Mon, 2012-06-18 at 10:05 -0700, Paul E. McKenney wrote:
>
> > > sd 0:0:0:0: Attached scsi generic sg0 type 0
> > > sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15
> > > sd 0:0:0:0: [sda] Attached SCSI disk
> > > scsi 0:0:1:0: Direct-Access ATA ST380021A 3.75 PQ: 0 ANSI: 5
> > > sd 0:0:1:0: [sdb] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
> > > sd 0:0:1:0: [sdb] Write Protect is off
> > > sd 0:0:1:0: Attached scsi generic sg1 type 0
> > > sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
> > > sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > > INFO: rcu_sched self-detected stall on CPU { 0} (t=16163 jiffies)
> > > Call Trace:
> > > INFO: rcu_sched self-detected stall on CPU { 1} (t=16163 jiffies)
> > > Call Trace:
> > > [ef877d30] [c0008d04] show_stack+0x50/0x158 (unreliable)
> > > [ef877d70] [c0097fe4] __rcu_pending+0x184/0x46c
> > > [ef877da0] [c00991a0] rcu_check_callbacks+0x7c/0x168
> > > [ef877dc0] [c0044a40] update_process_times+0x3c/0x70
> > > [ef877de0] [c0083a3c] tick_sched_timer+0x88/0x100
> > > [ef877e10] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> > > [ef877e30] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> > > [ef877ea0] [c000b5c4] timer_interrupt+0x1cc/0x204
> > > [ef877ed0] [c0011b88] ret_from_except+0x0/0x1c
> > > --- Exception: 901 at cpu_idle+0xe4/0x188
> >
> > Am I reading this correctly? Did the system really take a scheduling-clock
> > interrupt from within another scheduling-clock interrupt?
>
> Not that I can see. I see only one interrupt on that CPU. It was idle,
> took a timer interrupt -> hrtimer ... etc... RCU boom !
>
> > If so, my first question is "Why did the scheduling-clock interrupt
> > run for so long?" ;-)
>
> This is still that CPU:
>
> > LR = cpu_idle+0xc8/0x188
> > > [ef877f90] [c00097e8] cpu_idle+0x60/0x188 (unreliable)
> > > [ef877fc0] [c046531c] start_secondary+0x2c8/0x2cc
> > > [ef877ff0] [00003278] 0x3278
>
> And now we have the other one:
>
> > > [ef873b60] [c0008d04] show_stack+0x50/0x158 (unreliable)
> > > [ef873ba0] [c0097fe4] __rcu_pending+0x184/0x46c
> > > [ef873bd0] [c0099240] rcu_check_callbacks+0x11c/0x168
> > > [ef873bf0] [c0044a40] update_process_times+0x3c/0x70
> > > [ef873c10] [c0083a3c] tick_sched_timer+0x88/0x100
> > > [ef873c40] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> > > [ef873c60] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> > > [ef873cd0] [c000b5c4] timer_interrupt+0x1cc/0x204
> > > [ef873d00] [c0011b88] ret_from_except+0x0/0x1c
> > > --- Exception: 901 at wake_up_new_task+0x134/0x16c
> > > LR = wake_up_new_task+0x134/0x16c
> > > [ef873dc0] [c0065f08] wake_up_new_task+0xfc/0x16c (unreliable)
> > > [ef873df0] [c0035530] do_fork+0xe8/0x2bc
> > > [ef873e30] [c0008a4c] sys_clone+0x50/0x90
> > > [ef873e50] [c00114b8] ret_from_syscall+0x0/0x40
> > > --- Exception: c00 at kernel_thread+0x28/0x68
> > > LR = __call_usermodehelper+0x40/0xdc
> > > [ef873f10] [c005f5c8] async_run_entry_fn+0x128/0x1e4 (unreliable)
> > > [ef873f20] [ef878c00] 0xef878c00
> > > [ef873f40] [c004e668] process_one_work+0x150/0x3f0
> > > [ef873f70] [c00514f0] worker_thread+0x18c/0x37c
> > > [ef873fb0] [c00567bc] kthread+0x84/0x88
> > > [ef873ff0] [c000f514] kernel_thread+0x4c/0x68
>
> Here what we have is a kernel thread trying to call_usermodehelper
> (probably the hotplug stuff from discovering the disk) taking a timer
> interrupt from wake_up_new_task.
>
> Looks like the hang has to be with some RCU stuff update_process_times
> does vs. taking the interrupt in wake_up_new_task ? Hard to tell...
The RCU stuff from update_process_times() is usually the diagnostic.
> This happens more/less reliably once at boot on this machine, then no
> more (after the long pause the machine moves on, apparently fine).
What happens if you reduce the stall-warning timeout? You can use either
the CONFIG_RCU_CPU_STALL_TIMEOUT kernel config parameter or the
rcutree.rcu_cpu_stall_timeout boot parameter.
If you can get two stall-warning messages to appear during the hang,
comparing the stacks is usually informative.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/PCI: move DMA & IRQ init to device_add() notification path
From: Bjorn Helgaas @ 2012-06-18 21:06 UTC (permalink / raw)
To: Hiroo Matsumoto
Cc: Michal Simek, microblaze-uclinux, Kenji Kaneshige, Jesse Larrew,
jbarnes, Dominik Brodowski, linux-pci, linuxppc-dev
In-Reply-To: <20120523223700.24276.76804.stgit@bhelgaas.mtv.corp.google.com>
I'm trying to make some progress on these patches, but I'm concerned
about this bit:
> diff --git a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
> index 24caeaf..a980691 100644
> --- a/drivers/pcmcia/cardbus.c
> +++ b/drivers/pcmcia/cardbus.c
> @@ -85,7 +84,6 @@ int __ref cb_alloc(struct pcmcia_socket *s)
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0pci_bus_size_bridges(bus);
> =A0 =A0 =A0 =A0pci_bus_assign_resources(bus);
> - =A0 =A0 =A0 cardbus_config_irq_and_cls(bus, s->pci_irq);
>
> =A0 =A0 =A0 =A0/* socket specific tune function */
> =A0 =A0 =A0 =A0if (s->tune_bridge)
> @@ -93,6 +91,7 @@ int __ref cb_alloc(struct pcmcia_socket *s)
>
> =A0 =A0 =A0 =A0pci_enable_bridges(bus);
> =A0 =A0 =A0 =A0pci_bus_add_devices(bus);
> + =A0 =A0 =A0 cardbus_config_irq_and_cls(bus, s->pci_irq);
>
> =A0 =A0 =A0 =A0return 0;
> =A0}
We're moving the CardBus IRQ config from before pci_bus_add_devices()
to after. I see why you did that: we're proposing to do the powerpc
DMA & IRQ setup in pci_bus_add_devices(), so we don't want to have the
powerpc IRQ init clobber the CardBus IRQ config.
But a driver can claim the device as soon as we call
pci_bus_add_devices(), so we're potentially changing dev->irq after a
driver has already looked at it, which sounds like a bug.
There are only five possibilities for powerpc pci_irq_fixup:
ppc47x_pci_irq_fixup
mpc85xx_cds_pci_irq_fixup
maple_pci_irq_fixup
pmac_pci_irq_fixup
rtas_msi_pci_irq_fixup
If these were normal PCI header quirks instead, they could run
earlier, and we wouldn't need to move this
cardbus_config_irq_and_cls() call. Is it possible to make these
quirks, Ben?
Bjorn
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Ben Collins @ 2012-06-18 21:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Bjorn Helgaas, Paul Mackerras, linuxppc-dev
In-Reply-To: <1340051997.2372.27.camel@pasglop>
On Jun 18, 2012, at 3:39 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-06-18 at 09:23 -0600, Bjorn Helgaas wrote:
>> Ooh, sorry about that. Who's going to push this fix? I don't see it
>> in Linus' tree yet. If you want me to, please forward me the =
original
>> patch.=20
>=20
> I want to double check something. We are still printing something =
wrong
> in the kernel log, so it looks like we have some incorrect carry in =
some
> arithmetic happening somewhere.
Can we at least get this patch in to get things working again? It's =
still a regression either way.
> Cheers,
> Ben.
>=20
>=20
--
Ben Collins
Servergy, Inc.
(757) 243-7557
CONFIDENTIALITY NOTICE: This communication contains privileged and/or =
confidential information; and should be maintained with the strictest =
confidence. It is intended solely for the use of the person or entity in =
which it is addressed. If you are not the intended recipient, you are =
STRICTLY PROHIBITED from disclosing, copying, distributing or using any =
of this information. If you received this communication in error, please =
contact the sender immediately and destroy the material in its entirety, =
whether electronic or hard copy.
^ permalink raw reply
* CPU-local TLB flushing
From: Seth Jennings @ 2012-06-18 20:55 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Cc: Minchan Kim, Robert Jennings, Nitin Gupta
This is a continuation of a thread a few months ago:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-February/095775.html
zsmalloc is now in the staging tree and there are patches
on lkml to convert the x86 only tlb flushing code to arch
independent code.
https://lkml.org/lkml/2012/5/14/55
A quick back story, zsmalloc does some pte/tlb manipulation
to quickly map a pair of pages into a single VM area. It
does this with interrupts disabled in a preallocated per-cpu
VM area, which means the mapping only exists in the TLB of
the cpu that does the mapping and, therefore, only needs to
be flushed on that same cpu during the unmapping process.
Right now, zsmalloc uses __flush_tlb_one() on x86 to do a
cpu-local single entry tlb flush. Afaict, there is no such
call on ppc64.
The patch replaces that x86 call with a call to a new function,
local_unmap_kernel_range(), which is exactly the same as
unmap_kernel_range() in mm/vmalloc.c except that it calls
local_flush_tlb_kernel_range() instead of
flush_tlb_kernel_range().
A few archs support local_flush_tlb_kernel_range() already and
another patch in the patchset above, introduces this function
for x86; basically a wrapper for __flush_tlb_single().
For PPC_STD_MMU_64, it looked like all the tlb flushing
functions were just stubs, so I just added a stub for
local_flush_tlb_kernel_range(). This was stable running
a single threaded application, bound to one cpu, but crashes
with even two threads.
With local_flush_tlb_kernel_range() being a stub,
the new function local_unmap_kernel_range() is exactly
the same as unmap_kernel_range() since
local_flush_tlb_kernel_range() and flush_tlb_kernel_range()
are both stubs on ppc64.
My knowledge of the ppc64 hashing tlb design is almost
nothing, but it seems like this should work, albeit slowly
since it would be a global flush rather than cpu-local.
I was wondering if anyone could tell me why this doesn't work,
and what needs to be done to make it work.
Thanks in advance for any help! Let me know if you need
clarification on something.
--
Seth
^ permalink raw reply
* Re: [RFC/PATCH] i2c/powermac: Improve detection of devices from device-tree
From: Benjamin Herrenschmidt @ 2012-06-18 20:51 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m28vfkvkuz.fsf@igel.home>
On Mon, 2012-06-18 at 14:57 +0200, Andreas Schwab wrote:
> These are the remaining failures on PowerMac7,3:
>
> i2c i2c-5: No i2c address for /ht@0,f2000000/pci@1/mac-io@7/i2c@18000/i2c-modem
> i2c i2c-6: i2c-powermac: modalias failure on /u3@0,f8000000/i2c@f8001000/cereal@1c0
Right, those are known and harmless. I might add code to silence them.
Thanks for testing.
Cheers,
Ben.
^ permalink raw reply
* Re: RCU stalls on 32-bit pmac SMP
From: Benjamin Herrenschmidt @ 2012-06-18 20:45 UTC (permalink / raw)
To: paulmck; +Cc: linuxppc-dev
In-Reply-To: <20120618170521.GD2400@linux.vnet.ibm.com>
Hi Paul !
On Mon, 2012-06-18 at 10:05 -0700, Paul E. McKenney wrote:
> > sd 0:0:0:0: Attached scsi generic sg0 type 0
> > sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15
> > sd 0:0:0:0: [sda] Attached SCSI disk
> > scsi 0:0:1:0: Direct-Access ATA ST380021A 3.75 PQ: 0 ANSI: 5
> > sd 0:0:1:0: [sdb] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
> > sd 0:0:1:0: [sdb] Write Protect is off
> > sd 0:0:1:0: Attached scsi generic sg1 type 0
> > sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
> > sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> > INFO: rcu_sched self-detected stall on CPU { 0} (t=16163 jiffies)
> > Call Trace:
> > INFO: rcu_sched self-detected stall on CPU { 1} (t=16163 jiffies)
> > Call Trace:
> > [ef877d30] [c0008d04] show_stack+0x50/0x158 (unreliable)
> > [ef877d70] [c0097fe4] __rcu_pending+0x184/0x46c
> > [ef877da0] [c00991a0] rcu_check_callbacks+0x7c/0x168
> > [ef877dc0] [c0044a40] update_process_times+0x3c/0x70
> > [ef877de0] [c0083a3c] tick_sched_timer+0x88/0x100
> > [ef877e10] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> > [ef877e30] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> > [ef877ea0] [c000b5c4] timer_interrupt+0x1cc/0x204
> > [ef877ed0] [c0011b88] ret_from_except+0x0/0x1c
> > --- Exception: 901 at cpu_idle+0xe4/0x188
>
> Am I reading this correctly? Did the system really take a scheduling-clock
> interrupt from within another scheduling-clock interrupt?
Not that I can see. I see only one interrupt on that CPU. It was idle,
took a timer interrupt -> hrtimer ... etc... RCU boom !
> If so, my first question is "Why did the scheduling-clock interrupt
> run for so long?" ;-)
This is still that CPU:
> LR = cpu_idle+0xc8/0x188
> > [ef877f90] [c00097e8] cpu_idle+0x60/0x188 (unreliable)
> > [ef877fc0] [c046531c] start_secondary+0x2c8/0x2cc
> > [ef877ff0] [00003278] 0x3278
And now we have the other one:
> > [ef873b60] [c0008d04] show_stack+0x50/0x158 (unreliable)
> > [ef873ba0] [c0097fe4] __rcu_pending+0x184/0x46c
> > [ef873bd0] [c0099240] rcu_check_callbacks+0x11c/0x168
> > [ef873bf0] [c0044a40] update_process_times+0x3c/0x70
> > [ef873c10] [c0083a3c] tick_sched_timer+0x88/0x100
> > [ef873c40] [c005b11c] __run_hrtimer.clone.29+0x54/0x104
> > [ef873c60] [c005bf44] hrtimer_interrupt+0x158/0x3f8
> > [ef873cd0] [c000b5c4] timer_interrupt+0x1cc/0x204
> > [ef873d00] [c0011b88] ret_from_except+0x0/0x1c
> > --- Exception: 901 at wake_up_new_task+0x134/0x16c
> > LR = wake_up_new_task+0x134/0x16c
> > [ef873dc0] [c0065f08] wake_up_new_task+0xfc/0x16c (unreliable)
> > [ef873df0] [c0035530] do_fork+0xe8/0x2bc
> > [ef873e30] [c0008a4c] sys_clone+0x50/0x90
> > [ef873e50] [c00114b8] ret_from_syscall+0x0/0x40
> > --- Exception: c00 at kernel_thread+0x28/0x68
> > LR = __call_usermodehelper+0x40/0xdc
> > [ef873f10] [c005f5c8] async_run_entry_fn+0x128/0x1e4 (unreliable)
> > [ef873f20] [ef878c00] 0xef878c00
> > [ef873f40] [c004e668] process_one_work+0x150/0x3f0
> > [ef873f70] [c00514f0] worker_thread+0x18c/0x37c
> > [ef873fb0] [c00567bc] kthread+0x84/0x88
> > [ef873ff0] [c000f514] kernel_thread+0x4c/0x68
Here what we have is a kernel thread trying to call_usermodehelper
(probably the hotplug stuff from discovering the disk) taking a timer
interrupt from wake_up_new_task.
Looks like the hang has to be with some RCU stuff update_process_times
does vs. taking the interrupt in wake_up_new_task ? Hard to tell...
This happens more/less reliably once at boot on this machine, then no
more (after the long pause the machine moves on, apparently fine).
Cheers,
Ben.
> > pata-macio 0.00020000:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 0
> > scsi1 : pata_macio
> > ata2: PATA max MWDMA2 irq 20
> > sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13
> > sd 0:0:1:0: [sdb] Attached SCSI disk
> > ata2.00: ATAPI: PIONEER DVD-RW DVR-104, A227, max UDMA/33
> > ata2.00: configured for MWDMA2
> > scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-104 A227 PQ: 0 ANSI: 5
> > pata-macio 0.00021000:ata-3: Activating pata-macio chipset KeyLargo ATA-3, Apple bus ID 1
> > scsi2 : pata_macio
> > ata3: PATA max MWDMA2 irq 21
> > sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
> > cdrom: Uniform CD-ROM driver Revision: 3.20
> > sr 1:0:0:0: Attached scsi CD-ROM sr0
> > pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
> > sr 1:0:0:0: Attached scsi generic sg2 type 5
> > sungem.c:v1.0 David S. Miller <davem@redhat.com>
> > gem 0002:20:0f.0: eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:93:6f:04:b2
> > PPP generic driver version 2.4.2
> > PPP Deflate Compression module registered
> > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> > ohci_hcd 0001:10:18.0: OHCI Host Controller
> > ohci_hcd 0001:10:18.0: new USB bus registered, assigned bus number 1
> > ohci_hcd 0001:10:18.0: irq 27, io mem 0x80081000
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 2 ports detected
> > ohci_hcd 0001:10:19.0: OHCI Host Controller
> > ohci_hcd 0001:10:19.0: new USB bus registered, assigned bus number 2
> > ohci_hcd 0001:10:19.0: irq 28, io mem 0x80080000
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 2 ports detected
> > mousedev: PS/2 mouse device common for all mice
> > usbcore: registered new interface driver appletouch
> > PowerMac i2c bus pmu 2 registered
> > i2c i2c-0: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/rtc
> > i2c i2c-0: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/power-mgt
> > PowerMac i2c bus pmu 1 registered
> > i2c i2c-1: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/rtc
> > i2c i2c-1: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/via-pmu@16000/power-mgt
> > PowerMac i2c bus mac-io 0 registered
> > i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/cereal
> > i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/deq
> > i2c i2c-2: i2c-powermac: invalid reg on /pci@f2000000/mac-io@17/i2c@18000/i2c-modem
> > PowerMac i2c bus uni-n 1 registered
> > i2c i2c-3: i2c-powermac: invalid reg on /uni-n@f8000000/i2c@f8001000/cereal
> > PowerMac i2c bus uni-n 0 registered
> > i2c i2c-4: i2c-powermac: invalid reg on /uni-n@f8000000/i2c@f8001000/cereal
> > APM Battery Driver
> > usbcore: registered new interface driver usbhid
> > usbhid: USB HID core driver
> > oprofile: using ppc/7450 performance monitoring.
> > TCP: cubic registered
> > Initializing XFRM netlink socket
> > NET: Registered protocol family 17
> > NET: Registered protocol family 15
> > Key type dns_resolver registered
> > PM: Hibernation image not present or could not be loaded.
> > input: PMU as /devices/virtual/input/input0
> > kjournald starting. Commit interval 5 seconds
> > EXT3-fs (sda15): mounted filesystem with writeback data mode
> > VFS: Mounted root (ext3 filesystem) readonly on device 8:15.
> > usb 1-1: new full-speed USB device number 2 using ohci_hcd
> > devtmpfs: mounted
> > Freeing unused kernel memory: 240k freed
> > hub 1-1:1.0: USB hub found
> > hub 1-1:1.0: 3 ports detected
> > usb 1-2: new full-speed USB device number 3 using ohci_hcd
> > hub 1-2:1.0: USB hub found
> > hub 1-2:1.0: 3 ports detected
> > usb 1-1.3: new full-speed USB device number 4 using ohci_hcd
> > input: Mitsumi Electric Apple Extended USB Keyboard as /devices/pci0001:10/0001:10:18.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
> > hid-generic 0003:05AC:020B.0001: input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:18.0-1.3/input0
> > input: Mitsumi Electric Apple Extended USB Keyboard as /devices/pci0001:10/0001:10:18.0/usb1/1-1/1-1.3/1-1.3:1.1/input/input2
> > hid-generic 0003:05AC:020B.0002: input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:18.0-1.3/input1
> > usb 1-2.3: new low-speed USB device number 5 using ohci_hcd
> > hid-generic 0003:05AC:9219.0003: claimed by neither input, hiddev nor hidraw
> > udevd[1209]: starting version 175
> > EXT3-fs (sda15): using internal journal
> > sungem_phy: PHY ID: 2060e1, addr: 0
> > gem 0002:20:0f.0: eth0: Found BCM5421 PHY
> > gem 0002:20:0f.0: eth0: Link is up at 100 Mbps, full-duplex
> > gem 0002:20:0f.0: eth0: Pause is enabled (rxfifo: 10240 off: 7168 on: 5632)
> > sshd (2042): /proc/2042/oom_adj is deprecated, please use /proc/2042/oom_score_adj instead.
> >
> >
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Benjamin Herrenschmidt @ 2012-06-18 20:39 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linuxppc-dev, Paul Mackerras, Ben Collins
In-Reply-To: <CAErSpo4pDOigbvF3SPzOUqx79d_-8yHWrc8TsWChG9indB+k_A@mail.gmail.com>
On Mon, 2012-06-18 at 09:23 -0600, Bjorn Helgaas wrote:
> Ooh, sorry about that. Who's going to push this fix? I don't see it
> in Linus' tree yet. If you want me to, please forward me the original
> patch.
I want to double check something. We are still printing something wrong
in the kernel log, so it looks like we have some incorrect carry in some
arithmetic happening somewhere.
Cheers,
Ben.
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc3
From: Mauro Carvalho Chehab @ 2012-06-18 20:35 UTC (permalink / raw)
To: Kim Phillips; +Cc: Linuxppc-dev, Geert Uytterhoeven, linux-kernel, Chris Zankel
In-Reply-To: <20120618152758.3a0a28c7f68615e9e2599ee3@freescale.com>
Em 18-06-2012 17:27, Kim Phillips escreveu:
> On Sun, 17 Jun 2012 21:56:59 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
>> + drivers/edac/mpc85xx_edac.c: error: too few arguments to function
>> 'edac_mc_alloc': => 983:90
>>
>> powerpc-randconfig
>
> fixed in linux-next commit b9bc5dd, should have been upstreamed by
> now [1] - Mauro?
Just sent it a few mins ago. I was waiting for Linus to return back
from his trip.
Regards,
Mauro
>
> Kim
>
> [1] http://marc.info/?l=linux-edac&m=133942731507920&w=2
>
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc3
From: Kim Phillips @ 2012-06-18 20:27 UTC (permalink / raw)
To: Geert Uytterhoeven, Mauro Carvalho Chehab
Cc: Linuxppc-dev, linux-kernel, Chris Zankel
In-Reply-To: <CAMuHMdVfLjgrtWoPpvbLf12+=ApE6W9dNcweqD-_2Benr-D7NQ@mail.gmail.com>
On Sun, 17 Jun 2012 21:56:59 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> + drivers/edac/mpc85xx_edac.c: error: too few arguments to function
> 'edac_mc_alloc': => 983:90
>
> powerpc-randconfig
fixed in linux-next commit b9bc5dd, should have been upstreamed by
now [1] - Mauro?
Kim
[1] http://marc.info/?l=linux-edac&m=133942731507920&w=2
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
From: Scott Wood @ 2012-06-18 19:23 UTC (permalink / raw)
To: Sethi Varun-B16395; +Cc: Wood Scott-B07421, Linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D11E224@039-SN2MPN1-012.039d.mgd.msft.net>
On 06/18/2012 02:19 PM, Sethi Varun-B16395 wrote:
>
>
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Tuesday, June 19, 2012 12:47 AM
>> To: Sethi Varun-B16395
>> Cc: Kumar Gala; Wood Scott-B07421; Linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
>>
>> On 06/18/2012 02:12 PM, Sethi Varun-B16395 wrote:
>>>
>>>
>>>>>> +/*
>>>>>>> + * Error interrupt registers
>>>>>>> + */
>>>>>>> +
>>>>>>> +#define MPIC_ERR_INT_BASE 0x3900
>>>>>>> +#define MPIC_ERR_INT_EISR 0x0000
>>>>>>> +#define MPIC_ERR_INT_EIMR 0x0010
>>>>>>> +
>>>>>>> #define MPIC_MAX_IRQ_SOURCES 2048
>>>>>>> #define MPIC_MAX_CPUS 32
>>>>>>> #define MPIC_MAX_ISU 32
>>>>>>>
>>>>>>> #define MPIC_MAX_TIMER 8
>>>>>>> #define MPIC_MAX_IPI 4
>>>>>>> +#define MPIC_MAX_ERR 32
>>>>>>
>>>>>> Should probably be 64
>>>>>
>>>>> This patch supports MPIC 4.1 and EISR0. When support is added for
>>>>> EISR1 (didn't realize this was coming until your comment prompted me
>>>>> to check...), this should be updated, but this change alone would
>>>>> not make it work.
>>>>
>>>> Would prefer we handle this now rather than later (T4240 is going to
>>>> need
>>>> EISR1 support).
>>> Hi Kumar,
>>> As of now I don't have a proper mechanism to test this functionality.
>>> I will submit a follow up patch for EISR1/EIMR1 support once I have a
>>> mechanism to test this functionality.
>>
>> You could still write the code in a way that scales to multiple EISRs,
>> and test that it works with EISR0.
>>
> Yes, but I would like to submit the patch once I have tested it.
So test it the way I described, and submit. :-P
-Scott
^ 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