* 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: 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: 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: 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
* [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
* [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
* 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
* 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: 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: 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: 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: 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
* [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: [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
* 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: 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: 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: 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: [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: Lada Podivin @ 2009-06-22 11:31 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200906221123.11192.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
Thanks for replies!
2009/6/22 Stefan Roese <sr@denx.de>
> 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).
>
Right, the pin multiplexing was the problem. I didn't know that U-BOOT can
do that - very useful information, thank you again!
>
> BTW: Are you using Kilauea or a custom 405EX board?
>
> Best regards,
> Stefan
>
>
Yes, it's the Kilauea board.
[-- Attachment #2: Type: text/html, Size: 1104 bytes --]
^ permalink raw reply
* [PATCH] Sky CPU: redundant or incorrect tests on unsigned
From: Roel Kluin @ 2009-06-22 16:40 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Andrew Morton
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Can these be removed or do we need an `if (count > MAX)' test, and
what should MAX be then?
diff --git a/drivers/misc/hdpuftrs/hdpu_cpustate.c b/drivers/misc/hdpuftrs/hdpu_cpustate.c
index 176fe4e..35000cf 100644
--- a/drivers/misc/hdpuftrs/hdpu_cpustate.c
+++ b/drivers/misc/hdpuftrs/hdpu_cpustate.c
@@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file *file, char *buf,
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
if (count == 0)
return 0;
@@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct file *file, const char *buf,
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
-
if (count == 0)
return 0;
^ permalink raw reply related
* AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Sergej.Stepanov @ 2009-06-22 14:31 UTC (permalink / raw)
To: chris.pringle, scottwood; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4A3A23FA.1000407@oxtel.com>
>The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE
>needs _PAGE_COHERENT in order to work correctly, and in fact there is
>now a comment in there to that affect in 2.6.29. Backporting that change
>has made it work on 2.6.26. Both this patch, and the fix to head_32.S
>are needed for it to work correctly on older kernels.
>
>Chris
Hello Chris,
sorry for dummy, but if it possible, could you, please, send a correspondin=
g summary patch of backporting you've done for older kernels?
or just summary of that changes once again?
Many thanks
Sergej.=
^ permalink raw reply
* Boot failure on the powerstation with 2.6.30 latest
From: James Bottomley @ 2009-06-22 15:16 UTC (permalink / raw)
To: linuxppc-dev
2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I
can begin bisecting.
The boot log of the hang is:
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 02500000, size: 8280 Kbytes
OF stdout device is: /ht/isa@8/serial@2f8
Preparing to boot Linux version 2.6.30 (jejb@claymoor) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009
command line: root=/dev/sda3 ro console=ttyS0,19200n1
memory layout at init:
alloc_bottom : 0000000002d16000
alloc_top : 0000000030000000
alloc_top_hi : 0000000080000000
rmo_top : 0000000030000000
ram_top : 0000000080000000
instantiating rtas at 0x000000002fff5000... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000001... done
starting cpu hw idx 0000000000000002... done
starting cpu hw idx 0000000000000003... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000003117000 -> 0x0000000003117640
Device tree struct 0x0000000003118000 -> 0x000000000311b000
Calling quiesce...
returning from prom_init
So it looks like some type of early boot failure or handoff in head_64
James
^ permalink raw reply
* ppc405ex GPIO mapping
From: Cote, Sylvain @ 2009-06-22 15:13 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
Hi,
I am using kernel 2.6.25.20 on my Kilauea eval board (ppc405ex). I want to access some GPIO's. I have configured my u-boot to reflect what GPIO configuration I need. I try to access my GPIO's in my driver. When accessing GPIO's, I get this error in the kernel <<Unable to handle kernel paging request for data at address 0xef600800>>. 0xef600800 is the base address of GPIO in the ppc405ex.
It looks like GPIO's are not mapped in my kernel. I have tried to add this entry in my dts file (under POB0: opb ) but it does not work:
GPIO: gpio@ef600800
{
compatible = "ibm,gpio-405ex";
reg = <ef600800 00000020>;
};
Any clues on this issues?
Thanks
Sylvain C.
This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries.
The information is intended to be for the use of the individual(s) or
entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
\r
[-- Attachment #2: Type: text/html, Size: 5231 bytes --]
^ permalink raw reply
* Re: Boot failure on the powerstation with 2.6.30 latest
From: Brian King @ 2009-06-22 16:11 UTC (permalink / raw)
To: James Bottomley; +Cc: linuxppc-dev
In-Reply-To: <1245683801.6901.8.camel@mulgrave.site>
James,
I was running into a similar hang on one of my Power boxes as well.
Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system
to boot. It looks like that patch injected a bug where we can end up
waiting on an uninitialized mutex:
[c0000000009f3c30] c00000000052c7dc .mutex_lock+0x34/0x50
[c0000000009f3cb0] c00000000008b190 .get_online_cpus+0x3c/0x74
[c0000000009f3d40] c000000000146cd0 .kmem_cache_create+0xcc/0x548
[c0000000009f3e50] c000000000032ae0 .pgtable_cache_init+0x28/0x6c
[c0000000009f3ee0] c000000000780960 .start_kernel+0x1ec/0x520
[c0000000009f3f90] c0000000000083d8 .start_here_common+0x1c/0x44
The mutex gets initialized in cpu_hotplug_init, which doesn't get called until
after pgtable_cache_init.
-Brian
James Bottomley wrote:
> 2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I
> can begin bisecting.
>
> The boot log of the hang is:
>
> Please wait, loading kernel...
> Elf64 kernel loaded...
> Loading ramdisk...
> ramdisk loaded at 02500000, size: 8280 Kbytes
> OF stdout device is: /ht/isa@8/serial@2f8
> Preparing to boot Linux version 2.6.30 (jejb@claymoor) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009
> command line: root=/dev/sda3 ro console=ttyS0,19200n1
> memory layout at init:
> alloc_bottom : 0000000002d16000
> alloc_top : 0000000030000000
> alloc_top_hi : 0000000080000000
> rmo_top : 0000000030000000
> ram_top : 0000000080000000
> instantiating rtas at 0x000000002fff5000... done
> boot cpu hw idx 0000000000000000
> starting cpu hw idx 0000000000000001... done
> starting cpu hw idx 0000000000000002... done
> starting cpu hw idx 0000000000000003... done
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000003117000 -> 0x0000000003117640
> Device tree struct 0x0000000003118000 -> 0x000000000311b000
> Calling quiesce...
> returning from prom_init
>
> So it looks like some type of early boot failure or handoff in head_64
>
> James
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ 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