* [PATCH v2] powerpc: align DTL buffer to AMS boundary
From: Nishanth Aravamudan @ 2011-04-13 22:33 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1302706373-11653-1-git-send-email-nacc@us.ibm.com>
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 least in my understanding). Over-allocate and align
the resulting address. Tested both with and without AMS on a p7
partition.
---
Change from v1: removed extraneous #include.
Note, I initially put this in a firmware check if-block, but we have
also seen some issues with alignment with non-AMS partitions. The wasted
memory is unfortunate, though.
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
arch/powerpc/platforms/pseries/setup.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..a67be48 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -293,14 +293,15 @@ static int alloc_dispatch_logs(void)
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
- dtl = kmalloc_node(DISPATCH_LOG_BYTES, GFP_KERNEL,
- cpu_to_node(cpu));
+ dtl = kmalloc_node(DISPATCH_LOG_BYTES + DISPATCH_LOG_BYTES - 1,
+ GFP_KERNEL, cpu_to_node(cpu));
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
pr_warn("Stolen time statistics will be unreliable\n");
break;
}
+ dtl = PTR_ALIGN(dtl, DISPATCH_LOG_BYTES);
pp->dtl_ridx = 0;
pp->dispatch_log = dtl;
--
1.7.4.1
^ permalink raw reply related
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Andy Furniss @ 2011-04-13 20:01 UTC (permalink / raw)
To: Michel Dänzer
Cc: KH, LKML, dri-devel, Greg, Uwe Kleine-König, linuxppc-dev
In-Reply-To: <1302704124.15520.72.camel@thor.local>
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
> -dumbSched to see if that gets things along any further, but in the end
> there's probably no way around figuring out what causes the lockup and
> fixing that anyway.
I have an old AGP box that locks with 600g + agpgart - It used to give
GPU lockup to dmesg/log, but (I only test it occasionally) it doesn't
anymore. I can still sysrq OK.
I wonder if something changed in recent months in the drm/whatever code
that has changed/blocked the logging.
^ permalink raw reply
* Re: Powerpc compile error with 2.6.39-rc3 and non-SMP configs
From: Paul Gortmaker @ 2011-04-13 15:45 UTC (permalink / raw)
To: Michael Guntsche; +Cc: linuxppc-dev
In-Reply-To: <20110413101737.GA25514@gibson.comsick.at>
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 place. The
> function definition itself is already between an
Your analysis is right, but I think getting rid of the #ifdefs is
still the right approach where possible. I'll send a fix shortly.
Thanks for the report.
P.
>
> #ifdef CONFIG_SMP (line 56)
> #endif
>
> block so only exists if SMP=y and PPC_STD_MMU_64=y.
> Furthermore the stub in your patch is only created if SMP=y and
> PPC_STD_MMU_64=n which breaks non-SMP configs.
>
> Kind regards,
> Michael Guntsche
^ permalink raw reply
* Re: PowerMacintosh B&W G4 boot failure - linux-2.6.36.x
From: acrux @ 2011-04-13 18:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nello M
In-Reply-To: <BANLkTikwJ81ZxtHoJOpu_OW8bCcPTm8F9w@mail.gmail.com>
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 <acrux_it@libero.it>
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: kevin diggs @ 2011-04-13 17:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Mikael Pettersson, linuxppc-dev, linux-kernel
In-Reply-To: <1302685102.28876.81.camel@pasglop>
HI,
On Wed, Apr 13, 2011 at 3:58 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> 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 though.
>
In this context, what does 'crash' mean? The X thingy goes down? Or
the whole OS?
Cheers,
kevin.
> Cheers,
> Ben.
^ permalink raw reply
* [PATCH] powerpc/kexec: fix regression causing compile failure on UP
From: Paul Gortmaker @ 2011-04-13 16:30 UTC (permalink / raw)
To: benh; +Cc: Paul Gortmaker, mike, linuxppc-dev
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
and also annotate the relevant else/endif so that nobody
else falls into the same trap I did.
Reported-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
** compile tested on both UP & SMP this time! **
arch/powerpc/kernel/crash.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 3d3d416..5b5e1f0 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,7 +163,7 @@ static void crash_kexec_prepare_cpus(int cpu)
}
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
-#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
+#ifdef CONFIG_PPC_STD_MMU_64
static void crash_kexec_wait_realmode(int cpu)
{
unsigned int msecs;
@@ -188,9 +188,7 @@ static void crash_kexec_wait_realmode(int cpu)
}
mb();
}
-#else
-static inline void crash_kexec_wait_realmode(int cpu) {}
-#endif
+#endif /* CONFIG_PPC_STD_MMU_64 */
/*
* This function will be called by secondary cpus or by kexec cpu
@@ -235,7 +233,9 @@ void crash_kexec_secondary(struct pt_regs *regs)
crash_ipi_callback(regs);
}
-#else
+#else /* ! CONFIG_SMP */
+static inline void crash_kexec_wait_realmode(int cpu) {}
+
static void crash_kexec_prepare_cpus(int cpu)
{
/*
@@ -255,7 +255,7 @@ void crash_kexec_secondary(struct pt_regs *regs)
{
cpus_in_sr = CPU_MASK_NONE;
}
-#endif
+#endif /* CONFIG_SMP */
/*
* Register a function to be called on shutdown. Only use this if you
--
1.7.3.3
^ permalink raw reply related
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-13 15:38 UTC (permalink / raw)
To: Stefan Roese; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <201104131721.34123.ml@stefan-roese.de>
Stefan Roese <ml@stefan-roese.de> 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()).
> > >
> > > Before digging deeper: Has anybody tried/tested ftrace on MPC8xx? Any
> > > ideas what going wrong here?
> >
> > Just an idea, remove the usage of dcbX insn, these has been problematic
> > before.
>
> I originally tested with 2.6.32. Same problem there. And your 8xx patches with
> the dcbX changes are not included in 2.6.32 yet.
OK
>
> > How big was the size to copy_tofrom_user()? Did it mange to copy
> > any bytes?
>
> The size in __copy_tofrom_user is 4. And its the first call in
> ftrace_modify_code() that fails directly. This works just fine on a PPC440EPx
> board.
Since the size is only 4 it would not use dcbX anyway(I think).
Then is is probably called with the wrong addresses?
Jocke
^ permalink raw reply
* Re: PowerMacintosh B&W G4 boot failure - linux-2.6.36.x
From: nello martuscielli @ 2011-04-13 15:32 UTC (permalink / raw)
To: linuxppc-dev
could it be the same issue i've on my old Pegasos1 G3 ??
regards,
Nello
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Stefan Roese @ 2011-04-13 15:21 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF32A80193.EF3E454E-ONC1257871.005204A6-C1257871.00523F24@transmode.se>
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 MPC8xx? Any
> > ideas what going wrong here?
>
> Just an idea, remove the usage of dcbX insn, these has been problematic
> before.
I originally tested with 2.6.32. Same problem there. And your 8xx patches with
the dcbX changes are not included in 2.6.32 yet.
> How big was the size to copy_tofrom_user()? Did it mange to copy
> any bytes?
The size in __copy_tofrom_user is 4. And its the first call in
ftrace_modify_code() that fails directly. This works just fine on a PPC440EPx
board.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] powerpc: align DTL buffer to AMS boundary
From: Nishanth Aravamudan @ 2011-04-13 15:15 UTC (permalink / raw)
To: David Laight; +Cc: linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8ACF4@saturn3.aculab.com>
On 13.04.2011 [15:59:44 +0100], David Laight wrote:
> > From:
> > linuxppc-dev-bounces+david.laight=aculab.com@lists.ozlabs.org
> > [mailto:linuxppc-dev-bounces+david.laight=aculab.com@lists.ozl
> > abs.org] On Behalf Of Nishanth Aravamudan
> > Sent: 13 April 2011 15:53
> > To: Ben Herrenschmidt
> > Cc: linuxppc-dev@ozlabs.org; Paul Mackerras; Anton Blanchard
> > Subject: [PATCH] powerpc: align DTL buffer to AMS boundary
> >
> > 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)....
>
> How big is the buffer being allocated?
> If it is much less than 4k then it might be worth allocating
> a buffer of the correct size, and only if that crosses a 4k boundary
> allocate the larger buffer.
Currently, DISPATCH_LOG_BYTES is 4k (which I assume was actually in
deference to this requirement).
> Also, if the buffer is ever freed, the actual base address is needed
> for the free.
I didn't see any free patch for this sequence of code -- which make
sense as this allocation occurs under a for_each_possible_cpu loop.
Thanks for the feedback,
Nish
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-13 14:58 UTC (permalink / raw)
To: Stefan Roese; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <201104131632.21350.ml@stefan-roese.de>
Stefan Roese <ml@stefan-roese.de> 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 ]------------
> [ 0.038760] WARNING: at kernel/trace/ftrace.c:1014
> [ 0.038889] Modules linked in:
> [ 0.039062] NIP: c00666a0 LR: c006782c CTR: 00000001
> [ 0.039249] REGS: c0381e60 TRAP: 0700 Not tainted (2.6.38-default+)
> [ 0.039417] MSR: 00021032 <ME,CE,IR,DR> CR: 53009393 XER: a000af7f
> [ 0.039856] TASK = c0360500[0] 'swapper' THREAD: c0380000
> [ 0.040001] GPR00: 00000001 c0381f10 c0360500 ffffffff c02962c8 00000000
> c02962c4 00000000
> [ 0.040487] GPR08: 1de1a3e3 00000000 000258e3 c0381f40 93009399 10091a60
> 03fff800 0040055c
> [ 0.040977] GPR16: 00000001 00000001 ffffffff 007fff00 03ff9fb0 00000000
> 00000000 c0384080
> [ 0.041459] GPR24: c000f234 00000000 024acd00 00009032 c02962c8 c384553c
> c02962c8 c0381f10
> [ 0.042054] NIP [c00666a0] ftrace_bug+0x13c/0x1c4
> [ 0.042268] LR [c006782c] ftrace_process_locs+0x1b4/0x2b0
> [ 0.042405] Call Trace:
> [ 0.042592] [c0381f10] [c006fce8] ftrace_now+0x30/0x78 (unreliable)
> [ 0.042889] [c0381f40] [c006782c] ftrace_process_locs+0x1b4/0x2b0
> [ 0.043182] [c0381f70] [c0339944] ftrace_init+0x1e8/0x21c
> [ 0.043443] [c0381fb0] [c0333964] start_kernel+0x284/0x2a0
> [ 0.043704] [c0381ff0] [c0002224] start_here+0x44/0xa8
> [ 0.043869] Instruction dump:
> [ 0.044013] 2f9e0003 7f1ed800 3bbd0001 7f44d378 409dffc8 3c60c02f 3863101c
> 4bfbbbb9
> [ 0.044508] 48000080 3d20c04b 8929bc82 69200001 <0f000000> 2f890000
> 40be0010 38000001
> [ 0.045206] ---[ end trace 31fd0ba7d8756001 ]---
> [ 0.045349] ftrace faulted on writing [<c02962c8>] dns_query+0x8/0x278
> ...
>
>
> 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 MPC8xx? Any ideas
> what going wrong here?
Just an idea, remove the usage of dcbX insn, these has been problematic before.
How big was the size to copy_tofrom_user()? Did it mange to copy any bytes?
Jocke
^ permalink raw reply
* Re: [PATCH] powerpc: align DTL buffer to AMS boundary
From: David Laight @ 2011-04-13 14:59 UTC (permalink / raw)
To: linuxppc-dev
> From:=20
> linuxppc-dev-bounces+david.laight=3Daculab.com@lists.ozlabs.org=20
> [mailto:linuxppc-dev-bounces+david.laight=3Daculab.com@lists.ozl
> abs.org] On Behalf Of Nishanth Aravamudan
> Sent: 13 April 2011 15:53
> To: Ben Herrenschmidt
> Cc: linuxppc-dev@ozlabs.org; Paul Mackerras; Anton Blanchard
> Subject: [PATCH] powerpc: align DTL buffer to AMS boundary
>=20
> 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)....
How big is the buffer being allocated?
If it is much less than 4k then it might be worth allocating
a buffer of the correct size, and only if that crosses a 4k boundary
allocate the larger buffer.
Also, if the buffer is ever freed, the actual base address is needed
for the free.
David
^ permalink raw reply
* [PATCH] powerpc: align DTL buffer to AMS boundary
From: Nishanth Aravamudan @ 2011-04-13 14:52 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev, 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 least in my understanding). Over-allocate and align
the resulting address. Tested both with and without AMS on a p7
partition.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
Note, I initially put this in a firmware check if-block, but we have
also seen some issues with alignment with non-AMS partitions. The wasted
memory is unfortunate, though.
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@ozlabs.org
arch/powerpc/platforms/pseries/setup.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..7df5ddb 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -39,6 +39,7 @@
#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
+#include <linux/memblock.h>
#include <asm/mmu.h>
#include <asm/processor.h>
@@ -293,14 +294,15 @@ static int alloc_dispatch_logs(void)
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
- dtl = kmalloc_node(DISPATCH_LOG_BYTES, GFP_KERNEL,
- cpu_to_node(cpu));
+ dtl = kmalloc_node(DISPATCH_LOG_BYTES + DISPATCH_LOG_BYTES - 1,
+ GFP_KERNEL, cpu_to_node(cpu));
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
pr_warn("Stolen time statistics will be unreliable\n");
break;
}
+ dtl = PTR_ALIGN(dtl, DISPATCH_LOG_BYTES);
pp->dtl_ridx = 0;
pp->dispatch_log = dtl;
--
1.7.4.1
^ permalink raw reply related
* FTrace on MPC8xx
From: Stefan Roese @ 2011-04-13 14:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
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:1014
[ 0.038889] Modules linked in:
[ 0.039062] NIP: c00666a0 LR: c006782c CTR: 00000001
[ 0.039249] REGS: c0381e60 TRAP: 0700 Not tainted (2.6.38-default+)
[ 0.039417] MSR: 00021032 <ME,CE,IR,DR> CR: 53009393 XER: a000af7f
[ 0.039856] TASK = c0360500[0] 'swapper' THREAD: c0380000
[ 0.040001] GPR00: 00000001 c0381f10 c0360500 ffffffff c02962c8 00000000
c02962c4 00000000
[ 0.040487] GPR08: 1de1a3e3 00000000 000258e3 c0381f40 93009399 10091a60
03fff800 0040055c
[ 0.040977] GPR16: 00000001 00000001 ffffffff 007fff00 03ff9fb0 00000000
00000000 c0384080
[ 0.041459] GPR24: c000f234 00000000 024acd00 00009032 c02962c8 c384553c
c02962c8 c0381f10
[ 0.042054] NIP [c00666a0] ftrace_bug+0x13c/0x1c4
[ 0.042268] LR [c006782c] ftrace_process_locs+0x1b4/0x2b0
[ 0.042405] Call Trace:
[ 0.042592] [c0381f10] [c006fce8] ftrace_now+0x30/0x78 (unreliable)
[ 0.042889] [c0381f40] [c006782c] ftrace_process_locs+0x1b4/0x2b0
[ 0.043182] [c0381f70] [c0339944] ftrace_init+0x1e8/0x21c
[ 0.043443] [c0381fb0] [c0333964] start_kernel+0x284/0x2a0
[ 0.043704] [c0381ff0] [c0002224] start_here+0x44/0xa8
[ 0.043869] Instruction dump:
[ 0.044013] 2f9e0003 7f1ed800 3bbd0001 7f44d378 409dffc8 3c60c02f 3863101c
4bfbbbb9
[ 0.044508] 48000080 3d20c04b 8929bc82 69200001 <0f000000> 2f890000
40be0010 38000001
[ 0.045206] ---[ end trace 31fd0ba7d8756001 ]---
[ 0.045349] ftrace faulted on writing [<c02962c8>] dns_query+0x8/0x278
...
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 MPC8xx? Any ideas
what going wrong here?
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Michel Dänzer @ 2011-04-13 14:15 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Uwe Kleine-König,
Dave Airlie
In-Reply-To: <20110413122751.GA21050@iram.es>
On Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote:=20
> On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel D=C3=A4nzer wrote:
> > On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:=20
> > > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D=C3=A4nzer 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=C3=A4nzer wrot=
e:
> > > > > > >=20
> > > > > > > With no_wb=3D1 the driver goes a bit further but the X server=
ends
> > > > > > > up in an infinite ioctl loop and the logs are:=20
> > > > > >=20
> > > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file=
as well.
> > > > >=20
> > > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE=
.
> > > >=20
> > > > Note that it's normal for this ioctl to be called every time before=
the
> > > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioc=
tl
> > > > always returns an error, this may not indicate a problem on its own=
.=20
> > >=20
> > > It seems to be an infinite loop, always returning EINTR because
> > > of regular SIGALRM delivery.
> >=20
> > 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?
>=20
> No.
Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
-dumbSched to see if that gets things along any further, but in the end
there's probably no way around figuring out what causes the lockup and
fixing that anyway.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add an ePAPR compliant boot wrapper
From: Josh Boyer @ 2011-04-13 13:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <732a8ac3a24023f021908d03bd84b76638f381f1.1302676893.git.michael@ellerman.id.au>
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 <david@gibson.dropbear.id.au>, IBM Corporation.
>+ *
>+ * Based on earlier bootwrappers by:
>+ * (c) Benjamin Herrenschmidt <benh@kernel.crashing.org>, IBM Corp,\
>+ * and
>+ * Scott Wood <scottwood@freescale.com>
>+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
>+ *
>+ * This program is free software; you can redistribute it and/or modify it
>+ * under the terms of the GNU General Public License version 2 as published
>+ * by the Free Software Foundation.
>+ */
>+
>+#include "ops.h"
>+#include "stdio.h"
>+#include "planetcore.h"
>+#include "dcr.h"
>+#include "4xx.h"
>+#include "io.h"
Do you need planetcore, dcr, and 4xx.h included here? I don't see
anything used that would require them.
josh
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Gabriel Paubert @ 2011-04-13 12:27 UTC (permalink / raw)
To: Michel Dänzer
Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Uwe Kleine-König,
Dave Airlie
In-Reply-To: <1302696736.15520.63.camel@thor.local>
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 +0200, Michel Dänzer wrote:
> > > > > >
> > > > > > With no_wb=1 the driver goes a bit further but the X server ends
> > > > > > up in an infinite ioctl loop and the logs are:
> > > > >
> > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file as well.
> > > >
> > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> > >
> > > Note that it's normal for this ioctl to be called every time before the
> > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > > always returns an error, this may not indicate a problem on its own.
> >
> > It seems to be an infinite loop, always returning EINTR because
> > of regular SIGALRM delivery.
>
> 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.
Gabriel
^ permalink raw reply
* Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]
From: Uwe Kleine-König @ 2011-04-13 12:17 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Andreas Schwab,
Dave Airlie
In-Reply-To: <20110413103144.GB3066@iram.es>
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 <u.kleine-koenig@pengutronix.de> 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-rc1
> > v2.6.39-rc2
> >
>
> So who is right? I think it was before rc1.
Yep, correct. I interpreted the output of git name-rev to mean it's not
included in a tag earlier than v2.6.39-rc2, but actually that's wrong.
It's just that it's easier (for some definition of easy) to reach the
commit in question from v2.6.39-rc2 than from v2.6.39-rc1.
> However in this case the main reason to fire gitk was to have a quick look
> at the patch and its context, and simply reported the "Precedes" line
> in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
> that it has been quite a long time outside the main tree.
I think this conclusion isn't valid in general. (E.g. in git itself a
bug-fix is often done on top of the commit that introduced it and than
merged into master. Still the bugfix might be new.) But looking at the
AuthorDate of 69a07f0b117a seems to support your statement.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Michel Dänzer @ 2011-04-13 12:12 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Uwe Kleine-König,
Dave Airlie
In-Reply-To: <20110413075943.GA27996@iram.es>
On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:=20
> On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D=C3=A4nzer 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=C3=A4nzer wrote:
> > > > >=20
> > > > > With no_wb=3D1 the driver goes a bit further but the X server end=
s
> > > > > up in an infinite ioctl loop and the logs are:=20
> > > >=20
> > > > Which ioctl does it loop on? Please provide the Xorg.0.log file as =
well.
> > >=20
> > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE.
> >=20
> > Note that it's normal for this ioctl to be called every time before the
> > GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl
> > always returns an error, this may not indicate a problem on its own.=
=20
>=20
> It seems to be an infinite loop, always returning EINTR because
> of regular SIGALRM delivery.
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?
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]
From: Gabriel Paubert @ 2011-04-13 10:31 UTC (permalink / raw)
To: Andreas Schwab
Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Uwe Kleine-König,
Dave Airlie
In-Reply-To: <m339lm8r31.fsf@redhat.com>
On Wed, Apr 13, 2011 at 10:59:14AM +0200, Andreas Schwab wrote:
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 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-rc1
> v2.6.39-rc2
>
So who is right? I think it was before rc1.
Anyway I'm aware that there are other git commands, although for the option
details I often have to have a look at the man page.
However in this case the main reason to fire gitk was to have a quick look
at the patch and its context, and simply reported the "Precedes" line
in the display, which is 2.6.39-rc1. It also follow v2.6.37-rc2, which means
that it has been quite a long time outside the main tree.
Gabriel
^ permalink raw reply
* Powerpc compile error with 2.6.39-rc3 and non-SMP configs
From: Michael Guntsche @ 2011-04-13 10:17 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
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 exists if SMP=y and PPC_STD_MMU_64=y.
Furthermore the stub in your patch is only created if SMP=y and
PPC_STD_MMU_64=n which breaks non-SMP configs.
Kind regards,
Michael Guntsche
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Gabriel Paubert @ 2011-04-13 10:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Greg KH, LKML, dri-devel, Uwe Kleine-König, Dave Airlie,
linuxppc-dev
In-Reply-To: <1302682573.28876.78.camel@pasglop>
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.
>
> So basically the card crashed. There's about an infinite amount of
> reasons why radeons do so, sometimes it has to do with them not liking
> what you ate that day...
>
> The only thing I can see that could be of use would be a bisect
Bisecting for something which I have never got to work (radeon with
KMS) on this machine is something I don't know how to do...
Note that radeon without KMS also always ends up crashing, but it
may take hours. The only case where the machine works reliably is
when glxinfo claims that it is using software rendering.
Regards,
Gabriel
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Leon Woestenberg @ 2011-04-13 9:22 UTC (permalink / raw)
To: Felix Radensky
Cc: linuxppc-dev@ozlabs.org, Gupta Maneesh-B18878,
Aggrwal Poonam-B10812, Kushwaha Prabhakar-B32579
In-Reply-To: <4DA3DAF6.9090909@embedded-sol.com>
Felix,
On Tue, Apr 12, 2011 at 6:54 AM, Felix Radensky <felix@embedded-sol.com> 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 ? Please take a look at Freescale document titled
> "P1020E/P2020E RDB System Errata".
> There's errata CE10, IRQ0 held low. It is fixed in Rev D. Vivek Mahajan, who
> looked at the issue back
> in 2009, estimated that problem can be related to missing pull-up on IRQ0.
> This is exactly what is
> fixed in Rev D.
>
That's my understanding as well.
Check if R420 and R423 are populated. These are the required pull-ups.
On Rev D they are populated. You might be able to add them yourself.
Even if you have an Rev A-C PCB, this fix can already be applied; it
was on my board! (the bottom of the board mentions the schematic
revision)
The resistors have a silkscreen designator block called X, the
resistors are situated to the left and bottom of the silkscreen X.
IIRC, between the flash and Px020 part.
On the left side of R420 (or R423) I measured the block wave from the
RTC, which fires the 32kHz interrupt rate on IRQ0. This fixed by the
u-boot patch.
Regards,
Leon.
^ permalink raw reply
* Re: small git lesson [Was: Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?]
From: Andreas Schwab @ 2011-04-13 8:59 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Greg KH, linuxppc-dev, dri-devel, LKML, Dave Airlie
In-Reply-To: <20110413081246.GK18850__3180.67204575545$1302682420$gmane$org@pengutronix.de>
Uwe Kleine-K=C3=B6nig <u.kleine-koenig@pengutronix.de> writes:
> $ git name-rev --refs=3Drefs/tags/v2.6\* 69a07f0b117a40fcc1a479358d8e1f41=
793617f2
> 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-rc1
v2.6.39-rc2
Andreas.
--=20
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint =3D D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Benjamin Herrenschmidt @ 2011-04-13 8:58 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <19877.23529.745123.819112@pilspetsen.it.uu.se>
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 after adding a few things to it, it seems to work fine as well. I
> > added radeonfb and the radeon DRM (not KMS) and I added eventfd, timerfd
> > and input events.
> >
> > So I'm afraid I'm going to need you to bisect that one to find out what
> > exact change caused the breakage for you.
>
> Thanks for checking. I'll try a bisect later today.
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 though.
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox