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.
--
Hi Sean,
On Mon, Jun 22, 2009 at 1:36 AM, Sean MacLennan wrote:
> On Mon, 22 Jun 2009 08:25:04 +1000
> Benjamin Herrenschmidt 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 a
On Mon, 22 Jun 2009 11:52:11 +1000
David Gibson 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
>
> Acked-by: David Gibson
Acked-by: Sean MacLennan
___
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
Acked-by: David Gibson
> diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
> index d57aa5c..dab1b41 100644
> --- a/arch/powerpc/boot
Have git ignore generated files from dtc compile
Signed-off-by: Jon Smirl
---
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/.g
---
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
On Sun, 2009-06-21 at 18:36 -0400, Sean MacLennan wrote:
> On Mon, 22 Jun 2009 08:25:04 +1000
> Benjamin Herrenschmidt 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 actua
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
>
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt 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).
>
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
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
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
Shasi Pulijala 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
On Sun, Jun 21, 2009 at 7:28 AM, Frans Pop 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_
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
15 matches
Mail list logo