PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at lea
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at lea
On Thu, 2011-04-14 at 10:43 +1000, David Gibson wrote:
> On Wed, Apr 13, 2011 at 09:05:12AM -0400, Josh Boyer wrote:
> > On Wed, Apr 13, 2011 at 04:38:56PM +1000, Michael Ellerman wrote:
> > >+++ b/arch/powerpc/boot/epapr.c
> > >@@ -0,0 +1,69 @@
> > >+/*
> > >+ * Bootwrapper for ePAPR compliant fir
On Wed, 2011-04-13 at 15:33 -0700, Nishanth Aravamudan wrote:
> PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
> in the PAPR) and can not cross a memory entitlement granule boundary
> (4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
> kmalloc does not gu
On Tue, 2011-04-12 at 19:03 +0200, Joachim Förster wrote:
> Note that the default 0x400... is the link address of the zImage
> wrapper
> rather than the one of THE kernel.
>
> Currently the link address seems to be hard-coded into
> arch/powerpc/boot/wrapper
> (a shell script). Since long ago I'm
On Wed, 2011-04-13 at 20:27 +0200, acrux wrote:
> i guess it's a different problem from the PegasosI G3 but i could be wrong.
>
> I'd like to receive feedbacks and a working kernel config if someone is
> running with success
> linux-2.6.26.x on a Pmac B&W G3. This machine, altough obsolete, is
On Wed, Apr 13, 2011 at 09:05:12AM -0400, Josh Boyer wrote:
> On Wed, Apr 13, 2011 at 04:38:56PM +1000, Michael Ellerman wrote:
> >+++ b/arch/powerpc/boot/epapr.c
> >@@ -0,0 +1,69 @@
> >+/*
> >+ * Bootwrapper for ePAPR compliant firmwares
>
> Out of curiosity, do we have a list of the ePAPR compli
Hi,
On Wed, Apr 13, 2011 at 6:21 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote:
>> > Actually I do get a crash in X later on... something in the radeon
>> DRM
>> > interrupt code is getting what looks like a NULL dereference. I'll
>> try
>> > to dig that
On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote:
> > Actually I do get a crash in X later on... something in the radeon
> DRM
> > interrupt code is getting what looks like a NULL dereference. I'll
> try
> > to dig that one later on. I don't know if it's related to your
> problem
> > at all tho
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at lea
Michel Dänzer wrote:
That does sound like the GPU locks up. Do you get any messages in dmesg
about lockups and attempts to reset the GPU at any time?
No.
Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
-dum
On 11-04-13 06:17 AM, Michael Guntsche wrote:
> Hi,
>
> Commit b987812b3fc "powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP."
> breaks compilation on non SMP powerpc machines.
Ah crap. I compile tested on SMP, so didn't see that.
> I wonder if this commit is really neccessary in the first pl
i guess it's a different problem from the PegasosI G3 but i could be wrong.
I'd like to receive feedbacks and a working kernel config if someone is
running with success linux-2.6.26.x on a Pmac B&W G3. This machine, altough
obsolete, is still quite common.
--nico
--
acrux
_
HI,
On Wed, Apr 13, 2011 at 3:58 AM, Benjamin Herrenschmidt
wrote:
>
> Actually I do get a crash in X later on... something in the radeon DRM
> interrupt code is getting what looks like a NULL dereference. I'll try
> to dig that one later on. I don't know if it's related to your problem
> at all
Recent commit b987812b3fcaf70fdf0037589e5d2f5f2453e6ce caused
a compile failure on UP because a considerably large block
of the file was included within CONFIG_SMP, hence making a stub
function not exposed on UP builds when it needed to be.
Relocate the stub to the #else /* ! CONFIG_SMP */ section
Stefan Roese wrote on 2011/04/13 17:21:33:
>
> Hi Joakim,
>
> On Wednesday 13 April 2011 16:58:21 Joakim Tjernlund wrote:
> > > This is on a 2.6.38 kernel (2.6.32 fails too). Debugging shows that
> > > __copy_tofrom_user() fails with return code 4 (called via
> > > ftrace_modify_code()).
> > >
> >
could it be the same issue i've on my old Pegasos1 G3 ??
regards,
Nello
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi Joakim,
On Wednesday 13 April 2011 16:58:21 Joakim Tjernlund wrote:
> > This is on a 2.6.38 kernel (2.6.32 fails too). Debugging shows that
> > __copy_tofrom_user() fails with return code 4 (called via
> > ftrace_modify_code()).
> >
> > Before digging deeper: Has anybody tried/tested ftrace on
On 13.04.2011 [15:59:44 +0100], David Laight wrote:
> > From:
> > linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org
> > [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozl
> > abs.org] On Behalf Of Nishanth Aravamudan
> > Sent: 13 April 2011 15:53
> > To: Ben Herrenschmidt
Stefan Roese wrote on 2011/04/13 16:32:21:
>
> Hi,
>
> I noticed that ftrace doesn't seem to work on MPC8xx. I'm trying to use it on
> an MPC855T board, but ftrace oopses upon startup:
>
> [0.028785] ftrace: allocating 10312 entries in 31 pages
> [0.038594] [ cut here ]
> From:
> linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozl
> abs.org] On Behalf Of Nishanth Aravamudan
> Sent: 13 April 2011 15:53
> To: Ben Herrenschmidt
> Cc: linuxppc-...@ozlabs.org; Paul Mackerras; Anton Blanchard
>
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at lea
Hi,
I noticed that ftrace doesn't seem to work on MPC8xx. I'm trying to use it on
an MPC855T board, but ftrace oopses upon startup:
[0.028785] ftrace: allocating 10312 entries in 31 pages
[0.038594] [ cut here ]
[0.038760] WARNING: at kernel/trace/ftrace.c:101
On Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote:
> On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel Dänzer wrote:
> > On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> > > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> > > > On Die, 2011-04-12 at 14:00 +0200,
On Wed, Apr 13, 2011 at 04:38:56PM +1000, Michael Ellerman wrote:
>+++ b/arch/powerpc/boot/epapr.c
>@@ -0,0 +1,69 @@
>+/*
>+ * Bootwrapper for ePAPR compliant firmwares
Out of curiosity, do we have a list of the ePAPR compliant firmwares (if
any)?
>+ *
>+ * Copyright 2010 David Gibson , IBM Corpo
On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel Dänzer wrote:
> On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> > > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > > On Tue, Apr 12, 2011 at 01:46:10PM +
Hello Gabriel
On Wed, Apr 13, 2011 at 12:31:44PM +0200, Gabriel Paubert wrote:
> On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> > Uwe Kleine-König writes:
> >
> > > $ git name-rev --refs=refs/tags/v2.6\*
> > > 69a07f0b117a40fcc1a479358d8e1f41793617f2
> > > 69a07f0b117a40fcc1a4
On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > > > >
> > > > > With no_wb=1 the driver
On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> Uwe Kleine-König writes:
>
> > $ git name-rev --refs=refs/tags/v2.6\*
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2 tags/v2.6.39-rc2~3^2~43^2~4
> >
> > so it was introduced just before -
Hi,
Commit b987812b3fc "powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP."
breaks compilation on non SMP powerpc machines.
I wonder if this commit is really neccessary in the first place. The
function definition itself is already between an
#ifdef CONFIG_SMP (line 56)
#endif
block so only exi
On Wed, Apr 13, 2011 at 06:16:13PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
> >
> > Well, X is dead, or rather in an infinite ioctl loop as described
> > above.
> > IIRC, the display enters a power-down mode and there is nothing to
> > see.
>
Felix,
On Tue, Apr 12, 2011 at 6:54 AM, Felix Radensky wrote:
> On 04/12/2011 07:05 AM, Aggrwal Poonam-B10812 wrote:
>> As such there is no hardware fix related to this issue between RevC to
>> RevD. The solution was a software patch to resolve the issue related to
>> IRQ0.
>
> Are you sure ? Ple
Uwe Kleine-König writes:
> $ git name-rev --refs=refs/tags/v2.6\*
> 69a07f0b117a40fcc1a479358d8e1f41793617f2
> 69a07f0b117a40fcc1a479358d8e1f41793617f2 tags/v2.6.39-rc2~3^2~43^2~4
>
> so it was introduced just before -rc2.
$ git tag --contains 69a07f0b117a40fcc1a479358d8e1f41793617f2
v2.6.39-rc
On Wed, 2011-04-13 at 10:16 +0200, Mikael Pettersson wrote:
> > Ok so on a PowerMac7,3 here (dual 2.5Ghz and mostly same HW or at least
> > very similar) I can't reproduce your problem with a g5_defconfig.
> >
> > Your config doesn't work well for me (I don't do modules, I netboot),
> > but a
Benjamin Herrenschmidt writes:
>
> > > Finally I tried using g5_defconfig with 2.6.39-rc3. First boot
> > > it did get to /sbin/init, but udev init took much longer than
> > > normal and threw errors. After a warm reboot the same kernel
> > > hung as usual, this time before framebuffer init
On Wed, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:
>
> Well, X is dead, or rather in an infinite ioctl loop as described
> above.
> IIRC, the display enters a power-down mode and there is nothing to
> see.
So basically the card crashed. There's about an infinite amount of
reasons why radeo
On Wed, Apr 13, 2011 at 10:02:04AM +0200, Gabriel Paubert wrote:
> On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > BTW, if your kernel contains commit
> > 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
> > helps?
>
> My kernel is pristine 2.6.38 and does
On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> BTW, if your kernel contains commit
> 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that
> helps?
My kernel is pristine 2.6.38 and does not include this commit
(was introduced before 2.6.39-rc1 according to gitk)
On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote:
> On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote:
> > > >
> > > > With no_wb=1 the driver goes a bit further but the X server ends
> > > > up in an infinite i
39 matches
Mail list logo
