* Re: [PATCH] fbdev: work around old compiler bug
From: Sam Ravnborg @ 2009-06-22 9:41 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Simmons, Linus, LKML, Krzysztof Helt, Geert Uytterhoeven,
Andrew Morton, ppc-dev
In-Reply-To: <20090622183415.46fa786b.sfr@canb.auug.org.au>
On Mon, Jun 22, 2009 at 06:34:15PM +1000, Stephen Rothwell wrote:
> On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > When building with a 4.1.x compiler on powerpc64 (at least) we get
> > this error:
>
> Ignore this, it causes more problems:
>
> drivers/video/logo/logo_linux_clut224.c:548: error: logo_linux_clut224_clut causes a section type conflict
>
> I'll work on a better solution.
I have no time to experiemnt atm.
But I have seen this before.
It happens when we mix up const and non-const stuff.
I would assume the simple solution is to replace _initconst with _initdata
for all users.
If you get it to work with powerpc then it works for everyone (or so it is usually).
Sam
^ permalink raw reply
* Re: kilauea/405ex external interrupts
From: Stefan Roese @ 2009-06-22 9:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <e35801cc0906190100i1a0429eahade975319b5246df@mail.gmail.com>
On Friday 19 June 2009 10:00:52 Lada Podivin wrote:
> I'm writing a linux driver that uses an external interrupt (ppc 405ex). I'm
> using GPIO pin 30 (external IRQ 1) connected to UIC1. I'm aware of the
> virtual interrupt stuff, so I added a new node to my device tree in order
> to get proper virtual IRQ number. This node describes an external event and
> its connection to UIC via the mentioned ext. int. Here is a sample of the
> divce-tree:
<snip>
> EXTEVENT: external_event {
> device_type = "external";
> #address-cells = <0>;
> #size-cells = <0>;
> #interrupt-cells = <2>;
> interrupts = <0x1e 0x1>;
> interrupt-parent = <&UIC1>;
> };
> ...
>
> Then I use function "irq_of_parse_and_map()" which returns the virtual IRQ
> number 22. So, "request_irq()" seems to be satisfied with this number. I
> can see this interrupt in the /proc/interrupts. But! When I connect a
> signal source to the pin 30, nothing happens - the interrupt service
> routine isn't called.
>
> Am I suppose to configure anything else? (e. g. pin multiplexing, further
> device-tree tuning...) Thank you!
Yes, this could very well be a problem of pin multiplexing. From looking at
the Kilauea GPIO/Pin mux configuration in U-Boot, GPIO30 is configured as GPIO
input and not as IRQ1. So this can't work. The easiest way to change this is
in U-Boot (include/configs/kilauea.h).
BTW: Are you using Kilauea or a custom 405EX board?
Best regards,
Stefan
^ permalink raw reply
* Re: ALSA fixes for non-coherent ppc32 again
From: Gerhard Pircher @ 2009-06-22 9:23 UTC (permalink / raw)
To: Takashi Iwai, benh; +Cc: linuxppc-dev
In-Reply-To: <s5h8wjkoi70.wl%tiwai@suse.de>
-------- Original-Nachricht --------
> Datum: Mon, 22 Jun 2009 09:12:35 +0200
> Von: Takashi Iwai <tiwai@suse.de>
> An: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Gerhard Pircher <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: ALSA fixes for non-coherent ppc32 again
> At Mon, 22 Jun 2009 08:34:38 +1000,
> Benjamin Herrenschmidt wrote:
> >
> > On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
> > > Hi,
> > >
> > > Takashi Iwai posted patches to make ALSA work on non-coherent PPC32
> > > systems (almost exactly) a year ago. See here:
> > >
> > > http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
> > >
> > > As far as I can see these patches never went upstream. Where there
> > > any objections or did we just forget about them? It would be cool,
> > > if the patches could be merged now, as at least two platforms need
> > > this bugfix (namely Sam440 and AmigaOne).
> >
> > I definitely forgot about those...
>
> Me, too, almost... :)
:)
> > But I'm fine with what Takashi did
> > for now, I can always make the powerpc helper for dma_mmap_coherent()
> > smarter later on if necessary.
>
> I updated the patch series for 2.6.31, including sparc32, parisc, mips
> and sh support. The patches are found in test/dma-fix branch of sound
> git tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> test/dma-fix
Thanks!
> The old patches for 2.6.30 is found at history/dma-fix-2.6.30 branch
> there, too.
>
>
> For merging to the upstream, we'll need definitely discussions on
> linux-arch ML or so, as once James Bottomley suggested. I'll try to
> make it up once after the merge window.
>
> But, it'd be helpful if someone can test the patches above beforehand,
> of course :)
Sure, I'll give it a try until tomorrow.
Gerhard
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Laszlo Fekete @ 2009-06-22 9:10 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <4A38B883.80507@ktk.bme.hu>
Hello!
Is there any idea for the solution?
Thanks: blackluck
Laszlo Fekete wrote:
> Hello!
>
> I'm sorry about the annoyances, but I'd welcome all ideas, suggestions
> to see what needs to be done or should be tested for the solution.
>
> Thank you very much!
>
> Guennadi Liakhovetski wrote:
>> Ok, first attempt to forward this to scsi was wrong, as pointed out
>> by Matthew Wilcox this does indeed look like an interrupt problem -
>> no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I
>> guess. In any case, I think, the OP would be grateful for any hints.
>>
>> Thanks
>> Guennadi
>> ---
>> Guennadi Liakhovetski, Ph.D.
>> Freelance Open-Source Software Developer
>> http://www.open-technology.de/
>>
>> ---------- Forwarded message ----------
>> Date: Sat, 13 Jun 2009 16:22:07 +0200
>> From: Laszlo Fekete <blackluck@ktk.bme.hu>
>> To: debian-powerpc@lists.debian.org
>> Subject: sym scsi driver problem with 2.6.26 or newer debian kernel
>> on p610
>> Resent-Date: Sat, 13 Jun 2009 14:29:55 +0000 (UTC)
>> Resent-From: debian-powerpc@lists.debian.org
>>
>> This is a multi-part message in MIME format.
>> ------------------------------------------------------------------------
>>
>> Hello!
>>
>>
>>
>>
>>
>> Pls help me with sym scsi driver problem.
>>
>>
>>
>> I have Ibm P610 (and tested it on P630 and P640 too), installed debian
>>
>> etch and upgraded to lenny.
>>
>>
>>
>> But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi
>>
>> bus scan.
>>
>>
>>
>>
>>
>> Whats the problem with it, or how can I fix this?
>>
>>
>>
>>
>>
>> I attach the output from minicom with 2.6.29, 2.6.26, and the working
>>
>> 2.6.24 kernel booting.
>>
>>
>>
>>
>>
>> Thank you very much!
>>
>>
>>
>
>
^ permalink raw reply
* Re: Badness at drivers/char/tty_ldisc.c:210 during shutdown
From: Alan Cox @ 2009-06-22 8:52 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1245655421.4400.78.camel@concordia>
> > [c00000003cf6ba70] [c00000000040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable)
> > [c00000003cf6bb10] [c00000000040a7c8] .tty_ldisc_reinit+0x38/0x80
> > [c00000003cf6bba0] [c00000000040b1d8] .tty_ldisc_hangup+0x190/0x260
> > [c00000003cf6bc40] [c000000000401090] .do_tty_hangup+0x188/0x4c0
> > [c00000003cf6bd20] [c000000000401440] .tty_vhangup_self+0x34/0x54
> > [c00000003cf6bdb0] [c00000000019236c] .sys_vhangup+0x38/0x58
> > [c00000003cf6be30] [c000000000008534] syscall_exit+0x0/0x40
> > Instruction dump:
> > 912b0088 4bcd17bd 60000000 e87e8008 7f44d378 481c04fd 60000000 801b0008
> > 7c09fe70 7d200278 7c004850 54000ffe <0b000000> 7f63db78 4bd7c98d 60000000
>
> Ah right, so this has check has just gone in, and the code in question
> has been rewritten somewhat just recently.
The check is to catch any cases where a line discipline is being freed up
but has a refcount that is non zero. I think I know what is going on here.
Alan
^ permalink raw reply
* Re: [PATCH] fbdev: work around old compiler bug
From: Stephen Rothwell @ 2009-06-22 8:34 UTC (permalink / raw)
To: Linus
Cc: James Simmons, Sam Ravnborg, LKML, Krzysztof Helt,
Geert Uytterhoeven, Andrew Morton, ppc-dev
In-Reply-To: <20090622180420.2e0424e4.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> When building with a 4.1.x compiler on powerpc64 (at least) we get
> this error:
Ignore this, it causes more problems:
drivers/video/logo/logo_linux_clut224.c:548: error: logo_linux_clut224_clut causes a section type conflict
I'll work on a better solution.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] fbdev: work around old compiler bug
From: Stephen Rothwell @ 2009-06-22 8:04 UTC (permalink / raw)
To: Linus
Cc: James Simmons, Sam Ravnborg, LKML, Krzysztof Helt,
Geert Uytterhoeven, Andrew Morton, ppc-dev
When building with a 4.1.x compiler on powerpc64 (at least) we get
this error:
drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a section type conflict
This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
("fbdev: move logo externs to header file"). This is a partial revert
of that commit sufficient to not hit the compiler bug.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
scripts/pnmtologo.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 64f5ddb..d10c389 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -237,7 +237,7 @@ static void write_header(void)
fprintf(out, " * Linux logo %s\n", logoname);
fputs(" */\n\n", out);
fputs("#include <linux/linux_logo.h>\n\n", out);
- fprintf(out, "static const unsigned char %s_data[] __initconst = {\n",
+ fprintf(out, "static unsigned char %s_data[] __initdata = {\n",
logoname);
}
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: Badness at drivers/char/tty_ldisc.c:210 during shutdown
From: Michael Ellerman @ 2009-06-22 7:23 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev, linux-kernel, alan
In-Reply-To: <4A3F281F.9000408@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]
On Mon, 2009-06-22 at 12:13 +0530, Sachin Sant wrote:
> Sachin Sant wrote:
> > I came across the following badness message during shutdown on a
> > Power6 box.
> > This was with 2.6.30-git12(3fe0344faf7fdcb158bd5c1a9aec960a8d70c8e8)
> >
> > ------------[ cut here ]------------
> > Badness at drivers/char/tty_ldisc.c:210
> The badness message is still present with git18.
>
> ------------[ cut here ]------------
> Badness at drivers/char/tty_ldisc.c:210
> NIP: c00000000040a3e8 LR: c00000000040a3d0 CTR: 0000000000000000
> REGS: c00000003cf6b7f0 TRAP: 0700 Not tainted (2.6.30-git18)
> MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24000424 XER: 00000001
> TASK = c00000003e308660[3846] 'vhangup' THREAD: c00000003cf68000 CPU: 1
> <6>GPR00: 0000000000000001 c00000003cf6ba70 c000000000ef48c0 0000000000000001
> <6>GPR04: 0000000000000001 c00000003819f000 c000000000407b60 0000000000000000
> <6>GPR08: 0000000000000000 0000000000000000 0000000000000001 c000000000e1bce8
> <6>GPR12: 0000000044000428 c000000001002600 00000000ffffffff ffffffffffffffff
> <6>GPR16: 0000000021fd8a50 0000000000000002 0000000000000000 0000000021fc03b0
> <6>GPR20: 0000000000000000 0000000000000000 c00000003d04c700 0000000000000001
> <6>GPR24: 0000000000000000 0000000000000000 0000000000000001 c000000040007e20
> <6>GPR28: 0000000000000000 c0000000013ffd38 c000000000e7e860 c00000003cf6ba70
> NIP [c00000000040a3e8] .tty_ldisc_put+0xbc/0xf4
> LR [c00000000040a3d0] .tty_ldisc_put+0xa4/0xf4
> Call Trace:
> [c00000003cf6ba70] [c00000000040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable)
> [c00000003cf6bb10] [c00000000040a7c8] .tty_ldisc_reinit+0x38/0x80
> [c00000003cf6bba0] [c00000000040b1d8] .tty_ldisc_hangup+0x190/0x260
> [c00000003cf6bc40] [c000000000401090] .do_tty_hangup+0x188/0x4c0
> [c00000003cf6bd20] [c000000000401440] .tty_vhangup_self+0x34/0x54
> [c00000003cf6bdb0] [c00000000019236c] .sys_vhangup+0x38/0x58
> [c00000003cf6be30] [c000000000008534] syscall_exit+0x0/0x40
> Instruction dump:
> 912b0088 4bcd17bd 60000000 e87e8008 7f44d378 481c04fd 60000000 801b0008
> 7c09fe70 7d200278 7c004850 54000ffe <0b000000> 7f63db78 4bd7c98d 60000000
Ah right, so this has check has just gone in, and the code in question
has been rewritten somewhat just recently.
commit 677ca3060c474d7d89941948e32493d9c18c52d2
Author: Alan Cox <alan@linux.intel.com>
Date: Tue Jun 16 17:00:53 2009 +0100
ldisc: debug aids
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/drivers/char/tty_ldisc.c b/drivers/char/tty_ldisc.c
index 874c248..a19e935 100644
--- a/drivers/char/tty_ldisc.c
+++ b/drivers/char/tty_ldisc.c
@@ -207,6 +207,7 @@ static void tty_ldisc_put(struct tty_ldisc *ld)
ldo->refcount--;
module_put(ldo->owner);
spin_unlock_irqrestore(&tty_ldisc_lock, flags);
+ WARN_ON(ld->refcount);
kfree(ld);
}
I don't grok this code much, but is the WARN racing with something else
doing a get? ie. what is the value of ld->refcount before we drop the
lock?
> Let me know if i can provide any other information.
Try enabling TTY_DEBUG_HANGUP in drivers/char/tty_io.c ?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: ALSA fixes for non-coherent ppc32 again
From: Takashi Iwai @ 2009-06-22 7:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1245623678.16880.27.camel@pasglop>
At Mon, 22 Jun 2009 08:34:38 +1000,
Benjamin Herrenschmidt wrote:
>
> On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
> > Hi,
> >
> > Takashi Iwai posted patches to make ALSA work on non-coherent PPC32
> > systems (almost exactly) a year ago. See here:
> > http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
> >
> > As far as I can see these patches never went upstream. Where there any
> > objections or did we just forget about them? It would be cool, if the
> > patches could be merged now, as at least two platforms need this bugfix
> > (namely Sam440 and AmigaOne).
>
> I definitely forgot about those...
Me, too, almost... :)
> But I'm fine with what Takashi did
> for now, I can always make the powerpc helper for dma_mmap_coherent()
> smarter later on if necessary.
I updated the patch series for 2.6.31, including sparc32, parisc, mips
and sh support. The patches are found in test/dma-fix branch of sound
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git test/dma-fix
The old patches for 2.6.30 is found at history/dma-fix-2.6.30 branch
there, too.
For merging to the upstream, we'll need definitely discussions on
linux-arch ML or so, as once James Bottomley suggested. I'll try to
make it up once after the merge window.
But, it'd be helpful if someone can test the patches above beforehand,
of course :)
thanks,
Takashi
^ permalink raw reply
* Re: Badness at drivers/char/tty_ldisc.c:210 during shutdown
From: Sachin Sant @ 2009-06-22 6:43 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, alan
In-Reply-To: <4A3A2D2B.7070704@in.ibm.com>
Sachin Sant wrote:
> I came across the following badness message during shutdown on a
> Power6 box.
> This was with 2.6.30-git12(3fe0344faf7fdcb158bd5c1a9aec960a8d70c8e8)
>
> ------------[ cut here ]------------
> Badness at drivers/char/tty_ldisc.c:210
The badness message is still present with git18.
------------[ cut here ]------------
Badness at drivers/char/tty_ldisc.c:210
NIP: c00000000040a3e8 LR: c00000000040a3d0 CTR: 0000000000000000
REGS: c00000003cf6b7f0 TRAP: 0700 Not tainted (2.6.30-git18)
MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24000424 XER: 00000001
TASK = c00000003e308660[3846] 'vhangup' THREAD: c00000003cf68000 CPU: 1
<6>GPR00: 0000000000000001 c00000003cf6ba70 c000000000ef48c0 0000000000000001
<6>GPR04: 0000000000000001 c00000003819f000 c000000000407b60 0000000000000000
<6>GPR08: 0000000000000000 0000000000000000 0000000000000001 c000000000e1bce8
<6>GPR12: 0000000044000428 c000000001002600 00000000ffffffff ffffffffffffffff
<6>GPR16: 0000000021fd8a50 0000000000000002 0000000000000000 0000000021fc03b0
<6>GPR20: 0000000000000000 0000000000000000 c00000003d04c700 0000000000000001
<6>GPR24: 0000000000000000 0000000000000000 0000000000000001 c000000040007e20
<6>GPR28: 0000000000000000 c0000000013ffd38 c000000000e7e860 c00000003cf6ba70
NIP [c00000000040a3e8] .tty_ldisc_put+0xbc/0xf4
LR [c00000000040a3d0] .tty_ldisc_put+0xa4/0xf4
Call Trace:
[c00000003cf6ba70] [c00000000040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable)
[c00000003cf6bb10] [c00000000040a7c8] .tty_ldisc_reinit+0x38/0x80
[c00000003cf6bba0] [c00000000040b1d8] .tty_ldisc_hangup+0x190/0x260
[c00000003cf6bc40] [c000000000401090] .do_tty_hangup+0x188/0x4c0
[c00000003cf6bd20] [c000000000401440] .tty_vhangup_self+0x34/0x54
[c00000003cf6bdb0] [c00000000019236c] .sys_vhangup+0x38/0x58
[c00000003cf6be30] [c000000000008534] syscall_exit+0x0/0x40
Instruction dump:
912b0088 4bcd17bd 60000000 e87e8008 7f44d378 481c04fd 60000000 801b0008
7c09fe70 7d200278 7c004850 54000ffe <0b000000> 7f63db78 4bd7c98d 60000000
Let me know if i can provide any other information.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: Badness on the Warp
From: Pekka Enberg @ 2009-06-22 4:48 UTC (permalink / raw)
To: Sean MacLennan
Cc: Frans Pop, linux-kernel, linuxppc-dev, Paul Mackerras,
David Gibson
In-Reply-To: <20090621183658.2b408e69@lappy.seanm.ca>
Hi Sean,
On Mon, Jun 22, 2009 at 1:36 AM, Sean MacLennan<smaclennan@pikatech.com> wrote:
> On Mon, 22 Jun 2009 08:25:04 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> Right, our interrupt controllers need those fixes, they are low
>> on my priority list since it's a reasonably harmless warning and I'm
>> still chasing some actual breakage (though maybe not directly related
>> to your patches).
>>
>> Kumar already submitted a couple, Frans, feel free to beat me
>> at converting UIC (just use kmalloc directly in there instead
>> of alloc_bootmem).
>
> I can make the changes to UIC if you want. They badness is harmless (it
> ends up calling kzalloc anyway), but hard to explain to our PV (Product
> Verification) department that they can ignore what looks like a crash ;)
Right. We can also wrap the WARN_ON() in CONFIG_DEBUG_BOOTMEM or
something too but I'd prefer a proper fix here.
Pekka
^ permalink raw reply
* Re: [PATCH] Have git ignore generated files from dtc compile
From: Sean MacLennan @ 2009-06-22 2:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20090622015211.GA4003@yookeroo.seuss>
On Mon, 22 Jun 2009 11:52:11 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sun, Jun 21, 2009 at 09:28:00PM -0400, Jon Smirl wrote:
> > Have git ignore generated files from dtc compile
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Acked-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Sean MacLennan <smaclennan@pikatech.com>
^ permalink raw reply
* Re: [PATCH] Have git ignore generated files from dtc compile
From: David Gibson @ 2009-06-22 1:52 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <20090622012800.31652.35886.stgit@terra>
On Sun, Jun 21, 2009 at 09:28:00PM -0400, Jon Smirl wrote:
> Have git ignore generated files from dtc compile
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
> diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
> index d57aa5c..dab1b41 100644
> --- a/arch/powerpc/boot/.gitignore
> +++ b/arch/powerpc/boot/.gitignore
> @@ -37,3 +37,13 @@ zImage.pseries
> zconf.h
> zlib.h
> zutil.h
> +fdt.c
> +fdt.h
> +fdt_ro.c
> +fdt_rw.c
> +fdt_strerror.c
> +fdt_sw.c
> +fdt_wip.c
> +libfdt.h
> +libfdt_internal.h
> +
> diff --git a/scripts/dtc/.gitignore b/scripts/dtc/.gitignore
Except that I don't think this can go in via the powerpc tree, given
it touches scripts/
> new file mode 100644
> index 0000000..095acb4
> --- /dev/null
> +++ b/scripts/dtc/.gitignore
> @@ -0,0 +1,5 @@
> +dtc
> +dtc-lexer.lex.c
> +dtc-parser.tab.c
> +dtc-parser.tab.h
> +
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] Have git ignore generated files from dtc compile
From: Jon Smirl @ 2009-06-22 1:28 UTC (permalink / raw)
To: linuxppc-dev
Have git ignore generated files from dtc compile
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
arch/powerpc/boot/.gitignore | 10 ++++++++++
scripts/dtc/.gitignore | 5 +++++
2 files changed, 15 insertions(+), 0 deletions(-)
create mode 100644 scripts/dtc/.gitignore
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index d57aa5c..dab1b41 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -37,3 +37,13 @@ zImage.pseries
zconf.h
zlib.h
zutil.h
+fdt.c
+fdt.h
+fdt_ro.c
+fdt_rw.c
+fdt_strerror.c
+fdt_sw.c
+fdt_wip.c
+libfdt.h
+libfdt_internal.h
+
diff --git a/scripts/dtc/.gitignore b/scripts/dtc/.gitignore
new file mode 100644
index 0000000..095acb4
--- /dev/null
+++ b/scripts/dtc/.gitignore
@@ -0,0 +1,5 @@
+dtc
+dtc-lexer.lex.c
+dtc-parser.tab.c
+dtc-parser.tab.h
+
^ permalink raw reply related
* [PATCH] Have git ignore generated files from dtc compile
From: Jon Smirl @ 2009-06-22 1:26 UTC (permalink / raw)
To: linuxppc-dev
---
arch/powerpc/boot/.gitignore | 10 ++++++++++
scripts/dtc/.gitignore | 5 +++++
2 files changed, 15 insertions(+), 0 deletions(-)
create mode 100644 scripts/dtc/.gitignore
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index d57aa5c..dab1b41 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -37,3 +37,13 @@ zImage.pseries
zconf.h
zlib.h
zutil.h
+fdt.c
+fdt.h
+fdt_ro.c
+fdt_rw.c
+fdt_strerror.c
+fdt_sw.c
+fdt_wip.c
+libfdt.h
+libfdt_internal.h
+
diff --git a/scripts/dtc/.gitignore b/scripts/dtc/.gitignore
new file mode 100644
index 0000000..095acb4
--- /dev/null
+++ b/scripts/dtc/.gitignore
@@ -0,0 +1,5 @@
+dtc
+dtc-lexer.lex.c
+dtc-parser.tab.c
+dtc-parser.tab.h
+
^ permalink raw reply related
* Re: Badness on the Warp
From: Benjamin Herrenschmidt @ 2009-06-21 22:57 UTC (permalink / raw)
To: Sean MacLennan
Cc: Frans Pop, linux-kernel, linuxppc-dev, Pekka Enberg,
Paul Mackerras, David Gibson
In-Reply-To: <20090621183658.2b408e69@lappy.seanm.ca>
On Sun, 2009-06-21 at 18:36 -0400, Sean MacLennan wrote:
> On Mon, 22 Jun 2009 08:25:04 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Right, our interrupt controllers need those fixes, they are low
> > on my priority list since it's a reasonably harmless warning and I'm
> > still chasing some actual breakage (though maybe not directly related
> > to your patches).
> >
> > Kumar already submitted a couple, Frans, feel free to beat me
> > at converting UIC (just use kmalloc directly in there instead
> > of alloc_bootmem).
>
> I can make the changes to UIC if you want. They badness is harmless (it
> ends up calling kzalloc anyway), but hard to explain to our PV (Product
> Verification) department that they can ignore what looks like a crash ;)
Heh, right, but hopefully we should have that fixed before .31 is
out :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Make bridge bug in linux 2.6.25b using Powerpc 405ep
From: Benjamin Herrenschmidt @ 2009-06-21 22:39 UTC (permalink / raw)
To: zhong wang; +Cc: linuxppc-dev
In-Reply-To: <8647.75661.qm@web15308.mail.cnb.yahoo.com>
On Sun, 2009-06-21 at 11:45 +0800, zhong wang wrote:
> hello all:
> I encountered a very strange question, I am using the AMCC
> Powerpc 405ep its Emac0 received a single phy intel 971, Emac1
> received RTL8305SB, they shared Mdio, Mdc. 2.6.25.10 I use
> the kernel.
> The problem is to use the following command will be eth0,
> eth1 configured bridge .my borad will down often. Hope that
> helps!
>
>
>
(Please use plain text emails)
When you say that your board is down, this lacks specifics about what
exactly happens. Also, do you have a HW debugger such as an abatron BDI
or a RiscWatch connected to it ? If it's hung, that would help finding
out where.
Cheers,
Ben.
>
> ______________________________________________________________________
> 好玩贺卡等你发，邮箱贺卡全新上线！
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Badness on the Warp
From: Sean MacLennan @ 2009-06-21 22:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frans Pop, linux-kernel, linuxppc-dev, Pekka Enberg,
Paul Mackerras, David Gibson
In-Reply-To: <1245623104.16880.26.camel@pasglop>
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Right, our interrupt controllers need those fixes, they are low
> on my priority list since it's a reasonably harmless warning and I'm
> still chasing some actual breakage (though maybe not directly related
> to your patches).
>
> Kumar already submitted a couple, Frans, feel free to beat me
> at converting UIC (just use kmalloc directly in there instead
> of alloc_bootmem).
I can make the changes to UIC if you want. They badness is harmless (it
ends up calling kzalloc anyway), but hard to explain to our PV (Product
Verification) department that they can ignore what looks like a crash ;)
Cheers,
Sean
^ permalink raw reply
* Re: ALSA fixes for non-coherent ppc32 again
From: Benjamin Herrenschmidt @ 2009-06-21 22:34 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: Takashi Iwai, linuxppc-dev
In-Reply-To: <20090621181855.74980@gmx.net>
On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
> Hi,
>
> Takashi Iwai posted patches to make ALSA work on non-coherent PPC32
> systems (almost exactly) a year ago. See here:
> http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
>
> As far as I can see these patches never went upstream. Where there any
> objections or did we just forget about them? It would be cool, if the
> patches could be merged now, as at least two platforms need this bugfix
> (namely Sam440 and AmigaOne).
I definitely forgot about those... But I'm fine with what Takashi did
for now, I can always make the powerpc helper for dma_mmap_coherent()
smarter later on if necessary.
Cheers,
Ben.
^ permalink raw reply
* Re: Badness on the Warp
From: Benjamin Herrenschmidt @ 2009-06-21 22:25 UTC (permalink / raw)
To: Pekka Enberg
Cc: Frans Pop, linux-kernel, linuxppc-dev, Paul Mackerras,
Sean MacLennan, David Gibson
In-Reply-To: <84144f020906210320n2984807dw2d4b4fb38afd22cf@mail.gmail.com>
On Sun, 2009-06-21 at 13:20 +0300, Pekka Enberg wrote:
> The WARN_ON() is there to let us know that someone is doing a bootmem
> allocation but the slab allocator is already up. So the proper fix
> here is to use kmalloc() directly in the call-site that triggers this
> WARN_ON. I'm cc'ing Ben as he has been taking care of the fall-out
> from my patches on ppc.
>
Right, our interrupt controllers need those fixes, they are low
on my priority list since it's a reasonably harmless warning and I'm
still chasing some actual breakage (though maybe not directly related to
your patches).
Kumar already submitted a couple, Frans, feel free to beat me
at converting UIC (just use kmalloc directly in there instead
of alloc_bootmem).
Cheers,
Ben.
^ permalink raw reply
* ALSA fixes for non-coherent ppc32 again
From: Gerhard Pircher @ 2009-06-21 18:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Takashi Iwai; +Cc: linuxppc-dev
Hi,
Takashi Iwai posted patches to make ALSA work on non-coherent PPC32
systems (almost exactly) a year ago. See here:
http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
As far as I can see these patches never went upstream. Where there any
objections or did we just forget about them? It would be cool, if the
patches could be merged now, as at least two platforms need this bugfix
(namely Sam440 and AmigaOne).
Thanks!
Gerhard
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
^ permalink raw reply
* Re: [PATCH 1/3] AMCC Crypto4xx Device Driver v7
From: Herbert Xu @ 2009-06-21 13:53 UTC (permalink / raw)
To: Shasi Pulijala; +Cc: linuxppc-dev, linux-crypto
In-Reply-To: <DB599F406D04E34389140B7D99C71B1B07D83E96@SDCEXCHANGE01.ad.amcc.com>
Shasi Pulijala <spulijala@amcc.com> wrote:
> Hi,
> I am re-sending this patch as a patch series of 3, I am assuming the earlier one did not go through the mailing lists
> because it was over the size limit.
Actually the original patch came through the list and to me :)
However I'm not against splitting it up, but if you are going to
do it please make sure that each patch compiles by itself since
we want a bisectable tree.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Badness on the Warp
From: Pekka Enberg @ 2009-06-21 10:20 UTC (permalink / raw)
To: Frans Pop
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Sean MacLennan,
David Gibson
In-Reply-To: <200906210628.35553.elendil@planet.nl>
On Sun, Jun 21, 2009 at 7:28 AM, Frans Pop<elendil@planet.nl> wrote:
> On Sunday 21 June 2009, Sean MacLennan wrote:
>> I found the source of the badness. The backtrace is correct:
>>
>> uic_init_one
>
> So that's in arch/powerpc/sysdev/uic.c.
>
>> ___alloc_bootmem
>> ___alloc_bootmem_nopanic
>> alloc_arch_preferred_bootmem
>>
>> In alloc_arch_preferred_bootmem we have:
>>
>> =A0 =A0 =A0 if (WARN_ON_ONCE(slab_is_available()))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return kzalloc(size, GFP_NOWAIT);
>>
>> Since the slab is available (it had better be or the call will return
>> NULL), we get the badness message, then a successful return from
>> kzalloc.
>>
>> I believe the author wants something like:
>>
>> =A0 =A0 =A0 if (slab_is_available())
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return kzalloc(size, GFP_NOWAIT);
>> =A0 =A0 =A0 else
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 WARN_ON_ONCE(1);
>
> Well, I myself have no idea. It could also indicate a bug in the uic code=
.
>
> But let's CC some people responsible for this code. Pekka recently added
> this WARN that triggers in your case; David and Paul look to be the
> people most involved in the uic code.
>
> Start of the thread is at http://lkml.org/lkml/2009/6/20/165.
The WARN_ON() is there to let us know that someone is doing a bootmem
allocation but the slab allocator is already up. So the proper fix
here is to use kmalloc() directly in the call-site that triggers this
WARN_ON. I'm cc'ing Ben as he has been taking care of the fall-out
from my patches on ppc.
Pekka
^ permalink raw reply
* Re: Badness on the Warp
From: H. Peter Anvin @ 2009-06-21 7:03 UTC (permalink / raw)
To: Frans Pop; +Cc: linuxppc-dev, linux-kernel, Sean MacLennan
In-Reply-To: <200906202256.46073.elendil@planet.nl>
Frans Pop wrote:
>
> The fact that your bisect ended at a merge essentially means that it is
> invalid. As a merge does not introduce any actual change (unless it
> includes changes to resolve conflicts), it normally cannot be the cause
> of a regression.
>
Sort of. You can have a "bum merge" where code conflicts logically,
even if it isn't visible as a conflict in git. Furthermore, of course,
you can have misresolved actual conflicts.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: Badness on the Warp
From: Frans Pop @ 2009-06-21 4:28 UTC (permalink / raw)
To: Sean MacLennan
Cc: linuxppc-dev, Pekka Enberg, Paul Mackerras, linux-kernel,
David Gibson
In-Reply-To: <20090620194250.5a3e826f@lappy.seanm.ca>
On Sunday 21 June 2009, Sean MacLennan wrote:
> I found the source of the badness. The backtrace is correct:
>
> uic_init_one
So that's in arch/powerpc/sysdev/uic.c.
> ___alloc_bootmem
> ___alloc_bootmem_nopanic
> alloc_arch_preferred_bootmem
>
> In alloc_arch_preferred_bootmem we have:
>
> if (WARN_ON_ONCE(slab_is_available()))
> return kzalloc(size, GFP_NOWAIT);
>
> Since the slab is available (it had better be or the call will return
> NULL), we get the badness message, then a successful return from
> kzalloc.
>
> I believe the author wants something like:
>
> if (slab_is_available())
> return kzalloc(size, GFP_NOWAIT);
> else
> WARN_ON_ONCE(1);
Well, I myself have no idea. It could also indicate a bug in the uic code.
But let's CC some people responsible for this code. Pekka recently added
this WARN that triggers in your case; David and Paul look to be the
people most involved in the uic code.
Start of the thread is at http://lkml.org/lkml/2009/6/20/165.
Cheers,
FJP
^ 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