* Re: [PATCH] i2c: let the core register devices from devicetree
From: Barry Song @ 2012-06-21 1:16 UTC (permalink / raw)
To: Wolfram Sang
Cc: Viresh Kumar, Mauro Carvalho Chehab, Tony Lindgren, Linus Walleij,
Haojian Zhuang, Laxman Dewangan, linux-i2c, Kukjin Kim,
Stephen Warren, Olof Johansson, Deepak Sikri, Haavard Skinnemoen,
Pawel Moll, Wolfram Sang, Sascha Hauer, Rusty Russell,
Tang Yuantian, Jean Delvare (PC drivers, core), Magnus Damm,
Lars-Peter Clausen, Ben Dooks (embedded platforms),
linux-arm-kernel, Jiri Kosina, Kyungmin Park, Karol Lewandowski,
Dirk Brandewie, Shawn Guo, linuxppc-dev
In-Reply-To: <1339622215-4733-1-git-send-email-w.sang@pengutronix.de>
MjAxMi82LzE0IFdvbGZyYW0gU2FuZyA8dy5zYW5nQHBlbmd1dHJvbml4LmRlPjoKPiBDdXJyZW50
bHksIGV2ZXJ5IGRyaXZlciBoYXMgdG8gZG8gaXQgb24gaXRzIG93biwgYnV0IGl0IHNob3VsZCBi
ZSBkb25lCj4gaW4gdGhlIGNvcmUsIGxpa2Ugd2UgYWxyZWFkeSBkbyB3aXRoIGJvYXJkX2luZm8g
c3RydWN0cy4KPgo+IFNpZ25lZC1vZmYtYnk6IFdvbGZyYW0gU2FuZyA8dy5zYW5nQHBlbmd1dHJv
bml4LmRlPgoKQWNrZWQtYnk6IEJhcnJ5IFNvbmcgPGJhcnJ5LnNvbmdAbGlhbmxhYi5vcmc+Cgo+
IC0tLQo+Cj4gQmFzZWQgb24gdjMuNS1yYzIuIE9ubHkgYnVpbGQgdGVzdGVkLCBJIGRvbid0IGhh
dmUgYSBPRiBiYXNlZCBkZXZpY2UKPiBhcm91bmQgYXQgdGhlIG1vbWVudC4KPgo+IEBQZXRlcjog
V2h5IGRvZXMgb2NvcmVzIGRvIHRoZSBkZXZpY2UgcmVnaXN0cmF0aW9uIG1hbnVhbGx5IHZpYQo+
IHBsYXRmb3JtX2RhdGEgaW5zdGVhZCBvZiB1c2luZyBib2FyZF9pbmZvPwo+Cj4gwqBkcml2ZXJz
L2kyYy9idXNzZXMvaTJjLWNwbS5jIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoDUgLS0t
LS0KPiDCoGRyaXZlcnMvaTJjL2J1c3Nlcy9pMmMtZGVzaWdud2FyZS1wbGF0ZHJ2LmMgfCDCoCDC
oDEgLQo+IMKgZHJpdmVycy9pMmMvYnVzc2VzL2kyYy1ncGlvLmMgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgfCDCoCDCoDIgLS0KPiDCoGRyaXZlcnMvaTJjL2J1c3Nlcy9pMmMtaWJtX2lpYy5jIMKgIMKg
IMKgIMKgIMKgIMKgfCDCoCDCoDMgLS0tCj4gwqBkcml2ZXJzL2kyYy9idXNzZXMvaTJjLWlteC5j
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoDIgLS0KPiDCoGRyaXZlcnMvaTJjL2J1c3Nl
cy9pMmMtbXBjLmMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgMSAtCj4gwqBkcml2ZXJz
L2kyYy9idXNzZXMvaTJjLW14cy5jIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoDIgLS0K
PiDCoGRyaXZlcnMvaTJjL2J1c3Nlcy9pMmMtb2NvcmVzLmMgwqAgwqAgwqAgwqAgwqAgwqAgfCDC
oCDCoDIgLS0KPiDCoGRyaXZlcnMvaTJjL2J1c3Nlcy9pMmMtb21hcC5jIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIHwgwqAgwqAyIC0tCj4gwqBkcml2ZXJzL2kyYy9idXNzZXMvaTJjLXBueC5jIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoDIgLS0KPiDCoGRyaXZlcnMvaTJjL2J1c3Nlcy9pMmMt
cHhhLmMgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgMSAtCj4gwqBkcml2ZXJzL2kyYy9i
dXNzZXMvaTJjLXMzYzI0MTAuYyDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAxIC0KPiDCoGRyaXZl
cnMvaTJjL2J1c3Nlcy9pMmMtc2hfbW9iaWxlLmMgwqAgwqAgwqAgwqAgwqB8IMKgIMKgMSAtCj4g
wqBkcml2ZXJzL2kyYy9idXNzZXMvaTJjLXRlZ3JhLmMgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKg
IMKgMiAtLQo+IMKgZHJpdmVycy9pMmMvYnVzc2VzL2kyYy12ZXJzYXRpbGUuYyDCoCDCoCDCoCDC
oCDCoHwgwqAgwqAxIC0KPiDCoGRyaXZlcnMvaTJjL2J1c3Nlcy9pMmMteGlpYy5jIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIHwgwqAgwqAyIC0tCj4gwqBkcml2ZXJzL2kyYy9pMmMtY29yZS5jIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoDMgKysrCj4gwqAxNyBmaWxlcyBjaGFu
Z2VkLCAzIGluc2VydGlvbnMoKyksIDMwIGRlbGV0aW9ucygtKQoKLWJhcnJ5Cg==
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Bjorn Helgaas @ 2012-06-21 0:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Ben Collins
In-Reply-To: <1340051997.2372.27.camel@pasglop>
On Mon, Jun 18, 2012 at 2:39 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2012-06-18 at 09:23 -0600, Bjorn Helgaas wrote:
>> Ooh, sorry about that. =A0Who's going to push this fix? =A0I don't see i=
t
>> in Linus' tree yet. =A0If 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.
Probably not related to whatever you're seeing, but just FYI, I think
the core has a sign-extension bug related to P2P bridge I/O windows:
http://marc.info/?l=3Dlinux-pci&m=3D134023801524895&w=3D2
^ permalink raw reply
* Re: [PATCH] MIPS: fix bug.h MIPS build regression
From: Ralf Baechle @ 2012-06-20 16:12 UTC (permalink / raw)
To: Yoichi Yuasa
Cc: Linux MIPS Mailing List, Linux-sh list, linux-kernel,
Linuxppc-dev, Paul Mundt, Geert Uytterhoeven, Chris Zankel
In-Reply-To: <20120620152759.2caceb8c.yuasa@linux-mips.org>
On Wed, Jun 20, 2012 at 03:27:59PM +0900, Yoichi Yuasa wrote:
> Commit: 3777808873b0c49c5cf27e44c948dfb02675d578 breaks all MIPS builds.
Thanks, fix applied.
Ralf
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc3
From: Giuseppe CAVALLARO @ 2012-06-20 12:50 UTC (permalink / raw)
To: Paul Mundt
Cc: Chris Zankel, Linux-sh list, Linux MIPS Mailing List,
linux-kernel, Linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <20120620035951.GC5623@linux-sh.org>
Hello Paul
On 6/20/2012 5:59 AM, Paul Mundt wrote:
> 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?
Trying to reproduce the problem, I've also re-built the mainstream
kernel 3.5-rc3 for se7724_defconfig platform plus the stmmac (pltf and
pci) but all compiles fine.
I've also verified that there is the 33d5e332b9c5 commit that is the
latest one discussed/tested/committed in the network mailing list.
Can you tell me how to reproduce the problem? How can I help?
Pls let me know,
Peppe
^ permalink raw reply
* Re: [PATCH] MIPS: fix bug.h MIPS build regression
From: Sergei Shtylyov @ 2012-06-20 10:40 UTC (permalink / raw)
To: Yoichi Yuasa
Cc: Linux MIPS Mailing List, Linux-sh list, linux-kernel,
Ralf Baechle, Linuxppc-dev, Paul Mundt, Geert Uytterhoeven,
Chris Zankel
In-Reply-To: <20120620152759.2caceb8c.yuasa@linux-mips.org>
Hello.
On 20-06-2012 10:27, Yoichi Yuasa wrote:
> Commit: 3777808873b0c49c5cf27e44c948dfb02675d578
Please also specify the summary of that commit in parens.
> breaks all MIPS builds.
[...]
> Signed-off-by: Yoichi Yuasa<yuasa@linux-mips.org>
WBR, Sergei
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (powerpc related)
From: Benjamin Herrenschmidt @ 2012-06-20 10:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, ppc-dev, linux-kernel
In-Reply-To: <20120620175014.a822a766e0f91f7b44f48fa0@canb.auug.org.au>
On Wed, 2012-06-20 at 17:50 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
I hate our ABI is a good answer ? :-)
I'll see what I can do tomorrow. Poke me when I'm in the office.
Cheers,
Ben.
> 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
>
^ permalink raw reply
* Re: Build regressions/improvements in v3.5-rc3
From: Geert Uytterhoeven @ 2012-06-20 8:02 UTC (permalink / raw)
To: Paul Mundt
Cc: Chris Zankel, Linux-sh list, linux-kernel, Linuxppc-dev,
Linux MIPS Mailing List, Giuseppe Cavallaro
In-Reply-To: <20120620035951.GC5623@linux-sh.org>
On Wed, Jun 20, 2012 at 5:59 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> 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.
>
>> =C2=A0 + drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implic=
it
>> declaration of function 'pci_iomap'
>> [-Werror=3Dimplicit-function-declaration]: =C2=A0=3D> 90:3
>> =C2=A0 + drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implic=
it
>> declaration of function 'pci_iounmap'
>> [-Werror=3Dimplicit-function-declaration]: =C2=A0=3D> 142:2
>>
> Not sure about this one, it should find everything alright via:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0linux/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?
These were xtensa, not sh.
The ones above ("error: expected expression before 'do'") were sh.
>> =C2=A0 + error: "__ashrdi3" [fs/ntfs/ntfs.ko] undefined!: =C2=A0=3D> N/A
>> =C2=A0 + error: "__lshrdi3" [fs/ntfs/ntfs.ko] undefined!: =C2=A0=3D> N/A
>>
>> sh4/landisk_defconfig
>>
>> =C2=A0 + error: "__ashrdi3" [fs/xfs/xfs.ko] undefined!: =C2=A0=3D> N/A
>> =C2=A0 + error: "__lshrdi3" [drivers/mtd/mtd.ko] undefined!: =C2=A0=3D> =
N/A
>> =C2=A0 + error: "__lshrdi3" [fs/xfs/xfs.ko] undefined!: =C2=A0=3D> 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?
http://kisskb.ellerman.id.au/kisskb/buildresult/6543287/ says
sh4-linux-gcc (GCC) 4.6.3
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* 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
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