* Re: [PATCH] PowerPC/Cell: use vzalloc rather than vmalloc and memset in spu_alloc_lscsa_std
From: Arnd Bergmann @ 2010-10-30 21:41 UTC (permalink / raw)
To: Jesper Juhl; +Cc: cbe-oss-dev, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1010302004290.1572@swampdragon.chaosbits.net>
On Saturday 30 October 2010, Jesper Juhl wrote:
> We can get rid of a memset in
> arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
> using vzalloc() rather than vmalloc()+memset().
>
> Completely untested patch below since I have no hardware nor tools to
> compile this.
>
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* PowerMac G4 RAM
From: kevin diggs @ 2010-10-31 3:48 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have a G4 that has 1.25 G of ram. Under Linux I only get 768M?
Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade.
Kernel is 2.6.28.
Thanks!
kevin
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Fix initramfs size in PPC32 build
From: Geert Uytterhoeven @ 2010-10-31 10:14 UTC (permalink / raw)
To: Kerstin Jonsson, Hendrik Brueckner, Linus Torvalds
Cc: linux-arch, Michal Marek, linux-mmc, Linux Kernel Development,
Paul Mackerras, H. Peter Anvin, WANG Cong, Andrew Morton,
Michael Holzheu, linuxppc-dev
In-Reply-To: <1287742675-7614-1-git-send-email-kerstin.jonsson@ericsson.com>
On Fri, 22 Oct 2010, Kerstin Jonsson wrote:
> commit ffe8018c3424892c9590048fc36caa6c3e0c8a76 of the -mm tree
> fixes the initramfs size calculation for e.g. s390 but breaks it
> for 32bit architectures which do not define CONFIG_32BIT.
>
> This patch fix the problem for PPC32 which will elsewise end up
> with a __initramfs_size of 0.
>
> Signed-off-by: Kerstin Jonsson <kerstin.jonsson@ericsson.com>
> Cc: Paul Mackerras <paulus@samba.org>
> ---
> arch/powerpc/Kconfig | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 50cc5d9..d536fe4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -4,6 +4,10 @@ config PPC32
> bool
> default y if !PPC64
>
> +config 32BIT
> + bool
> + default y if PPC32
> +
> config 64BIT
> bool
> default y if PPC64
> --
> 1.7.1
Thanks for the hint!
In the future, please CC linux-arch, or at least lkml, for things like this,
as it broke allmost all 32-bit arches.
Only mips, s390, and score set CONFIG_32BIT for 32-bit builds.
Would have saved me a bisection on m68k...
I came up with the alternative patch below to fix it in a single place.
---
>From d51254ca020a23050f1641d92d68113e55cc0467 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sun, 31 Oct 2010 10:56:23 +0100
Subject: [PATCH] initramfs: Fix initramfs size for 32-bit arches
commit ffe8018c3424892c9590048fc36caa6c3e0c8a76 ("initramfs: fix initramfs size
calculation") broke 32-bit arches like (on ARAnyM):
VFS: Cannot open root device "hda1" or unknown-block(3,1)
Please append a correct "root=" boot option; here are the available partitions:
fe80 1059408 nfhd8 (driver?)
fe81 921600 nfhd8p1 00000000-0000-0000-0000-000000000nfhd8p1
fe82 137807 nfhd8p2 00000000-0000-0000-0000-000000000nfhd8p2
0200 3280 fd0 (driver?)
0201 3280 fd1 (driver?)
0300 1059408 hda driver: ide-gd
0301 921600 hda1 00000000-0000-0000-0000-000000000hda1
0302 137807 hda2 00000000-0000-0000-0000-000000000hda2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1)
As pointed out by Kerstin Jonsson <kerstin.jonsson@ericsson.com>, this is due
to CONFIG_32BIT not being defined.
Only mips, s390, and score set CONFIG_32BIT for 32-bit builds, so fix it for
all other 32-bit arches by inverting the logic and testing for CONFIG_64BIT,
which should be defined on all 64-bit arches.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
usr/initramfs_data.S | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
index b9efed5..792a750 100644
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -30,8 +30,8 @@ __irf_end:
.section .init.ramfs.info,"a"
.globl __initramfs_size
__initramfs_size:
-#ifdef CONFIG_32BIT
- .long __irf_end - __irf_start
-#else
+#ifdef CONFIG_64BIT
.quad __irf_end - __irf_start
+#else
+ .long __irf_end - __irf_start
#endif
--
1.7.0.4
Gr{oetje,eeting}s,
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. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* Re: PowerMac G4 RAM
From: Benjamin Herrenschmidt @ 2010-10-31 11:28 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=+kF+c=RC09_4V2wqw61xFhFHnvqYHAKbA0TpQ@mail.gmail.com>
On Sat, 2010-10-30 at 22:48 -0500, kevin diggs wrote:
> Hi,
>
> I have a G4 that has 1.25 G of ram. Under Linux I only get 768M?
> Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade.
> Kernel is 2.6.28.
Tried enabling CONFIG_HIGHMEM ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 02/22] bitops: rename generic little-endian bitops functions
From: Hans-Christian Egtvedt @ 2010-10-31 14:02 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-arch, linux-m68k, kvm, Arnd Bergmann, David S. Miller,
Marcelo Tosatti, linux-kernel, rds-devel, Christoph Hellwig,
Andy Grover, netdev, Geert Uytterhoeven, Avi Kivity, Greg Ungerer,
Andreas Schwab, Andrew Morton, linuxppc-dev,
Hans-Christian Egtvedt, Paul Mackerras
In-Reply-To: <1287672077-5797-3-git-send-email-akinobu.mita@gmail.com>
Around Thu 21 Oct 2010 23:40:57 +0900 or thereabout, Akinobu Mita wrote:
> As a preparation for providing little-endian bitops for all architectures,
> This removes generic_ prefix from little-endian bitops function names
> in asm-generic/bitops/le.h.
>
> s/generic_find_next_le_bit/find_next_le_bit/
> s/generic_find_next_zero_le_bit/find_next_zero_le_bit/
> s/generic_find_first_zero_le_bit/find_first_zero_le_bit/
> s/generic___test_and_set_le_bit/__test_and_set_le_bit/
> s/generic___test_and_clear_le_bit/__test_and_clear_le_bit/
> s/generic_test_le_bit/test_le_bit/
> s/generic___set_le_bit/__set_le_bit/
> s/generic___clear_le_bit/__clear_le_bit/
> s/generic_test_and_set_le_bit/test_and_set_le_bit/
> s/generic_test_and_clear_le_bit/test_and_clear_le_bit/
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Roman Zippel <zippel@linux-m68k.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>
> Cc: linux-m68k@lists.linux-m68k.org
> Cc: Greg Ungerer <gerg@uclinux.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Andy Grover <andy.grover@oracle.com>
> Cc: rds-devel@oss.oracle.com
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Cc: Avi Kivity <avi@redhat.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Cc: kvm@vger.kernel.org
> ---
> No change from previous submission
>
> arch/avr32/kernel/avr32_ksyms.c | 4 ++--
> arch/avr32/lib/findbit.S | 4 ++--
For the AVR32 changes.
Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
<snipp patch>
--
Best regards, Hans-Christian Egtvedt
^ permalink raw reply
* eabi supported
From: Oliver Kowalke @ 2010-10-31 18:54 UTC (permalink / raw)
To: linuxppc-dev
Hi,
could you tell me which Linux distribution does support powerpc with
eabi (embedded abi)?
I tried 'T2 Project' but it doesn't offer ABI selection in its config
script.
thx,
Oliver
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Grant Likely @ 2010-11-01 5:17 UTC (permalink / raw)
To: David Daney
Cc: linux-mips, Corey Minyard, Anton Vorontsov, Paul Mackerras,
Sadanand Mutyala, Sergey Matyukevich, Sean MacLennan,
Wolfgang Denk, microblaze-uclinux, devicetree-discuss,
Andres Salomon, Michal Simek, Anatolij Gustschin, Eric Dumazet,
Jiri Pirko, netdev, linux-kernel, ralf, Sandeep Gopalpet,
Vitaly Bordug, linuxppc-dev, David S. Miller
In-Reply-To: <1288130833-16421-1-git-send-email-ddaney@caviumnetworks.com>
On Tue, Oct 26, 2010 at 03:07:13PM -0700, David Daney wrote:
> There are two identical implementations of of_get_mac_address(), one
> each in arch/powerpc/kernel/prom_parse.c and
> arch/microblaze/kernel/prom_parse.c. Move this function to a new
> common file of_net.{c,h} and adjust all the callers to include the new
> header.
Applied, thanks; but made some changes to protect this code because it
does not work on little endian (it can be fixed in a separate patch)
Also...
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Corey Minyard <cminyard@mvista.com>
> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: John Rigby <jcrigby@gmail.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Anton Vorontsov <avorontsov@mvista.com>
> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: Li Yang <leoli@freescale.com>
> Cc: Sergey Matyukevich <geomatsi@gmail.com>
> Cc: Jiri Pirko <jpirko@redhat.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Sean MacLennan <smaclennan@pikatech.com>
> Cc: Sadanand Mutyala <Sadanand.Mutyala@xilinx.com>
> Cc: Andres Salomon <dilinger@queued.net>
> Cc: microblaze-uclinux@itee.uq.edu.au
> Cc: linux-kernel@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: netdev@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
You don't need to believe everything that get_maintainers is telling
you. When you get a large list like this, don't Cc everyone, but
apply some educated guesses. You can guess that the PowerPC and
Microblaze maintainers care because it touches their trees, and you
can guess that I care because I'm the dt maintainer. David Miller
isn't a bad guess because of networking. But 22 people is excessive.
g.
^ permalink raw reply
* Re:
From: Michal Simek @ 2010-11-01 6:29 UTC (permalink / raw)
To: microblaze-uclinux; +Cc: nacc, linuxppc-dev, miltonm
In-Reply-To: <1287422825-14999-2-git-send-email-nacc@us.ibm.com>
Hi,
Nishanth Aravamudan wrote:
> Use set_dma_ops and remove now used-once oddly named temp pointer sd.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> Cc: benh@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/microblaze/pci/pci-common.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
Is there any reason why you are sending me this patch again and again?
Please STOP doing this!
This patch was added to the mainline last week.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Michael Ellerman @ 2010-11-01 11:02 UTC (permalink / raw)
To: Joe Perches; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <c6c46b5924e1cc9720d3ad76e6c11e982bd661e5.1288471898.git.joe@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
On Sat, 2010-10-30 at 14:08 -0700, Joe Perches wrote:
> Coalesce long formats.
> Align arguments.
> Add missing newlines.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> index 5ecd040..d7343a7 100644
> --- a/arch/powerpc/kernel/hw_breakpoint.c
> +++ b/arch/powerpc/kernel/hw_breakpoint.c
> @@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
> * message to let the user know about it.
> */
> if (!stepped) {
> - WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
> - "0x%lx will be disabled.", info->address);
> + WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
> + info->address);
That appears to have done nothing other than turn a short line into one
that is now > 80 columns. Is that the latest fad?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] iSeries: Don't leak if allocations fail in mf_getSrcHistory
From: Michael Ellerman @ 2010-11-01 11:10 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel, Stephen Rothwell
In-Reply-To: <alpine.LNX.2.00.1010301911220.1572@swampdragon.chaosbits.net>
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Sat, 2010-10-30 at 19:20 +0200, Jesper Juhl wrote:
> Hi,
>
> If memory is tight and a dynamic allocation fails there's no reason to
> make a bad situation worse by leaking memory.
>
> mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
> to do is to free that memory again before returning -ENOMEM - which is
> what this patch does.
>
> I realize that the function is under '#if 0' so this probably doesn't
> matter much, but I assume that the function is still there for a reason
> (but I could be wrong, I don't know the powerpc code).
> Anyway, I suggest we remove the leak.
Stephen is the iSeries maintainer, and I think he #if 0'ed the code. But
I don't think it will ever be un-ifdef'ed, so should probably just be
removed.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Timur Tabi @ 2010-11-01 12:04 UTC (permalink / raw)
To: Grant Likely
Cc: linux-mips, netdev, devicetree-discuss, David Daney, linux-kernel,
microblaze-uclinux, linuxppc-dev
In-Reply-To: <20101101051734.GB17587@angua.secretlab.ca>
On Mon, Nov 1, 2010 at 12:17 AM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
>> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
>> Cc: Michal Simek <monstr@monstr.eu>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Wolfram Sang <w.sang@pengutronix.de>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Corey Minyard <cminyard@mvista.com>
>> Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
>> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
>> Cc: Anatolij Gustschin <agust@denx.de>
>> Cc: John Rigby <jcrigby@gmail.com>
>> Cc: Wolfgang Denk <wd@denx.de>
>> Cc: Anton Vorontsov <avorontsov@mvista.com>
>> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> Cc: Li Yang <leoli@freescale.com>
>> Cc: Sergey Matyukevich <geomatsi@gmail.com>
>> Cc: Jiri Pirko <jpirko@redhat.com>
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Sean MacLennan <smaclennan@pikatech.com>
>> Cc: Sadanand Mutyala <Sadanand.Mutyala@xilinx.com>
>> Cc: Andres Salomon <dilinger@queued.net>
>> Cc: microblaze-uclinux@itee.uq.edu.au
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: netdev@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>
> You don't need to believe everything that get_maintainers is telling
> you. =A0When you get a large list like this, don't Cc everyone, but
> apply some educated guesses. =A0You can guess that the PowerPC and
> Microblaze maintainers care because it touches their trees, and you
> can guess that I care because I'm the dt maintainer. David Miller
> isn't a bad guess because of networking. =A0But 22 people is excessive.
And ironically, he left out the person who wrote the function -- me.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: eabi supported
From: Josh Boyer @ 2010-11-01 13:17 UTC (permalink / raw)
To: Oliver Kowalke; +Cc: linuxppc-dev
In-Reply-To: <4CCDBB78.7000600@gmx.de>
On Sun, Oct 31, 2010 at 07:54:48PM +0100, Oliver Kowalke wrote:
>Hi,
>
>could you tell me which Linux distribution does support powerpc with
>eabi (embedded abi)?
>
>I tried 'T2 Project' but it doesn't offer ABI selection in its config
>script.
eabi isn't really used all that much on powerpc. I don't know of a
community distro that supports powerpc in general, much less with eabi.
You might be able to get it from one of the embedded linux vendors, but
you'd have to contact them.
josh
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 13:22 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6631e123845856ac20423c25e07844c8@mail.gmail.com>
On Fri, Oct 29, 2010 at 11:06 PM, Rupjyoti Sarmah <rsarmah@apm.com> wrote:
> Hi ,
>
> APM boards Canyonlands/Kilauea/Glacier/Katmai/Sequoia are all failing
> during booting.
What kernel version? What config? Have you tried a git bisect to see
when it broke? Etc, etc.
Also, CC'ing linuxppc-dev would have been a good idea. Not many on
lkml are even going to know what you're talking about with such sparse
details.
josh
>
> Call trace is same for all
>
>
> Call Trace:
>
> [df835d70] [c02d27cc] emac_probe+0xf28/0x12a8 (unreliable)
>
> [df835e50] [c023c7cc] platform_driver_probe_shim+0x40/0x54
>
> [df835e60] [c01bf354] platform_drv_probe+0x20/0x30
>
> [df835e70] [c01bde68] driver_probe_device+0x148/0x1ac
>
> [df835e90] [c01be17c] __driver_attach+0xa4/0xa8
>
> [df835eb0] [c01bcfa4] bus_for_each_dev+0x60/0x9c
>
> [df835ee0] [c01bdbbc] driver_attach+0x24/0x34
>
> [df835ef0] [c01bd94c] bus_add_driver+0x1b8/0x274
>
> [df835f20] [c01be3d8] driver_register+0x6c/0x160
>
> [df835f40] [c01bf6c4] platform_driver_register+0x68/0x78
>
> [df835f50] [c023c998] of_register_platform_driver+0xa8/0xc4
>
> [df835f60] [c0393e88] emac_init+0x1ac/0x1dc
>
> [df835fa0] [c0001574] do_one_initcall+0x160/0x1a8
>
> [df835fd0] [c037a1e8] kernel_init+0xcc/0x174
>
> [df835ff0] [c000c5b0] kernel_thread+0x4c/0x68
>
> Instruction dump:
>
> 419e016c 2f800007 419e0164 38130774 901a00d0 381306b0 901a00d4 7f43d378
>
> 4bf91d89 817a01a0 39200001 380b0008 <7d400028> 7d4a4b78 7d40012d 40a2fff4
>
> ---[ end trace dac0cf4779f83901 ]---
>
>
> Regards,
> Rup
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH 04/39] arch/powerpc: Update WARN uses
From: Joe Perches @ 2010-11-01 14:41 UTC (permalink / raw)
To: michael; +Cc: Paul Mackerras, Jiri Kosina, linuxppc-dev, linux-kernel
In-Reply-To: <1288609334.10671.4.camel@concordia>
On Mon, 2010-11-01 at 22:02 +1100, Michael Ellerman wrote:
> On Sat, 2010-10-30 at 14:08 -0700, Joe Perches wrote:
> > Coalesce long formats.
> > Align arguments.
> > Add missing newlines.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> > arch/powerpc/kernel/hw_breakpoint.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c
> > index 5ecd040..d7343a7 100644
> > --- a/arch/powerpc/kernel/hw_breakpoint.c
> > +++ b/arch/powerpc/kernel/hw_breakpoint.c
> > @@ -270,8 +270,8 @@ int __kprobes hw_breakpoint_handler(struct die_args *args)
> > * message to let the user know about it.
> > */
> > if (!stepped) {
> > - WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
> > - "0x%lx will be disabled.", info->address);
> > + WARN(1, "Unable to handle hardware breakpoint. Breakpoint at 0x%lx will be disabled.\n",
> > + info->address);
>
> That appears to have done nothing other than turn a short line into one
> that is now > 80 columns.
Added '\n'.
The series was done for a few reasons:
o to add missing newlines at the end of messages as was done here
o to convert a couple of misuses of WARN(msg) to WARN(1, msg)
o to remove KERN_ prefixes from WARN(test, KERN_<level> msg)
> Is that the latest fad?
Pretty much. Format coalescing is generally preferred for grep.
Some consider it churn.
cheers, Joe
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 15:05 UTC (permalink / raw)
To: Rupjyoti Sarmah, Tom Herbert, Eric Dumazet, David S. Miller
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <AANLkTikWWGpAM8+_z9fnngYuYSpT3NWgM7xeGkOzZ3jg@mail.gmail.com>
On Mon, Nov 1, 2010 at 9:22 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Fri, Oct 29, 2010 at 11:06 PM, Rupjyoti Sarmah <rsarmah@apm.com> wrote=
:
>> Hi ,
>>
>> APM boards Canyonlands/Kilauea/Glacier/Katmai/Sequoia are all failing
>> during booting.
>
> What kernel version? =A0What config? =A0Have you tried a git bisect to se=
e
> when it broke? =A0Etc, etc.
>>
>> Call trace is same for all
>>
>>
>> Call Trace:
>>
>> [df835d70] [c02d27cc] emac_probe+0xf28/0x12a8 (unreliable)
>>
>> [df835e50] [c023c7cc] platform_driver_probe_shim+0x40/0x54
>>
>> [df835e60] [c01bf354] platform_drv_probe+0x20/0x30
>>
>> [df835e70] [c01bde68] driver_probe_device+0x148/0x1ac
>>
>> [df835e90] [c01be17c] __driver_attach+0xa4/0xa8
>>
>> [df835eb0] [c01bcfa4] bus_for_each_dev+0x60/0x9c
>>
>> [df835ee0] [c01bdbbc] driver_attach+0x24/0x34
>>
>> [df835ef0] [c01bd94c] bus_add_driver+0x1b8/0x274
>>
>> [df835f20] [c01be3d8] driver_register+0x6c/0x160
>>
>> [df835f40] [c01bf6c4] platform_driver_register+0x68/0x78
>>
>> [df835f50] [c023c998] of_register_platform_driver+0xa8/0xc4
>>
>> [df835f60] [c0393e88] emac_init+0x1ac/0x1dc
>>
>> [df835fa0] [c0001574] do_one_initcall+0x160/0x1a8
>>
>> [df835fd0] [c037a1e8] kernel_init+0xcc/0x174
>>
>> [df835ff0] [c000c5b0] kernel_thread+0x4c/0x68
>>
>> Instruction dump:
>>
>> 419e016c 2f800007 419e0164 38130774 901a00d0 381306b0 901a00d4 7f43d378
>>
>> 4bf91d89 817a01a0 39200001 380b0008 <7d400028> 7d4a4b78 7d40012d 40a2fff=
4
>>
>> ---[ end trace dac0cf4779f83901 ]---
A git bisect between 2.6.36 (working) and Linus tip (traceback) points to:
e6484930d7c73d324bccda7d43d131088da697b9 net: allocate tx queues in
register_netdevice
as causing this. I'm not entirely sure why yet, but the commit
message seems slightly off to me. It claims to make TX queue
allocation identical to RX, but from what I can tell, most of the RX
queue logic is hidden behind CONFIG_RPS, which is not set in my config
at all (and can't be due to a dep on CONFIG_SMP). This change doesn't
guard anything behind that.
A few hints would be appreciated.
josh
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Stephen Rothwell @ 2010-11-01 15:36 UTC (permalink / raw)
To: Josh Boyer
Cc: Eric Dumazet, Rupjyoti Sarmah, linux-kernel, linuxppc-dev,
David S. Miller, Tom Herbert
In-Reply-To: <AANLkTikQuUcAMZKqZ3Rz5HVzOs+63-Y4VYUo5-3EM30H@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
Hi Josh,
On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>
> A few hints would be appreciated.
Remove the call to netif_stop_queue() from emac_probe(). Apparently,
calling this before register_netdev() is now wrong (maybe always was).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 15:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Eric Dumazet, Rupjyoti Sarmah, linux-kernel, linuxppc-dev,
David S. Miller, Tom Herbert
In-Reply-To: <20101102023650.bc553e74.sfr@canb.auug.org.au>
On Mon, Nov 1, 2010 at 11:36 AM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Josh,
>
> On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>>
>> A few hints would be appreciated.
>
> Remove the call to netif_stop_queue() from emac_probe(). =A0Apparently,
> calling this before register_netdev() is now wrong (maybe always was).
Yeah, I just discovered that myself. I'm wondering
1) why we do that in that function?
2) If it needs to be removed entirely, or moved to after the
register_netdev call
3) If the call to netif_carrier_off also needs similar attention.
I can whip up a patch to remove those calls or move them after the
register, but I don't want to do that without knowing which one is
"right".
josh
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Timur Tabi @ 2010-11-01 15:46 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <20101101051734.GB17587@angua.secretlab.ca>
On Mon, Nov 1, 2010 at 12:17 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Applied, thanks; but made some changes to protect this code because it
> does not work on little endian (it can be fixed in a separate patch)
I'm confused. How does of_get_mac_address() not work on little-endian?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: David Miller @ 2010-11-01 15:50 UTC (permalink / raw)
To: sfr; +Cc: eric.dumazet, rsarmah, linux-kernel, linuxppc-dev, therbert
In-Reply-To: <20101102023650.bc553e74.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 2 Nov 2010 02:36:50 +1100
> Hi Josh,
>
> On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
>>
>> A few hints would be appreciated.
>
> Remove the call to netif_stop_queue() from emac_probe(). Apparently,
> calling this before register_netdev() is now wrong (maybe always was).
Right.
I'll add this to net-2.6
--------------------
ibm_newemac: Remove netif_stop_queue() in emac_probe().
Touching the queue state before register_netdev is not
allowed, and besides the queue state before ->open()
is "don't care"
Reported-by: Josh Boyer <jwboyer@gmail.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ibm_newemac/core.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 385dc32..06bb9b7 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2871,7 +2871,6 @@ static int __devinit emac_probe(struct platform_device *ofdev,
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
netif_carrier_off(ndev);
- netif_stop_queue(ndev);
err = register_netdev(ndev);
if (err) {
--
1.7.3.2
^ permalink raw reply related
* RE: Support for multiple port's
From: Bounine, Alexandre @ 2010-11-01 15:49 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTin7OeSgUgqUEnYxUnZQ0vgckg7e43gudms8NqeG@mail.gmail.com>
Thomas Taranowski wrote:
> Going through the code, it looks like the rapidio driver assumes
> there's only going to be a single Port implemented.
Yes, this is true for the current implementation.
> On the newer QorIQ P2020 processors there are 2 sets of port
> registers, so the current code lays the dbell_atmu_regs structure on
> top of the second set of atmu_regs. There are probably other issues
> as well.
There are issues with multiport support in RIO subsystem code as well .
>=20
> Are there any patch sets available that support the newer processors,
> and multi-port ( multi-homed? ) RapidIO configurations?
I am planning a patch for RIO subsystem - this will not address issues
with FSL mport driver.
>=20
> Thanks!
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: David Miller @ 2010-11-01 15:51 UTC (permalink / raw)
To: jwboyer; +Cc: sfr, eric.dumazet, rsarmah, linux-kernel, linuxppc-dev, therbert
In-Reply-To: <AANLkTin3nsb6FfNtXfqjZCuV66mwKVOsKgmZpTABFDUJ@mail.gmail.com>
From: Josh Boyer <jwboyer@gmail.com>
Date: Mon, 1 Nov 2010 11:39:47 -0400
> On Mon, Nov 1, 2010 at 11:36 AM, Stephen Rothwell <sfr@canb.auug.org.=
au> wrote:
>> Hi Josh,
>>
>> On Mon, 1 Nov 2010 11:05:53 -0400 Josh Boyer <jwboyer@gmail.com> wro=
te:
>>>
>>> A few hints would be appreciated.
>>
>> Remove the call to netif_stop_queue() from emac_probe(). =A0Apparent=
ly,
>> calling this before register_netdev() is now wrong (maybe always was=
).
> =
> Yeah, I just discovered that myself. I'm wondering
> =
> 1) why we do that in that function?
Because likely it was blindly copied from some other driver.
> 2) If it needs to be removed entirely, or moved to after the
> register_netdev call
Removed entirely.
> 3) If the call to netif_carrier_off also needs similar attention.
Not really.
> I can whip up a patch to remove those calls or move them after the
> register, but I don't want to do that without knowing which one is
> "right".
I've already taken care of this.
^ permalink raw reply
* Re: [PATCH] OF device tree: Move of_get_mac_address() to a common source file.
From: Grant Likely @ 2010-11-01 15:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <AANLkTimp-AFN5T3z9o6X9qM-GQXSU5vinf+Lqu_jUmJj@mail.gmail.com>
On Mon, Nov 1, 2010 at 11:46 AM, Timur Tabi <timur@freescale.com> wrote:
> On Mon, Nov 1, 2010 at 12:17 AM, Grant Likely <grant.likely@secretlab.ca>=
wrote:
>
>> Applied, thanks; but made some changes to protect this code because it
>> does not work on little endian (it can be fixed in a separate patch)
>
> I'm confused. =A0How does of_get_mac_address() not work on little-endian?
Hmmm, right. I got confused here. It should be just fine on
little-endian. I'll revert my change. Thanks.
g.
^ permalink raw reply
* RE: RapidIO: MC Exception when enumerating peer to peer connection
From: Bounine, Alexandre @ 2010-11-01 15:58 UTC (permalink / raw)
To: Thomas Taranowski, Micha Nelissen; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikhcOMexRBVthK8Xr8VTNvDmiUDvWG+QbyzWc38@mail.gmail.com>
Thomas Taranowski wrote:
> Yes, I tried pretty much all combinations of boot order, but I believe
> the preferred approach is to boot the agents first, then the host
> according to my freescale documentation. My problem was that all
> three devices had the same device id. Once I programmed them with
> different device id's via the alternate device id register I could
> finally get doorbell messages across with the jtag.
=20
In the current fsl_rio implementation initialization enables ACCEPT_ALL
mode for the port therefore you should not have problems caused by
initial destID value. Based on your post about multiport support I think
you are close to find a source of the problem.
Are you using any switches in your setup or this is pure board-to-board
configuration?
Alex.
^ permalink raw reply
* PowerQUICC II PCIe dma
From: David Laight @ 2010-11-01 15:58 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to get a ppc 831x to do PCIe dma transfers, PIO transfers
work ok but are somewhat lethargic (partially due to the slave).
I've done the following:
- All reads/writes (including the dma descriptors) are byteswapped.
- Enabled the dma in PEX_CSB_CTRL (value 0x3f)
- Used the kernel physical addresses for all addresses.
For memory from virt_to_phys(), pci from pci_resource_start().
(virt_to_phys() gives invalid values for the pci area).
- I'm setting both 'snoop' bits to 1 (as per the device errata)
So the descriptor 'ctrl' has value (len >> 2) << 12 | 0xff9,
and the dma 'ctrl' 0x401.
- I've put a 'sync' instruction (iosync()) just before the
write to start the dma.
On the first request after hard reset, the dma status register
REX_RDMA_STAT gets set to 4. On subsequent requests it stays zero.
Nothing else appears to happen at all (except the 'start' bit
always reads back zero).
The 'CSB status register' at 0x81c stays zero - so I don't think
it is stuck waiting for the PCIe slave.
I'm not at all sure of the word ordering for the dma descriptor!
Page 14-113 doesn't say! However I've written the values so that
it doesn't matter - once I get a status written back I'll know...
I've probably forgotten something very silly!
Anyone who has got this working any ideas ??
David
^ permalink raw reply
* Re: All Applied micro boards are failing with current mainline kernel
From: Josh Boyer @ 2010-11-01 16:14 UTC (permalink / raw)
To: David Miller
Cc: sfr, eric.dumazet, rsarmah, linux-kernel, linuxppc-dev, therbert
In-Reply-To: <20101101.085126.71102684.davem@davemloft.net>
On Mon, Nov 1, 2010 at 11:51 AM, David Miller <davem@davemloft.net> wrote:
>> I can whip up a patch to remove those calls or move them after the
>> register, but I don't want to do that without knowing which one is
>> "right".
>
> I've already taken care of this.
Thanks!
josh
^ 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