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.
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:
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
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
On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell s...@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
[c0003cf6ba70] [c040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable)
[c0003cf6bb10] [c040a7c8] .tty_ldisc_reinit+0x38/0x80
[c0003cf6bba0] [c040b1d8] .tty_ldisc_hangup+0x190/0x260
[c0003cf6bc40] [c0401090] .do_tty_hangup+0x188/0x4c0
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
Original-Nachricht
Datum: Mon, 22 Jun 2009 09:12:35 +0200
Von: Takashi Iwai ti...@suse.de
An: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-...@ozlabs.org
Betreff: Re: ALSA fixes for non-coherent ppc32 again
At Mon,
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
On Mon, Jun 22, 2009 at 06:34:15PM +1000, Stephen Rothwell wrote:
On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell s...@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:
Thanks for replies!
2009/6/22 Stefan Roese s...@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
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin roel.kl...@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
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
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 0250, size: 8280 Kbytes
OF stdout device is: /ht/i...@8/ser...@2f8
Preparing
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:
[c09f3c30] c052c7dc
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
Hi,
I have the same board and I had a similar problem. I use 2.6.30, so I don't
know whether 2.6.25 supports the following - however, here's my suggestion.
Set these options in your kernel config: CONFIG_GPIOLIB=y and
CONFIG_PPC4xx_GPIO=y. Before compilation do export
KCPPFLAGS=-DARCH_NR_GPIOS=32
Unsigned `len' cannot be less than 0.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Or should it be `if (!buf || len MAX)' and what should MAX be then?
diff --git a/arch/powerpc/platforms/cell/spufs/sputrace.c
b/arch/powerpc/platforms/cell/spufs/sputrace.c
index d0b1f3f..8f799ee 100644
On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote:
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at
On Mon, 2009-06-22 at 14:20 -0700, Dan Williams wrote:
On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote:
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote:
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
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote:
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
Actually, no, reverting that one doesn't fix it.
A full run of git bisect turns up this commit as the culprit; I'll make
a fuss on lkml:
I haven't had the full log of that boot failure, but reverting the patch
Brian suggested won't work well indeed, as I said, from the moment slab
is
On Mon, 2009-06-22 at 11:10 +0200, Laszlo Fekete wrote:
Hello!
Is there any idea for the solution?
Hard to tell yet. Looks indeed like something is wrong with the
interrupt controller.
Any chance you can bisect that ? I'll also have a look on my side,
it's definitely not something obvious.
The non-debug case in ps3/mm.c uses pr_debug(), so that the compiler
still does type checks etc. and doesn't complain about unused
variables in the non-debug case.
However with DEBUG=n and CONFIG_DYNAMIC_DEBUG=y there's still code
generated for those pr_debugs().
size before:
textdata
On Tue, 2009-06-23 at 11:18 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2009-06-22 at 11:10 +0200, Laszlo Fekete wrote:
Hello!
Is there any idea for the solution?
Hard to tell yet. Looks indeed like something is wrong with the
interrupt controller.
Any chance you can bisect that ?
On Sun, 2009-06-14 at 11:10 +0200, Guennadi Liakhovetski wrote:
P610 (and tested it on P630 and P640 too)
Also, send me a tarball of /proc/device-tree please.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Commit 31207dab7d2e63795eb15823947bd2f7025b08e2
Fix incorrect allocation of interrupt rev-map
introduced a regression crashing on boot on machines using
a DCR based MPIC, such as the Cell blades.
The reason is that the irq host data structure is initialized
much later as a result of that patch,
This appears to be a ppc thing, so let's cc that list. Let's also cc
the driver's author and other contributors. Please cc these people on
future versions of the patch also.
On Mon, 15 Jun 2009 17:17:54 +0200 Richard R__jfors
richard.rojfors@mocean-labs.com wrote:
This patch splits
thanks, applied.
-#define HCAD_VERSION 0026
+#define HCAD_VERSION 0027
the driver version was already 0027 (since bde2cfaf), so I dropped this chunk.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
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 replace the bootmem_alloc with a kzalloc and the badness
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
32 matches
Mail list logo
