On Wed, Jun 02, 2010 at 09:33:16PM +1000, Paul Mackerras wrote:
> On Fri, May 28, 2010 at 12:09:24PM +0530, K.Prasad wrote:
>
> > Please find a new set of patches that have the following changes.
>
> Thanks. There are a couple of minor things still remaining (dangling
> put_cpu in arch_unreg
Patch Overview:
The pci_restore_state API is shared by both power management code and Extended
Error Handling (EEH) code on Power. This patch adds an additional recovery
function to pci_restore_state API. The problem being addressed is that Power
Management semantics only allow the saved state of
On Thu, Jun 3, 2010 at 5:22 PM, Stephen Neuendorffer
wrote:
> It seems to me like what's confused in the defconfigs is two concepts:
> 1) The requirements of a platform (what options must be set and must not
> be set)
> 2) The guarantee that a particular config was known to work at some
> point in
It seems to me like what's confused in the defconfigs is two concepts:
1) The requirements of a platform (what options must be set and must not
be set)
2) The guarantee that a particular config was known to work at some
point in time.
The first could allow you to drop 99% of the options (I think t
On Thu, Jun 3, 2010 at 3:17 PM, Grant Likely wrote:
> Signed-off-by: Grant Likely
> CC: linuxppc-dev@lists.ozlabs.org
> CC: Benjamin Herrenschmidt
> ---
... and my timing is fantastic in light of the defconfig discussion
going on on the LKML. :-)
http://lkml.org/lkml/2010/6/2/472
g.
___
It was possible to overflow the buffer used to print out the formatted
version of the resource path. The fix is to limit the number of
bytes that get formatted.
This patch also updates the ipr_show_resource_path function to display the
resource address for devices that are attached to adapters th
Signed-off-by: Grant Likely
CC: linuxppc-dev@lists.ozlabs.org
CC: Benjamin Herrenschmidt
---
arch/powerpc/configs/52xx/cm5200_defconfig| 45 +++--
arch/powerpc/configs/52xx/lite5200b_defconfig | 109 +
arch/powerpc/configs/52xx/motionpro_defconfig | 76 ++---
arch/powerp
Hello!
My hardware: Apple Power Mac G5 "Late 2005"
I've just compiled kernel 2.6.34 for Gentoo Linux.
# ACCEPT_KEYWORDS="~ppc64" emerge -1 sys-kernel/gentoo-sources-2.6.34
I tried the "KVM support for PowerPC book3s_64 processors" just to see if what
I could do with KVM on my Apple Power Mac G5
On Thu, 2010-06-03 at 10:24 +0200, Christoph Hellwig wrote:
> Irq stacks provide an essential protection from stack overflows through
> external interrupts, at the cost of two additionals stacks per CPU.
>
> Enable them unconditionally to simplify the kernel build and prevent
> people from acciden
On 06/03/2010 06:20 AM, Paul Mackerras wrote:
Currently the kernel supports processes running in little-endian mode
on machines that have a little-endian mode (as opposed to an endian
bit in the TLB entry like most embedded PowerPC processors do, which
is a much better idea). Little-endian mode
Currently the kernel supports processes running in little-endian mode
on machines that have a little-endian mode (as opposed to an endian
bit in the TLB entry like most embedded PowerPC processors do, which
is a much better idea). Little-endian mode comes in two flavours:
so-called "PowerPC" littl
Hi,
I am building a kernel module on linux-2.6.31 on a PowerPC architecture.
While buildng the module i am including a static library given by the
client.
I am getting the below warning while building the module with the library:
WARNING: /home/drivers/modules/module.o (.ghsinfo): unexpected
no
Scott Wood wrote:
> On 06/02/2010 03:06 AM, Martyn Welch wrote:
> I think that's a more fundamental change to CPM early debug than I
> can
> handle right now.
>>>
>>> Is IMMRBASE on your board at some address that has a low likelihood of
>>> conflicting when treated as a kernel effectiv
On Wed, 2010-06-02 at 04:22 +0530, Vaidyanathan Srinivasan wrote:
> > If the group were a core group, the total would be much higher and we'd
> > likely end up assigning 1 to each before we'd run out of capacity.
>
> This is a tricky case because we are depending upon the
> DIV_ROUND_CLOSEST to d
Irq stacks provide an essential protection from stack overflows through
external interrupts, at the cost of two additionals stacks per CPU.
Enable them unconditionally to simplify the kernel build and prevent
people from accidentally disabling them.
Signed-off-by: Christoph Hellwig
Index: linux
15 matches
Mail list logo
