Re: Help needed in debugging the crash of kernel stack overflow
On May 22, 2008, at 8:08 AM, sandeep malik wrote: Hi, We are using MSC7120 (e300 based) board running Montavista Linux 2.4. We are observing a random crash with the following dump: Kernel stack overflow in process c5b22000, r1=c5b22460 NIP: XER: 2000 LR: SP: C5B22460 REGS: c5b223b0 TRAP: 0400Tainted: P MSR: 20001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c5b22000[175] 'insmod' Last syscall: -1 last math last altivec GPR00: C5B22460 C5B22000 C5B22470 20001032 GPR08: F700 0008 0001 24224482 1033BB30 GPR16: 0001 1032 05B22460 GPR24: 0200 C7B09400 C016A240 C5B23D80 0010 C7B09400 Call backtrace: 70536574 34205220 5551 5551 494C450A 66363531 4F4E455F 35382054 38383053 20542056 43686563 53797353 35632052 70383830 74205670 0A636230 436D640A 38383053 24108028 C5C740C8 C00059AC Kernel panic: kernel stack overflow In interrupt handler - not syncing Any idea what might be going wrong or how to approach this problem as it is not getting reproduced and the behaviour is very random. Any pointers will be helpful. You really need to take these up with MontaVista. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [POWERPC] Fix return value check logic
debugfs_create_file() return a non-NULL (non-zero) value in case of success
This fixes this non-critical boot-time debuging error message:
[1.316386] calling irq_debugfs_init+0x0/0x50
[1.316399] initcall irq_debugfs_init+0x0/0x50 returned -12 after 0 msecs
[1.316411] initcall irq_debugfs_init+0x0/0x50 returned with error code -12
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
$ scripts/checkpatch.pl 0001--POWERPC-Fix-return-value-check-logic.patch
total: 0 errors, 0 warnings, 8 lines checked
0001--POWERPC-Fix-return-value-check-logic.patch has no obvious style problems
and is ready for submission.
arch/powerpc/kernel/irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 2f73f70..bcc249d 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1073,7 +1073,7 @@ static const struct file_operations virq_debug_fops = {
static int __init irq_debugfs_init(void)
{
if (debugfs_create_file(virq_mapping, S_IRUGO, powerpc_debugfs_root,
-NULL, virq_debug_fops))
+NULL, virq_debug_fops) == NULL)
return -ENOMEM;
return 0;
--
1.5.5.GIT
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Question about native compiling
Hi all, I apologize if the list finds this off topic, but I'm at a loss of who to ask the question and thought this would be a good place to start. Our target is an MPC8347E PowerQUICC II Pro, and we're using the latest kernel (2.6.25). We started this project by building on x86 and doing cross-compiling to the powerpc target. As the project progressed and we started adding applications we found that we couldn't cross-compile postgress among other things. So we switched to native compilation on the target. Problem is, it's extreamly slow. Now our idea is to get our hands on a PowerPC based Mac, load it up with Ubuntu and do native builds on that. The question is, which Mac to get? The concern is this: a G5 is 64-bit but the 8347E is 32-bit. If we do our compiles on a G5 is it really a 'native' compile or is it a cross-compile and we're back in the same boat as we were with the x86? Should we use a G4 instead? Thanks for any advice or pointers to other places where I can find information. Bruce ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Question about native compiling
[EMAIL PROTECTED] wrote: Hi all, I apologize if the list finds this off topic, but I'm at a loss of who to ask the question and thought this would be a good place to start. Our target is an MPC8347E PowerQUICC II Pro, and we're using the latest kernel (2.6.25). We started this project by building on x86 and doing cross-compiling to the powerpc target. As the project progressed and we started adding applications we found that we couldn't cross-compile postgress among other things. So we switched to native compilation on the target. Problem is, it's extreamly slow. Now our idea is to get our hands on a PowerPC based Mac, load it up with Ubuntu and do native builds on that. The question is, which Mac to get? The concern is this: a G5 is 64-bit but the 8347E is 32-bit. If we do our compiles on a G5 is it really a 'native' compile or is it a cross-compile and we're back in the same boat as we were with the x86? Should we use a G4 instead? Thanks for any advice or pointers to other places where I can find information. We use a dual G5 to do the exact same thing. We have a compiler buildt on our target board (Freescale 8280), and on the G5 we make sure that this compiler is being used (by chrooting into a copy of the filesystem used on the target). Then we compile all our apps . Only thing we have to do speciial, is to add --build=powerpc-unknown-linux-gnu --host=powerpc-unknown-linux-gnu to the ./configure cammand line. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] [POWERPC] Add the PC speaker only when requested so
This will cause this minor boot-time debugging error message to go away:
[1.316451] calling add_pcspkr+0x0/0x84
[1.316478] initcall add_pcspkr+0x0/0x84 returned -19 after 0 msecs
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
scripts/checkpatch.pl
0001--POWERPC-Add-the-PC-speaker-only-when-requested-so.patch
total: 0 errors, 0 warnings, 14 lines checked
0001--POWERPC-Add-the-PC-speaker-only-when-requested-so.patch has no obvious
style problems and is ready for submission.
arch/powerpc/kernel/setup-common.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index db540ea..61a3f41 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -500,6 +500,7 @@ void __init smp_setup_cpu_sibling_map(void)
}
#endif /* CONFIG_SMP */
+#ifdef CONFIG_PCSPKR_PLATFORM
static __init int add_pcspkr(void)
{
struct device_node *np;
@@ -522,6 +523,7 @@ static __init int add_pcspkr(void)
return ret;
}
device_initcall(add_pcspkr);
+#endif /* CONFIG_PCSPKR_PLATFORM */
void probe_machine(void)
{
--
1.5.5.GIT
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
APU FPU in Virtex ppc405
Were the issues associated with getting the Xilinx Floating point APU working with Linux completely resolved ? Is there a git tree or patch collection with the appropriate patches etc ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: APU FPU in Virtex ppc405
On Thu, May 22, 2008 at 5:06 PM, David H. Lynch Jr. [EMAIL PROTECTED] wrote: Were the issues associated with getting the Xilinx Floating point APU working with Linux completely resolved ? Is there a git tree or patch collection with the appropriate patches etc ? I had it working at one point ages ago, but that project ended up dropping the work and I haven't touched it since. I think I posted the patches but I don't have a link to them easily at hand. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Add the PC speaker only when requested so
On Thu, May 22, 2008 at 4:40 PM, Emil Medve [EMAIL PROTECTED] wrote:
This will cause this minor boot-time debugging error message to go away:
[1.316451] calling add_pcspkr+0x0/0x84
[1.316478] initcall add_pcspkr+0x0/0x84 returned -19 after 0 msecs
What situation are you hitting this in? The code should only run if
there is a pnpPNP,100 compatible node in the device tree.
Also, where is CONFIG_PCSPKR_PLATFORM defined? I don't see it
anywhere in powerpc code and only a reference to it in an x86
Makefile. As it stands, it looks like this patch unconditionally
disables the pcspkr code.
Cheers,
g.
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
scripts/checkpatch.pl
0001--POWERPC-Add-the-PC-speaker-only-when-requested-so.patch
total: 0 errors, 0 warnings, 14 lines checked
0001--POWERPC-Add-the-PC-speaker-only-when-requested-so.patch has no obvious
style problems and is ready for submission.
arch/powerpc/kernel/setup-common.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index db540ea..61a3f41 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -500,6 +500,7 @@ void __init smp_setup_cpu_sibling_map(void)
}
#endif /* CONFIG_SMP */
+#ifdef CONFIG_PCSPKR_PLATFORM
static __init int add_pcspkr(void)
{
struct device_node *np;
@@ -522,6 +523,7 @@ static __init int add_pcspkr(void)
return ret;
}
device_initcall(add_pcspkr);
+#endif /* CONFIG_PCSPKR_PLATFORM */
void probe_machine(void)
{
--
1.5.5.GIT
___
Linuxppc-dev mailing list
[EMAIL PROTECTED]
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: APU FPU in Virtex ppc405
Yes, it's working under Linux. Just do as John, Steve, and Yoshio suggest. That should work then. My problem was that our own cross- tool was not working correctly. But we will fix it in next couple of weeks. I did very primitive changes and didn't have a patch. In next few weeks we might want to go for powerpc tree then, so I will try to do it all over again. Shan On May 22, 2008, at 7:06 PM, David H. Lynch Jr. wrote: Were the issues associated with getting the Xilinx Floating point APU working with Linux completely resolved ? Is there a git tree or patch collection with the appropriate patches etc ? -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: APU FPU in Virtex ppc405
My understanding is that with the fpu on the ppc405 (not ppc440), the processor clock rate had to be reduced for the fpu to work. This ended up negating much of the performance benefits of using the fpu. I don't know the specifics offhand, but Xilinx answer records can be searched. Hopefully I'm wrong, and there can still be a benefit to using the ppc405 fpu. - John On Thu, 2008-05-22 at 19:06 -0400, David H. Lynch Jr. wrote: Were the issues associated with getting the Xilinx Floating point APU working with Linux completely resolved ? Is there a git tree or patch collection with the appropriate patches etc ? John Bonesio Commercial Linux Solutions [EMAIL PROTECTED] (408) 879-5569 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Fix return value check logic
On Thu, 2008-05-22 at 14:49 -0500, Emil Medve wrote:
debugfs_create_file() return a non-NULL (non-zero) value in case of success
This fixes this non-critical boot-time debuging error message:
[1.316386] calling irq_debugfs_init+0x0/0x50
[1.316399] initcall irq_debugfs_init+0x0/0x50 returned -12 after 0 msecs
[1.316411] initcall irq_debugfs_init+0x0/0x50 returned with error code -12
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
$ scripts/checkpatch.pl 0001--POWERPC-Fix-return-value-check-logic.patch
total: 0 errors, 0 warnings, 8 lines checked
0001--POWERPC-Fix-return-value-check-logic.patch has no obvious style
problems and is ready for submission.
arch/powerpc/kernel/irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 2f73f70..bcc249d 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1073,7 +1073,7 @@ static const struct file_operations virq_debug_fops = {
static int __init irq_debugfs_init(void)
{
if (debugfs_create_file(virq_mapping, S_IRUGO, powerpc_debugfs_root,
- NULL, virq_debug_fops))
+ NULL, virq_debug_fops) == NULL)
return -ENOMEM;
That won't work if CONFIG_DEBUG_FS is not defined, because in that case
debugfs_create_file() returns -ENODEV. I guess the whole virq debug code
should be wrapped in #ifdef CONFIG_DEBUG_FS.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: APU FPU in Virtex ppc405
Shan and I are going to sit down and rebuild our tool chain (a mix of crosstool, linux-from-scratch, and Xilinx patches) next week. Our aim is to quantify the gains/losses of frequency versus hardware acceleration since we have several large scientific apps we plan to run. Like he said, we're hoping to have a handle on the best approach over the next couple of weeks. Ron My understanding is that with the fpu on the ppc405 (not ppc440), the processor clock rate had to be reduced for the fpu to work. This ended up negating much of the performance benefits of using the fpu. I don't know the specifics offhand, but Xilinx answer records can be searched. Hopefully I'm wrong, and there can still be a benefit to using the ppc405 fpu. - John On Thu, 2008-05-22 at 19:06 -0400, David H. Lynch Jr. wrote: Were the issues associated with getting the Xilinx Floating point APU working with Linux completely resolved ? Is there a git tree or patch collection with the appropriate patches etc ? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Add the PC speaker only when requested so
On May 22, 2008, at 6:27 PM, Grant Likely wrote: On Thu, May 22, 2008 at 4:40 PM, Emil Medve [EMAIL PROTECTED] wrote: This will cause this minor boot-time debugging error message to go away: [1.316451] calling add_pcspkr+0x0/0x84 [1.316478] initcall add_pcspkr+0x0/0x84 returned -19 after 0 msecs What situation are you hitting this in? The code should only run if there is a pnpPNP,100 compatible node in the device tree. The code always runs, the -19 is from the fact that the code returns - ENODEV when it doesn't find the device in the tree. I don't see any reason we should be ALWAYS be probing for a PC speaker. Seems like a reasonable patch. Also, where is CONFIG_PCSPKR_PLATFORM defined? I don't see it anywhere in powerpc code and only a reference to it in an x86 Makefile. As it stands, it looks like this patch unconditionally disables the pcspkr code. Its defined in init/Kconfig. - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [POWERPC] Add the PC speaker only when requested so
On Thu, May 22, 2008 at 9:34 PM, Kumar Gala [EMAIL PROTECTED] wrote: On May 22, 2008, at 6:27 PM, Grant Likely wrote: On Thu, May 22, 2008 at 4:40 PM, Emil Medve [EMAIL PROTECTED] wrote: This will cause this minor boot-time debugging error message to go away: [1.316451] calling add_pcspkr+0x0/0x84 [1.316478] initcall add_pcspkr+0x0/0x84 returned -19 after 0 msecs What situation are you hitting this in? The code should only run if there is a pnpPNP,100 compatible node in the device tree. The code always runs, the -19 is from the fact that the code returns -ENODEV when it doesn't find the device in the tree. I don't see any reason we should be ALWAYS be probing for a PC speaker. Seems like a reasonable patch. Fair enough; I was just wondering if it was a complete fix. But now that I dig into the code I see that the calling...initcall returned... messages are just debug stuff that isn't always turned on. I have no problem with the patch. Also, where is CONFIG_PCSPKR_PLATFORM defined? I don't see it anywhere in powerpc code and only a reference to it in an x86 Makefile. As it stands, it looks like this patch unconditionally disables the pcspkr code. Its defined in init/Kconfig. Apparently my grep-foo isn't what it used to be... Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
