On Mon, 2008-11-03 at 18:07 +1100, Stephen Rothwell wrote:
> And get rid of this build warning:
>
> arch/powerpc/platforms/pseries/pci_dlpar.c: In function 'init_phb_dynamic':
> arch/powerpc/platforms/pseries/pci_dlpar.c:192: warning: unused variable 'b'
>
> This is one of the very few warnings l
And get rid of this build warning:
arch/powerpc/platforms/pseries/pci_dlpar.c: In function 'init_phb_dynamic':
arch/powerpc/platforms/pseries/pci_dlpar.c:192: warning: unused variable 'b'
This is one of the very few warnings left in a ppc64_defconfig build and
getting rid of it will make it easie
And get rid of this build warning:
arch/powerpc/platforms/pseries/pci_dlpar.c: In function 'init_phb_dynamic':
arch/powerpc/platforms/pseries/pci_dlpar.c:192: warning: unused variable 'b'
This is one of the very few warnings left in a ppc64_defconfig build and
getting rid of it will make it easie
Nick Piggin writes:
> This is an interesting one for me. AFAIKS it is possible to use lwsync for
> a full barrier after a successful ll/sc operation, right? (or stop me here
> if I'm wrong).
An lwsync would order subsequent loads after the lwarx/ldarx, and
subsequent stores after the stcwx./stcdx
Ben Dooks wrote:
When reading from a device that is not present or declines to respond
to, e.g., a non-existent register address, CPM immediately reports a
NAK condition in the TxBD, but the driver kept waiting until a timeout,
which takes 1 second and causes an ugly console error message.
hmm,
> Cropping the size of the memory node. That was simplest to do from the
> cuboot wrapper at the time. If marking it reserved via a reserve map
> is more elegant and correct, we could do that.
>
> But I will still like to know what about the other way is hairy please.
I don't like it :-) Bad f
On Mon, 03 Nov 2008 08:33:16 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-11-02 at 08:41 -0500, Josh Boyer wrote:
> > On Sun, Nov 02, 2008 at 08:55:02AM +1100, Benjamin Herrenschmidt wrote:
> > >On Sat, 2008-11-01 at 07:30 -0400, Josh Boyer wrote:
> > >>
> > >> That is o
On Fri, Oct 31, 2008 at 05:29:25PM -0700, Mike Ditto wrote:
> Make the driver report an ENXIO error immediately upon NAK instead of
> waiting for another interrupt and getting a timeout.
>
> Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
> ---
> When reading from a device that is not present or dec
On Sat, Nov 01, 2008 at 11:43:15AM +0300, Maxim Uvarov wrote:
> 2008/11/1 Simon Horman <[EMAIL PROTECTED]>
>
> > On Fri, Oct 31, 2008 at 09:53:23AM +0300, Maxim Uvarov wrote:
> > > 2008/10/31 Simon Horman <[EMAIL PROTECTED]>
> > >
> > > > Hi,
> > > >
> > > > Could someone please comment on the sat
A published errata for ppc440epx states, that when running Linux with both
EHCI and OHCI modules loaded, the EHCI module experiences a fatal error
when a high-speed device is connected to the USB2.0, and functions normally
if OHCI module is not loaded.
There used to be recommendation to use only h
On Sun, 2008-11-02 at 08:41 -0500, Josh Boyer wrote:
> On Sun, Nov 02, 2008 at 08:55:02AM +1100, Benjamin Herrenschmidt wrote:
> >On Sat, 2008-11-01 at 07:30 -0400, Josh Boyer wrote:
> >>
> >> That is on purpose. The chip has an errata that causes badness if
> >> you use the last XX bytes of DRAM
arch/powerpc/platforms/cell/ras.c:299: error: implicit declaration of function
'crash_shutdown_register'
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/ras.c |1 +
1 file changed, 1 insertion(+)
--- a/arch/powerpc/platforms/cell/ras.c
+++ b/arch/powerpc/
drivers/ps3/ps3-lpm.c:838: error: implicit declaration of function
'get_hard_smp_processor_id'
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
drivers/ps3/ps3-lpm.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/ps3/ps3-lpm.c
+++ b/drivers/ps3/ps3-lpm.c
@@ -22,6 +22,7 @@
#inclu
After I updated to 67d1128425 I get plenty of this:
| VFS: Mounted root (nfs filesystem) readonly.
| Freeing unused kernel memory: 148k init
| BUG: sleeping function called from invalid context at
/home/bigeasy/git/linux-2.6-powerpc/mm/mmap.c:234
| in_atomic():1, irqs_disabled():0
| Call Trace:
|
On Sun, Nov 02, 2008 at 08:55:02AM +1100, Benjamin Herrenschmidt wrote:
>On Sat, 2008-11-01 at 07:30 -0400, Josh Boyer wrote:
>>
>> That is on purpose. The chip has an errata that causes badness if
>> you use the last XX bytes of DRAM. I forget exactly what XX is, but
>> we just remove the last
15 matches
Mail list logo