* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-13 23:37 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071113220655.85840@gmx.net>
On Tue, 2007-11-13 at 23:06 +0100, Gerhard Pircher wrote:
> Well, I only disabled power saving with powersave=off. Are there any
> other
> ways to disable idle? What do you mean with instrumenting locks or
> irq enable/disable?
Add printk's to things :-) It's a UP kernel so there should be no
spinlocks anyway.
Best is to try to get a 100% reprocase and printk your way toward the
origin of the problem if you don't have a HW debugger. Unless you manage
to sneak in an irq to xmon but if you are totally locked up, you
probably can't.
Could also be something you do that your buggy northbridge doesn't like.
For example, maybe it dislikes M bit in the hash table and you end up
with it set due to other reasons (I know we had changes in this area).
> > Also, did you try booting with all kernel debug options enabled ?
> I compiled in almost all kernel debugging options and booted the
> kernel
> with driver_debug, initcall_debug and debug. I didn't notice any
> serious
> error messages so far. Not sure however, if I missed a debug option.
>
> > Finally, since the problem seem to have started around a specific
> kernel
> > version, can you try to bisect the patch that causes it ?
> Hmm, I'm not sure how to do this (only worked on platform code so
> far).
> I guess you think about checking out a kernel version from the git
> repository, which doesn't contain the patch for kernel_execve().
> I still suspect the kernel_execve() function (which was introduced in
> 2.6.17) because the kernel locks up after starting the first user
> program.
> AFAIK kernel threads should be running much earlier.
They are but they cause a lot less MMU pressure, could be an
indication...
Ben.
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Dan Malek @ 2007-11-13 23:23 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711131359l43f289e7j48b0df3ff57ea7c7@mail.gmail.com>
On Nov 13, 2007, at 1:59 PM, Grant Likely wrote:
>> Abatron BDI-2000.
>
> Oops, but that's not all that cheap. ($2750USD).
If you place any value on your time or development
schedule, it's a bargain. Just plug it in, and it works.
Choose any of your favorite debugger front ends,
from none with just a telnet interface, to remote gdb,
ddd, or several Eclipse options. Several choices
of host OS. It will pay you back in development and
debugging time savings over and over.
-- Dan
^ permalink raw reply
* [PATCH] powerpc: fix 2nd UCC entry in mpc832x_mds.dts
From: Kim Phillips @ 2007-11-13 23:26 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala
correct the reg property, remove duplicate io port entry, whitespace fixes.
Thanks to Peter Van Ackeren for pointing this out.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/boot/dts/mpc832x_mds.dts | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index fcd333c..eeafa8b 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -104,7 +104,7 @@
reg = <700 100>;
device_type = "ipic";
};
-
+
par_io@1400 {
reg = <1400 100>;
device_type = "par_io";
@@ -117,7 +117,6 @@
3 5 1 0 2 0 /* MDC */
0 d 2 0 1 0 /* RX_CLK (CLK9) */
3 18 2 0 1 0 /* TX_CLK (CLK10) */
- 1 1 1 0 1 0 /* TxD1 */
1 0 1 0 1 0 /* TxD0 */
1 1 1 0 1 0 /* TxD1 */
1 2 1 0 1 0 /* TxD2 */
@@ -165,11 +164,11 @@
reg = <e0100000 480>;
brg-frequency = <0>;
bus-frequency = <BCD3D80>;
-
+
muram@10000 {
device_type = "muram";
ranges = <0 00010000 00004000>;
-
+
data-only@0 {
reg = <0 4000>;
};
@@ -228,7 +227,7 @@
compatible = "ucc_geth";
model = "UCC";
device-id = <4>;
- reg = <3000 200>;
+ reg = <3200 200>;
interrupts = <23>;
interrupt-parent = < &qeic >;
/*
--
1.5.2.2
^ permalink raw reply related
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Gerhard Pircher @ 2007-11-13 22:21 UTC (permalink / raw)
To: Jon Smirl, grant.likely; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711131410r3b955fe7me20defb36d646939@mail.gmail.com>
-------- Original-Nachricht --------
> Datum: Tue, 13 Nov 2007 17:10:29 -0500
> Von: "Jon Smirl" <jonsmirl@gmail.com>
> An: "Grant Likely" <grant.likely@secretlab.ca>
> CC: "Gerhard Pircher" <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs
> On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > Abatron BDI-2000.
> >
> > Oops, but that's not all that cheap. ($2750USD). You might try
> > looking at the Macraigor Wiggler
> > (http://www.macraigor.com/wiggler.htm), but it has limited powerpc
> > support.
>
> Here are the choices:
> http://www.macraigor.com/cpus.htm
Looks like the Abatron BDI-2000 is the cheapest hardware debugger that
supports 74xx G4 CPUs. :-(
Thanks!
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jon Smirl @ 2007-11-13 22:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711131359l43f289e7j48b0df3ff57ea7c7@mail.gmail.com>
On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/13/07, Gerhard Pircher <gerhard_pircher@gmx.net> wrote:
> > > I'm trying to debug a kernel lockup that occurs on my machine with all kernel
> > > versions >2.6.16. I don't have a clue what the root cause of this lockup is,
> > > thus I'm thinking about using a hardware debugger. Can anybody recommend a
> > > reasonably cheap hardware debugger that works with G4 CPUs and can interact
> > > with GDB/DDD?
> >
> > Abatron BDI-2000.
>
> Oops, but that's not all that cheap. ($2750USD). You might try
> looking at the Macraigor Wiggler
> (http://www.macraigor.com/wiggler.htm), but it has limited powerpc
> support.
Here are the choices:
http://www.macraigor.com/cpus.htm
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-13 22:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194990218.28865.1.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 14 Nov 2007 08:43:38 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
> Well, at least the above tells is it's not DMA related.
>
> I don't know of any deeply hidden problem, so you are probably hitting
> something else ... if you have disabled idle, then it may be useful to
> try instrumenting locks or irq enable/disable.
Well, I only disabled power saving with powersave=off. Are there any other
ways to disable idle? What do you mean with instrumenting locks or
irq enable/disable?
> Also, did you try booting with all kernel debug options enabled ?
I compiled in almost all kernel debugging options and booted the kernel
with driver_debug, initcall_debug and debug. I didn't notice any serious
error messages so far. Not sure however, if I missed a debug option.
> Finally, since the problem seem to have started around a specific kernel
> version, can you try to bisect the patch that causes it ?
Hmm, I'm not sure how to do this (only worked on platform code so far).
I guess you think about checking out a kernel version from the git
repository, which doesn't contain the patch for kernel_execve().
I still suspect the kernel_execve() function (which was introduced in
2.6.17) because the kernel locks up after starting the first user program.
AFAIK kernel threads should be running much earlier.
Thanks!
regards,
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: 2.6.24-rc2-git3 powerpc link failure
From: Stephen Rothwell @ 2007-11-13 22:06 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andy, LKML
In-Reply-To: <473984E2.1040006@linux.vnet.ibm.com>
Hi Kamalesh,
On Tue, 13 Nov 2007 16:35:06 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> The 2.6.24-rc2-git3 kernel build fails during linking
>
> KSYM .tmp_kallsyms1.S
> AS .tmp_kallsyms1.o
> LD .tmp_vmlinux2
> KSYM .tmp_kallsyms2.S
> AS .tmp_kallsyms2.o
> LD .tmp_vmlinux3
> KSYM .tmp_kallsyms3.S
> AS .tmp_kallsyms3.o
> LD vmlinux.o
> ld: TOC section size exceeds 64k
> make: *** [vmlinux.o] Error 1
You need the following patch.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 7 Nov 2007 11:56:48 +1100
Subject: [PATCH] [POWERPC] Stop the TOC overflowing for large builds.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index ca51f0c..9374bc9 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -3,7 +3,7 @@
#
ifeq ($(CONFIG_PPC64),y)
-EXTRA_CFLAGS += -mno-minimal-toc
+CFLAGS_prom_init.o += -mno-minimal-toc
endif
ifeq ($(CONFIG_PPC32),y)
CFLAGS_prom_init.o += -fPIC
--
1.5.3.5
^ permalink raw reply related
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jon Smirl @ 2007-11-13 22:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711131357r6b072f4cgcd43c5cb8e73abdb@mail.gmail.com>
On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/13/07, Gerhard Pircher <gerhard_pircher@gmx.net> wrote:
> > I'm trying to debug a kernel lockup that occurs on my machine with all kernel
> > versions >2.6.16. I don't have a clue what the root cause of this lockup is,
> > thus I'm thinking about using a hardware debugger. Can anybody recommend a
> > reasonably cheap hardware debugger that works with G4 CPUs and can interact
> > with GDB/DDD?
>
> Abatron BDI-2000.
Does anyone have the detailed doc needed to implement the software for
a PPC hardware debugger? Dominic, the author of OpenOCD, has said he
will take a look at adding PPC support if someone can supply him with
the right doc.
I've requested it from my Freescale rep. They sent me all of the
hardware info but none of the software info. They can't seem to figure
out what I'm asking for.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: 2.6.24-rc1 freezes on powerbook at first boot stage
From: Elimar Riesebieter @ 2007-11-13 22:02 UTC (permalink / raw)
To: Nathan Lynch
Cc: linuxppc-dev, linux-wireless, Linux Kernel Mailing List,
linux-usb-devel
In-Reply-To: <20071104032006.GG9695@localdomain>
On Sat, 03 Nov 2007 the mental interface of
Nathan Lynch told:
[...]
> Does 2.6.23 (or any earlier kernel) work?
>=20
2.6.24-rc2 works so lala :)
Machine:
processor : 0
cpu : 7447A, altivec supported
clock : 833.333000MHz
revision : 0.2 (pvr 8003 0102)
bogomips : 36.32
timebase : 18432000
platform : PowerMac
machine : PowerBook5,6
motherboard : PowerBook5,6 MacRISC3 Power Macintosh=20
detected as : 287 (PowerBook G4 15")
pmac flags : 0000001b
L2 cache : 512K unified
pmac-generation : NewWorld
b43 doesn't authenticate via wpa (bluetooth isn't loaded):
WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 5 value 0x1 - Internet Systems Consortium DHCP Client V3.1.0
dmesg:
=2E.....
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
sysctl table check failed: /kernel .1 Writable sysctl directory
Call Trace:
[c1061e60] [c0008b28] show_stack+0x4c/0x1ac (unreliable)
[c1061ea0] [c0047354] set_fail+0x50/0x68
[c1061ec0] [c0047784] sysctl_check_table+0x418/0x714
[c1061f30] [c00335b8] register_sysctl_table+0x64/0xb4
[c1061f50] [c033fd5c] register_powersave_nap_sysctl+0x18/0x2c
[c1061f60] [c03391e4] kernel_init+0xc0/0x2a0
[c1061ff0] [c0011a58] kernel_thread+0x44/0x60
setup_kcore: restrict size=3D3fffffff
Registering PowerMac CPU frequency driver
=2E.....
ohci_hcd: Unknown symbol usb_hcd_pci_suspend
ohci_hcd: Unknown symbol usb_hcd_resume_root_hub
ohci_hcd: Unknown symbol usb_hcd_pci_probe
ohci_hcd: Unknown symbol usb_hcd_unlink_urb_from_ep
ohci_hcd: Unknown symbol usb_disabled
ohci_hcd: Unknown symbol usb_hcd_check_unlink_urb
ohci_hcd: Unknown symbol usb_calc_bus_time
ohci_hcd: Unknown symbol usb_hcd_pci_shutdown
ohci_hcd: Unknown symbol usb_hcd_link_urb_to_ep
ohci_hcd: Unknown symbol usb_hcd_pci_resume
ohci_hcd: Unknown symbol usb_put_hcd
ohci_hcd: Unknown symbol usb_hcd_giveback_urb
ohci_hcd: Unknown symbol usb_hcd_poll_rh_status
ohci_hcd: Unknown symbol usb_create_hcd
ohci_hcd: Unknown symbol usb_hcd_pci_remove
ohci_hcd: Unknown symbol usb_remove_hcd
ohci_hcd: Unknown symbol usb_add_hcd
ohci_hcd: Unknown symbol usb_root_hub_lost_power
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
=2E....
console-tools (kbd) doesn't work correct (No DPMS Blank on console)
(Using radeonfb) Boottime font isn't loaded on every vt.
=2E...
There is a lot to do, but it seems to be a big, big code change in
that version. This impressed me by looking at the git changes and
the size of patches. And the rc's don't seem to be frozend versions.
A lot of new code comes in....
Let me know whether a complete dmesg is needed.
Thanks
Elimar
--=20
The path to source is always uphill!
-unknown-
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Grant Likely @ 2007-11-13 21:59 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711131357r6b072f4cgcd43c5cb8e73abdb@mail.gmail.com>
On 11/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/13/07, Gerhard Pircher <gerhard_pircher@gmx.net> wrote:
> > I'm trying to debug a kernel lockup that occurs on my machine with all kernel
> > versions >2.6.16. I don't have a clue what the root cause of this lockup is,
> > thus I'm thinking about using a hardware debugger. Can anybody recommend a
> > reasonably cheap hardware debugger that works with G4 CPUs and can interact
> > with GDB/DDD?
>
> Abatron BDI-2000.
Oops, but that's not all that cheap. ($2750USD). You might try
looking at the Macraigor Wiggler
(http://www.macraigor.com/wiggler.htm), but it has limited powerpc
support.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Grant Likely @ 2007-11-13 21:57 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071113214845.85820@gmx.net>
On 11/13/07, Gerhard Pircher <gerhard_pircher@gmx.net> wrote:
> I'm trying to debug a kernel lockup that occurs on my machine with all kernel
> versions >2.6.16. I don't have a clue what the root cause of this lockup is,
> thus I'm thinking about using a hardware debugger. Can anybody recommend a
> reasonably cheap hardware debugger that works with G4 CPUs and can interact
> with GDB/DDD?
Abatron BDI-2000.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Hardware debuggers for PPC74xx G4 CPUs
From: Gerhard Pircher @ 2007-11-13 21:48 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to debug a kernel lockup that occurs on my machine with all kernel
versions >2.6.16. I don't have a clue what the root cause of this lockup is,
thus I'm thinking about using a hardware debugger. Can anybody recommend a
reasonably cheap hardware debugger that works with G4 CPUs and can interact
with GDB/DDD?
regards,
Gerhard
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-13 21:43 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071113212320.85840@gmx.net>
On Tue, 2007-11-13 at 22:23 +0100, Gerhard Pircher wrote:
> > There are ways, sure, which probably involve adding prink's all over
> the
> > place to figure it out... could be some DMA issue for example, could
> be
> > pretty much anything. Have you tried booting an initrd with no disk
> > access ?
> I tried to boot with a ramdisk, but that didn't help much. I still
> locks up
> while loading an init program or after entering some commands in
> sh shell. Looks like the problem is hidden deep in the kernel.
Well, at least the above tells is it's not DMA related.
I don't know of any deeply hidden problem, so you are probably hitting
something else ... if you have disabled idle, then it may be useful to
try instrumenting locks or irq enable/disable.
Also, did you try booting with all kernel debug options enabled ?
Finally, since the problem seem to have started around a specific kernel
version, can you try to bisect the patch that causes it ?
Ben.
^ permalink raw reply
* Re: Makefile and COMMON_UIMAGE target
From: Jon Smirl @ 2007-11-13 21:33 UTC (permalink / raw)
To: PowerPC dev list
In-Reply-To: <9e4733910711131324g418b7764vc84ece40d78658d@mail.gmail.com>
I meant DEFAULT_UIMAGE, not COMMON_UIMAGE in the previous message. The
patch is right.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Makefile and COMMON_UIMAGE target
From: Jon Smirl @ 2007-11-13 21:24 UTC (permalink / raw)
To: PowerPC dev list
If I select Efika (zImage.chrp) and my target (uImage, COMMON_UIMAGE)
at the same time. The chrp image doesn't get built.
This fixes it, but is it the right fix?
What the right to compare CONFIG_DEVICE_TREE to "" if it isn't defined?
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 4e16534..b291f53 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -149,7 +149,7 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
+#defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
KBUILD_IMAGE := $(defaultimage-y)
all: $(KBUILD_IMAGE)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..cbbc4ab 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -147,6 +147,7 @@ image-$(CONFIG_PPC_PRPMC2800) +=
zImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
+ifdef CONFIG_DEVICE_TREE
ifneq ($(CONFIG_DEVICE_TREE),"")
image-$(CONFIG_PPC_8xx) += cuImage.8xx
image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
@@ -160,6 +161,7 @@ image-$(CONFIG_BAMBOO) +=
treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_WALNUT) += treeImage.walnut
endif
+endif
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-13 21:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194753340.21340.24.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Sun, 11 Nov 2007 14:55:40 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
>
> On Sat, 2007-11-10 at 18:11 +0100, Gerhard Pircher wrote:
> > -------- Original-Nachricht --------
> > > Datum: Fri, 09 Nov 2007 18:50:29 +1100
> > > Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > > CC: linuxppc-dev@ozlabs.org
> > > Betreff: Re: Kernel locks up after calling kernel_execve()
> >
> > Is there a way to debug it without a hardware debugger or can you
> > recommend a cheap hardware debugger?
>
> There are ways, sure, which probably involve adding prink's all over the
> place to figure it out... could be some DMA issue for example, could be
> pretty much anything. Have you tried booting an initrd with no disk
> access ?
I tried to boot with a ramdisk, but that didn't help much. I still locks up
while loading an init program or after entering some commands in
sh shell. Looks like the problem is hidden deep in the kernel.
Thanks!
Gerhard
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
^ permalink raw reply
* Re: (beginner) Kernel fail during local_irq_enable()
From: Siva Prasad @ 2007-11-13 20:46 UTC (permalink / raw)
To: fabien.fb; +Cc: linuxppc-embedded
In-Reply-To: <mailman.2590.1194951904.3099.linuxppc-embedded@ozlabs.org>
Hi,=20
Some thing similar happened for me before. After I set the IRQ enable
bits, it resulted in an exception. After analyzing the exception and
SRR1 bits set, I was able to take care of it.
Other reason can be...
Immediately after you enable interrupts, any interrupt (which are
already enabled) can cause the system to take a different path of
servicing those interrupts. If some thing happens in that service
routine, you are in for a surprise.
If you have a JTAG emulator, after system hangs, just halt it and see
where it is executing. That may give a clue of what might have happened.
Or, you can look at the stack, based on the register contents, to see
the call back (difficult, but possible).
Good Luck.
- Siva
------------------------------
Date: Tue, 13 Nov 2007 12:04:59 +0100
From: fabien <fabien.fb@gmail.com>
Subject: (beginner) Kernel fail during local_irq_enable()
To: linuxppc-embedded@ozlabs.org
I work on a custom board based on MPC8xx.
The bootloader on it is a ppcboot 1.1.5. I'm a beginner with Linux port
and ppc.
I'm trying to pass the board working with a 2.4.4 kernel to a 2.6.19
kernel
from denx.
The kernel hang when trying to enable interrupt in local_irq_enable()
in init/main.c.
Nothing happened after. Look at the printk log dumped from __log_buf
adresse with md ppcboot command.
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 39, Issue 19
From: Siva Prasad @ 2007-11-13 20:45 UTC (permalink / raw)
To: fabien.fb; +Cc: linuxppc-embedded
In-Reply-To: <mailman.2590.1194951904.3099.linuxppc-embedded@ozlabs.org>
Hi,=20
Some thing similar happened for me before. After I set the IRQ enable
bits, it resulted in an exception. After analyzing the exception and
SRR1 bits set, I was able to take care of it.
Other reason can be...
Immediately after you enable interrupts, any interrupt (which are
already enabled) can cause the system to take a different path of
servicing those interrupts. If some thing happens in that service
routine, you are in for a surprise.
If you have a JTAG emulator, after system hangs, just halt it and see
where it is executing. That may give a clue of what might have happened.
Or, you can look at the stack, based on the register contents, to see
the call back (difficult, but possible).
Good Luck.
- Siva
------------------------------
Date: Tue, 13 Nov 2007 12:04:59 +0100
From: fabien <fabien.fb@gmail.com>
Subject: (beginner) Kernel fail during local_irq_enable()
To: linuxppc-embedded@ozlabs.org
I work on a custom board based on MPC8xx.
The bootloader on it is a ppcboot 1.1.5. I'm a beginner with Linux port
and ppc.
I'm trying to pass the board working with a 2.4.4 kernel to a 2.6.19
kernel
from denx.
The kernel hang when trying to enable interrupt in local_irq_enable()
in init/main.c.
Nothing happened after. Look at the printk log dumped from __log_buf
adresse with md ppcboot command.
^ permalink raw reply
* Re: 85xx Device tree problems: e0024520:02 not found
From: Clemens Koller @ 2007-11-13 20:33 UTC (permalink / raw)
To: robert lazarski; +Cc: linuxppc-embedded
In-Reply-To: <f87675ee0711131217q6bb54e06q74f7d16e79b94f19@mail.gmail.com>
robert lazarski schrieb:
> Hi all,
>
> I'm trying to bring up a new 8548 board on 2.6.23.1 . When booting,
> Some times I can get as far mounting over nfs. However, it gets stuck
> here:
>
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> e0024520:02 not found
> eth2: Could not attach to PHY
> IP-Config: Failed to open eth2
> IP-Config: Device `eth2' not found.
As already written in the u-boot-users list,
you could give the pauilis.git tree a try.
There have been recently (last month) several
PHY related changes. 2.6.23.1 seems to be too
"old".
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* [PATCH 1/2] PowerPC: 4xx uic: add mask_ack callback
From: Valentine Barshak @ 2007-11-13 20:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dwg
In-Reply-To: <20071113201559.GA26172@ru.mvista.com>
This adds uic_mask_ack_irq() callback to PowerPC 4xx uic code
to avoid kernel crash. It is used for edge-triggered interrupts
by handle_uic_irq().
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/uic.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/sysdev/uic.c 2007-11-13 18:42:33.000000000 +0300
+++ linux-2.6/arch/powerpc/sysdev/uic.c 2007-11-13 22:28:01.000000000 +0300
@@ -97,6 +97,22 @@ static void uic_ack_irq(unsigned int vir
spin_unlock_irqrestore(&uic->lock, flags);
}
+static void uic_mask_ack_irq(unsigned int virq)
+{
+ struct uic *uic = get_irq_chip_data(virq);
+ unsigned int src = uic_irq_to_hw(virq);
+ unsigned long flags;
+ u32 er, sr;
+
+ sr = 1 << (31-src);
+ spin_lock_irqsave(&uic->lock, flags);
+ er = mfdcr(uic->dcrbase + UIC_ER);
+ er &= ~sr;
+ mtdcr(uic->dcrbase + UIC_ER, er);
+ mtdcr(uic->dcrbase + UIC_SR, sr);
+ spin_unlock_irqrestore(&uic->lock, flags);
+}
+
static int uic_set_irq_type(unsigned int virq, unsigned int flow_type)
{
struct uic *uic = get_irq_chip_data(virq);
@@ -152,7 +168,7 @@ static struct irq_chip uic_irq_chip = {
.typename = " UIC ",
.unmask = uic_unmask_irq,
.mask = uic_mask_irq,
-/* .mask_ack = uic_mask_irq_and_ack, */
+ .mask_ack = uic_mask_ack_irq,
.ack = uic_ack_irq,
.set_type = uic_set_irq_type,
};
^ permalink raw reply
* [PATCH 0/2] PowerPC: 4xx uic updates
From: Valentine Barshak @ 2007-11-13 20:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dwg
These patches update 4xx uic code. The first one
fixes a minor issue with edge-triggered interrupts,
while the second one makes it use generic level and edge irq
handlers. I've added irq ack'ing to the unmask callback for
level-triggered interrupts, because to de-assert them we have
to do 2 things is the exact order as below:
1. de-assert the external source in the ISR.
2. ack the IRQ on the UIC.
So, ack'ing level interrupts before unmasking them makes possible
to use generic level irq handler and it doesn't hurt, cause
we can never miss a level-triggered interrupt. It always stays
asserted untill the external source is removed and ack'ed on UIC.
These have been tested on Sequoia PowerPC 440EPx board.
Thanks,
Valentine.
^ permalink raw reply
* 85xx Device tree problems: e0024520:02 not found
From: robert lazarski @ 2007-11-13 20:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to bring up a new 8548 board on 2.6.23.1 . When booting,
Some times I can get as far mounting over nfs. However, it gets stuck
here:
NET: Registered protocol family 1
NET: Registered protocol family 17
e0024520:02 not found
eth2: Could not attach to PHY
IP-Config: Failed to open eth2
IP-Config: Device `eth2' not found.
I can ping and tftp via u-boot just fine over eth2 - which runs
marvells 88E1111 . Here's the relavent part of my device tree:
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <0 1>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
reg = <1>;
device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
interrupt-parent = <&mpic>;
interrupts = <2 1>;
reg = <2>;
device_type = "ethernet-phy";
};
phy3: ethernet-phy@3 {
interrupt-parent = <&mpic>;
interrupts = <3 1>;
reg = <3>;
device_type = "ethernet-phy";
};
};
ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <24000 1000>;
local-mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <d 2 e 2 12 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy0>;
};
ethernet@25000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <25000 1000>;
local-mac-address = [ 00 E0 0C 00 73 01 ];
interrupts = <13 2 14 2 18 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1>;
};
ethernet@26000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <26000 1000>;
local-mac-address = [ 00 E0 0C 00 73 02 ];
interrupts = <f 2 10 2 11 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy2>;
};
ethernet@27000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "eTSEC";
compatible = "gianfar";
reg = <27000 1000>;
local-mac-address = [ 00 E0 0C 00 73 03 ];
interrupts = <15 2 16 2 17 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy3>;
};
Any ideas?
Robert
^ permalink raw reply
* Re: OT: Strange delays / what usually happens every 10 min?
From: Florian Boelstler @ 2007-11-13 20:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47339E23.70806@arcor.de>
For the sake of completeness: It is related to a flush operation of the
IP route cache, please see
http://thread.gmane.org/gmane.linux.kernel/602382.
Cheers,
Florian
^ permalink raw reply
* inflate returned FFFFFFFB
From: Alan Nishioka @ 2007-11-13 18:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
After adding files to initramfs, I get the following error:
Uncompressing Linux...inflate returned FFFFFFFB
This is caused by zlib_inflate returning -5 or Z_BUF_ERROR.
The attached patch fixes this problem for me.
It is also available at
http://www.nishioka.com/misc/ppc-gunzip.patch
It probably also fixes the problem at
http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023851.html
and only 15 months too late.
It moves the link/load address higher in memory and tells gunzip it has
more space to uncompress.
You need to change the address in .config
make menuconfig
Advanced setup -->
[*] Prompt for advanced configuration options
[*] Set the boot link/load address
(0x00800000) Link/load address for booting
This is my first post to this list.
Please tell me if I am missing anything.
Alan Nishioka
alan@nishioka.com
[-- Attachment #2: ppc-gunzip.patch --]
[-- Type: text/plain, Size: 1047 bytes --]
diff -ur linux-2.6.23.1-orig/arch/ppc/boot/simple/misc-embedded.c linux-2.6.23.1/arch/ppc/boot/simple/misc-embedded.c
--- linux-2.6.23.1-orig/arch/ppc/boot/simple/misc-embedded.c 2007-10-12 12:43:44.000000000 -0400
+++ linux-2.6.23.1/arch/ppc/boot/simple/misc-embedded.c 2007-11-08 12:06:12.000000000 -0500
@@ -212,7 +212,7 @@
*cp = 0;
puts("\nUncompressing Linux...");
- gunzip(0, 0x400000, zimage_start, &zimage_size);
+ gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
flush_instruction_cache();
puts("done.\n");
{
diff -ur linux-2.6.23.1-orig/arch/ppc/boot/simple/misc.c linux-2.6.23.1/arch/ppc/boot/simple/misc.c
--- linux-2.6.23.1-orig/arch/ppc/boot/simple/misc.c 2007-10-12 12:43:44.000000000 -0400
+++ linux-2.6.23.1/arch/ppc/boot/simple/misc.c 2007-11-08 13:08:34.000000000 -0500
@@ -216,7 +216,7 @@
puts("\n");
puts("Uncompressing Linux...");
- gunzip(NULL, 0x400000, zimage_start, &zimage_size);
+ gunzip(NULL, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
puts("done.\n");
/* get the bi_rec address */
^ permalink raw reply
* [PATCH] powerpc: Fix fs_enet module build
From: Jochen Friedrich @ 2007-11-13 18:32 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org; +Cc: Jeff Garzik, netdev, linux-kernel, akpm
If fs_enet is build as module, on PPC_CPM_NEW_BINDING platforms
mii-fec/mii-bitbang should be build as module, as well. On other
platforms, mii-fec/mii-bitbang must be included into the main module.
Otherwise some symbols remain undefined. Additionally, fs_enet uses
libphy, so add a select PHYLIB.
Building modules, stage 2.
MODPOST 5 modules
ERROR: "fs_scc_ops" [drivers/net/fs_enet/fs_enet.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
This patch replaces powerpc-fs_enet-select-phylib-as-the-driver-needs-it.patch
from -mm.
drivers/net/fs_enet/Kconfig | 11 ++++++++++-
drivers/net/fs_enet/Makefile | 15 ++++++++++++---
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index 2765e49..562ea68 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -2,6 +2,7 @@ config FS_ENET
tristate "Freescale Ethernet Driver"
depends on CPM1 || CPM2
select MII
+ select PHYLIB
config FS_ENET_HAS_SCC
bool "Chip has an SCC usable for ethernet"
@@ -11,11 +12,19 @@ config FS_ENET_HAS_SCC
config FS_ENET_HAS_FCC
bool "Chip has an FCC usable for ethernet"
depends on FS_ENET && CPM2
- select MDIO_BITBANG
default y
config FS_ENET_HAS_FEC
bool "Chip has an FEC usable for ethernet"
depends on FS_ENET && CPM1
+ select FS_ENET_MDIO_FEC
default y
+config FS_ENET_MDIO_FEC
+ tristate "MDIO driver for FEC"
+ depends on FS_ENET && CPM1
+
+config FS_ENET_MDIO_FCC
+ tristate "MDIO driver for FCC"
+ depends on FS_ENET && CPM2
+ select MDIO_BITBANG
diff --git a/drivers/net/fs_enet/Makefile b/drivers/net/fs_enet/Makefile
index 02d4dc1..1ffbe07 100644
--- a/drivers/net/fs_enet/Makefile
+++ b/drivers/net/fs_enet/Makefile
@@ -4,7 +4,16 @@
obj-$(CONFIG_FS_ENET) += fs_enet.o
-obj-$(CONFIG_8xx) += mac-fec.o mac-scc.o mii-fec.o
-obj-$(CONFIG_CPM2) += mac-fcc.o mii-bitbang.o
+fs_enet-$(CONFIG_FS_ENET_HAS_SCC) += mac-scc.o
+fs_enet-$(CONFIG_FS_ENET_HAS_FEC) += mac-fec.o
+fs_enet-$(CONFIG_FS_ENET_HAS_FCC) += mac-fcc.o
-fs_enet-objs := fs_enet-main.o
+ifeq ($(CONFIG_PPC_CPM_NEW_BINDING),y)
+obj-$(CONFIG_FS_ENET_MDIO_FEC) += mii-fec.o
+obj-$(CONFIG_FS_ENET_MDIO_FCC) += mii-bitbang.o
+else
+fs_enet-$(CONFIG_FS_ENET_MDIO_FEC) += mii-fec.o
+fs_enet-$(CONFIG_FS_ENET_MDIO_FCC) += mii-bitbang.o
+endif
+
+fs_enet-objs := fs_enet-main.o $(fs_enet-m)
--
1.5.3.5
^ permalink raw reply related
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