* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Grant Likely @ 2006-05-31 22:33 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6E8@de01exm68.ds.mot.com>
On 5/31/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
> Was the port done on a FX100 FPGA?
No; but AFAIK, the ppc hardcore is identical for all FX parts. The
FX100 shoudn't be a problem.
> Also, what PVR number does the PPC405 indicate?
Core#0>rd pvr
pvr: 0x20011430 536941616
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Aidan Williams @ 2006-05-31 22:22 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6E6@de01exm68.ds.mot.com>
Anantharaman Chetan-W16155 wrote:
> Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
> FX series FPGA’s, PPC405 processor?
>
Yes, see
http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022583.html
Note that there are silicon bugs that prevent caches being used in some
chips.
> More specifically, the FX100 FPGA?
I don't have one of those, sorry.
- aidan
^ permalink raw reply
* Help with MPC5200 + Bestcomm + Local Plus Bus
From: roger blofeld @ 2006-05-31 21:42 UTC (permalink / raw)
To: linuxppc embedded
Hi
I have a custom board which is essentially an icecube with an FPGA on
the local bus. I have a driver which pulls data from the FPGA in
response to interrupts using memcpy_fromio(). I would like to reduce
the CPU usage.
Has anyone used bestcomm to move data from LPB to memory? Is there an
example anywhere? From the app note AN2604 it looks like writing a
bestcomm task is difficult at best. Perhaps it is possible to re-use
the ethernet rx task for this purpose?
I'm using mainline 2.6.16.18 with Sylvain's patches for
ethernet/bestcomm/ide. (BTW, will that code make it into the mainline
any time soon?)
Thanks in advance for any advice
-roger
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* RE: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Anantharaman Chetan-W16155 @ 2006-05-31 21:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605311235n171f889g135e074685b578bc@mail.gmail.com>
Was the port done on a FX100 FPGA? Also, what PVR number does the PPC405
indicate?
Thanks,
Chetan
-----Original Message-----
From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant
Likely
Sent: Wednesday, May 31, 2006 2:35 PM
To: Anantharaman Chetan-W16155
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
On 5/31/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
> Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
FX
> series FPGA's, PPC405 processor?
Linux on the V4-FX is well supported. Xilinx has an app node
describing how to modify the linuxppc-2.4 tree to work on the V4-FX.
You can find out how to get the tree here:
http://www.penguinppc.org/kernel/
I've got both 2.4 & 2.6 happily running on my ML403 board here.
Cheers,
g.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Geoff Levand @ 2006-05-31 21:25 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev
In-Reply-To: <20060531204144.GA7909@w-mikek2.ibm.com>
Mike Kravetz wrote:
> We would like to add code that gathers statistics about hypervisor calls.
> It would keep track of things like # of calls made for each opcode as well
> as time spent processing the calls.
>
> The 'obvious' place to gather such statistics would be from within the
> routines making hcalls in hvCall.S. Once thing that I have noticed is
> the following comment at the beginning hvCall.S:
>
> * NOTE: this file will go away when we move to inline this work.
>
> So, it appears someone thought/thinks these routines should be inlined.
> I assume this is for performance reasons? If this is the case, then I
> suspect gathering of statistics (which would introduce overhead) would
> meet resistance?
>
> Comments about the feasibility of adding such statistic gathering code
> would be appreciated.
FYI, there exists an add-on feature KFT (kernel function trace)
which you may be able to extend to do much of what you want. It
uses gcc's -finstrument-functions option to hook into the
entry and exit of C functions. You may able to add the hooks
by hand to the asm routines in hvCall.S and then take advantage
of the existing KFT functionality to start and stop traces, post
process the data, etc.
http://tree.celinuxforum.org/CelfPubWiki/KernelFunctionTrace
-Geoff
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Michal Ostrowski @ 2006-05-31 21:04 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1149107718.8379.48.camel@localhost.localdomain>
On Wed, 2006-05-31 at 15:35 -0500, Matthew McClintock wrote:
> On Wed, 2006-05-31 at 16:26 -0400, Michal Ostrowski wrote:
> > I've had some experience with trying to edit existing OF trees (i.e.
> > take a G5 OF tree and alter it to reflect the fact that the OS has a
> > hypervisor between it and the HW). It's not a pleasant experience.
> >
> > Thus for OF based systems I'd be very wary of trying to edit the OF
> > tree
> > in arbitrary ways prior to Linux seeing it.
>
> Out of curiosity what was hard about it?
Well, suppose that you want to remove a particular device from an OF
tree. At what point are you certain that you've completely removed all
references to it?
I've always been concerned that there are some properties remaining in
the tree that may refer to the node I am removing (resulting in an
inconsistent tree). If you're working with one particular FW provider
then you may come up with code that does it right, but such code may not
necessarily catch all the extensions provided by another FW provider.
I've found Apple and IBM FW like to do things in different ways. In
particular IBM FW likes to add "ibm,*" properties and you'd have to know
the meaning of all such properties to ensure you've caught all
references to the device you're pruning.
Like with most things, getting a solution to solve your immediate
problem is easy; a perfect, general solution is much, much more
difficult.
(Granted, some things, such as adding a new "memory" node are pretty
easy to do.)
> Also it is worth mentioning
> some systems don't have to privilege of having a OF tree ready to go by
> the time Linux starts.
For such systems I think the right approach is to provide a
DTC-generated OF tree (provided that one ensures that we don't skip
important parts of prom_init.c).
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Collecting hypervisor call stats
From: Mike Kravetz @ 2006-05-31 20:41 UTC (permalink / raw)
To: linuxppc-dev
We would like to add code that gathers statistics about hypervisor calls.
It would keep track of things like # of calls made for each opcode as well
as time spent processing the calls.
The 'obvious' place to gather such statistics would be from within the
routines making hcalls in hvCall.S. Once thing that I have noticed is
the following comment at the beginning hvCall.S:
* NOTE: this file will go away when we move to inline this work.
So, it appears someone thought/thinks these routines should be inlined.
I assume this is for performance reasons? If this is the case, then I
suspect gathering of statistics (which would introduce overhead) would
meet resistance?
Comments about the feasibility of adding such statistic gathering code
would be appreciated.
Thanks,
--
Mike
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Matthew McClintock @ 2006-05-31 20:35 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1149107204.6507.97.camel@brick>
On Wed, 2006-05-31 at 16:26 -0400, Michal Ostrowski wrote:
> I've had some experience with trying to edit existing OF trees (i.e.
> take a G5 OF tree and alter it to reflect the fact that the OS has a
> hypervisor between it and the HW). It's not a pleasant experience.
>
> Thus for OF based systems I'd be very wary of trying to edit the OF
> tree
> in arbitrary ways prior to Linux seeing it.
Out of curiosity what was hard about it? Also it is worth mentioning
some systems don't have to privilege of having a OF tree ready to go by
the time Linux starts.
-Matthew
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Michal Ostrowski @ 2006-05-31 20:26 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060531200419.GA17052@mag.az.mvista.com>
On Wed, 2006-05-31 at 13:04 -0700, Mark A. Greer wrote:
> On Tue, May 30, 2006 at 05:12:37PM -0400, Michal Ostrowski wrote:
> > On Tue, 2006-05-30 at 13:41 -0700, Mark A. Greer wrote:
> > > On Mon, May 29, 2006 at 10:01:03PM -0400, mostrows@watson.ibm.com wrote:
> > I'm curious how the tacked-on dt is expected to interact with the real
> > FW dt,
>
> That's a good question. I was thinking that a tacked on dt would be a
> complete replacement for whatever dt came from the fw (but extracting
> some info like /memory props). That probably works okay for non-OF
> systems but may not work for OF systems b/c there is so much more info
> in the OF dt. Someone who knows about OF will have to speak up here.
>
I've had some experience with trying to edit existing OF trees (i.e.
take a G5 OF tree and alter it to reflect the fact that the OS has a
hypervisor between it and the HW). It's not a pleasant experience.
Thus for OF based systems I'd be very wary of trying to edit the OF tree
in arbitrary ways prior to Linux seeing it.
> > and in particular how you would expect the interrogation
> > of /chosen/bootargs in prom_init.c (using prom_getprop()) to pick up the
> > command line value I specify in the tacked-on dt.
>
> If a flattened dt is used instead of an OF dt the prom_init code isn't used.
If we always skip prom_init.c code then we may skip stuff like TCE
allocation which is only ever done on the first boot (and never on
kexec).
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.
From: Mark A. Greer @ 2006-05-31 20:04 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1149023558.6507.15.camel@brick>
On Tue, May 30, 2006 at 05:12:37PM -0400, Michal Ostrowski wrote:
> On Tue, 2006-05-30 at 13:41 -0700, Mark A. Greer wrote:
> > On Mon, May 29, 2006 at 10:01:03PM -0400, mostrows@watson.ibm.com wrote:
> > > zImage will store the builtin command-line in a dedicated section, allowing
> > > it to be easily identified and edited with user-space tools.
> > >
> > > zImage will set /chosen/bootargs to the stored builtin command-line setting,
> > > if /chosen/bootargs is empty (emulating the behavior in prom_init.c).
> > >
> > > Use of this mechanism avoids the need to modify firmware or rely on a
> > > bootloader to customize kernel arguments (and overall system
> > > behavior). The command line can be edited as needed when a zImage is
> > > copied to a TFTP staging area for download by firmware.
>
>
>
>
> > Why do this? Why not get rid of storing the cmdline in the zImage altogether?
> >
>
> The CONFIG_CMDLINE that we have now is very useful if I want the
> behavior of the system to be dependent on the kernel/command line I
> specify that it used (particularly in BOOTP/TFTP scenarios). For such
> systems I configure their firmware to not provide any arguments and to
> always download via TFTP a designated kernel image.
>
> What this scenario does, is it allows me to specify system behavior by
> putting the right kernel with the right command line in the magic
> location from where it will be downloaded.
>
> The problem is, that if I have some large number of machines and I want
> to use the same kernel for all of them (and simply change the command
> line between them) then I have to effectively build a custom kernel for
> each. This patch allows me to build one kernel and then simply edit the
> command line embedded within it.
>
> The key point is that the command line changes and I don't want to have
> to require a firmware interaction every time I change it.
Okay. I hadn't thought of that scenario. You're happy with the dt that
the fw gives you except that you want to change the bootargs.
I guess we can keep CONFIG_CMDLINE around then.
> > We already have equivalent functionality by storing it in the dt's
> > /chosen/bootargs so why this unnecessary complexity?
> >
>
>
> > Add some code to edit the /chosen/bootargs at zImage runtime (just like
> > arch/ppc used to) and we're covered.
>
> That is what this patch is doing.
>
> > AFAICT, we're already adding a tool
> > to tack on flat dt's to an already existing zImage so you're not doing
> > anything we can't--or won't--do already.
> >
>
> Can you please point me at this code so that I can evaluate it in
> detail?
It doesn't exist yet and no one has jumped up to make that tool that I
have seen. I've been messing with bootwrapper code and part of that
adds cmdline editing from a running bootwrapper. We still need someone
to write this tool (assuming that's the way we're going):
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022435.html
Care to volunteer? ;)
> I'm curious how the tacked-on dt is expected to interact with the real
> FW dt,
That's a good question. I was thinking that a tacked on dt would be a
complete replacement for whatever dt came from the fw (but extracting
some info like /memory props). That probably works okay for non-OF
systems but may not work for OF systems b/c there is so much more info
in the OF dt. Someone who knows about OF will have to speak up here.
> and in particular how you would expect the interrogation
> of /chosen/bootargs in prom_init.c (using prom_getprop()) to pick up the
> command line value I specify in the tacked-on dt.
If a flattened dt is used instead of an OF dt the prom_init code isn't used.
Mark
^ permalink raw reply
* Re: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Grant Likely @ 2006-05-31 19:35 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6E6@de01exm68.ds.mot.com>
On 5/31/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
> Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4 FX
> series FPGA's, PPC405 processor?
Linux on the V4-FX is well supported. Xilinx has an app node
describing how to modify the linuxppc-2.4 tree to work on the V4-FX.
You can find out how to get the tree here:
http://www.penguinppc.org/kernel/
I've got both 2.4 & 2.6 happily running on my ML403 board here.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] use msleep() for RTAS delays
From: John Rose @ 2006-05-31 19:32 UTC (permalink / raw)
To: External List; +Cc: Paul Mackerras
The current use of udelay() for RTAS extended delay conditions can
result in CPU soft lockups. The use of msleep() won't tie up the CPU.
Signed-off-by: John Rose <johnrose@austin.ibm.com>
---
Thanks-
John
diff -puN arch/powerpc/kernel/rtas.c~msleep_rtas arch/powerpc/kernel/rtas.c
--- 2_6_linus/arch/powerpc/kernel/rtas.c~msleep_rtas 2006-05-31 14:07:51.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas.c 2006-05-31 14:10:09.000000000 -0500
@@ -447,10 +447,10 @@ int rtas_set_power_level(int powerdomain
while (1) {
rc = rtas_call(token, 2, 2, setlevel, powerdomain, level);
if (rc == RTAS_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
@@ -472,10 +472,10 @@ int rtas_get_sensor(int sensor, int inde
while (1) {
rc = rtas_call(token, 2, 2, state, sensor, index);
if (rc == RTAS_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
@@ -497,12 +497,11 @@ int rtas_set_indicator(int indicator, in
while (1) {
rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
if (rc == RTAS_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
- }
- else
+ msleep(wait_time);
+ } else
break;
}
diff -puN arch/powerpc/kernel/rtas_flash.c~msleep_rtas arch/powerpc/kernel/rtas_flash.c
--- 2_6_linus/arch/powerpc/kernel/rtas_flash.c~msleep_rtas 2006-05-31 14:10:47.000000000 -0500
+++ 2_6_linus-johnrose/arch/powerpc/kernel/rtas_flash.c 2006-05-31 14:19:30.000000000 -0500
@@ -16,7 +16,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
-#include <asm/delay.h>
+#include <linux/delay.h>
#include <asm/uaccess.h>
#include <asm/rtas.h>
#include <asm/abs_addr.h>
@@ -372,10 +372,10 @@ static void manage_flash(struct rtas_man
rc = rtas_call(rtas_token("ibm,manage-flash-image"), 1,
1, NULL, args_buf->op);
if (rc == RTAS_RC_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
@@ -465,10 +465,10 @@ static void validate_flash(struct rtas_v
spin_unlock(&rtas_data_buf_lock);
if (rc == RTAS_RC_BUSY)
- udelay(1);
+ msleep(1);
else if (rtas_is_extended_busy(rc)) {
wait_time = rtas_extended_busy_delay_time(rc);
- udelay(wait_time * 1000);
+ msleep(wait_time);
} else
break;
}
_
^ permalink raw reply
* Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Anantharaman Chetan-W16155 @ 2006-05-31 19:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
Has anyone successfully ported a Linux 2.4 Kernel on a Xilinx Virtex-4
FX series FPGA's, PPC405 processor?
More specifically, the FX100 FPGA?
Thanks,
Chetan
[-- Attachment #2: Type: text/html, Size: 1895 bytes --]
^ permalink raw reply
* Re: >=2.6.17-rc4-mm1 kernel compilation problem (relocation truncated to fit)
From: Nathan Pilatzke @ 2006-05-31 17:34 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linuxppc-dev
In-Reply-To: <447DC91D.8010508@zytor.com>
Applied the patch, did a 'make clean' and 'make'. The patch had no
effect for me, exact same errors.
H. Peter Anvin wrote:
> Nathan Pilatzke wrote:
>> I am getting compilation errors for 2.6.17-rc5-mm1 all the way back to
>> 2.6.17-rc4-mm1. Kernel 2.6.17-rc3-mm1 compiles better for me (I get the
>> undefined reference to __udivdi3 error that has been reported
>> previously). Here are the errors that I get for 2.6.17-rc5-mm1:
>>
>
> Could you try the following patch?
>
> -hpa
>
>
> ------------------------------------------------------------------------
>
> diff --git a/usr/klibc/arch/ppc/MCONFIG b/usr/klibc/arch/ppc/MCONFIG
> index 8b51e65..e101453 100644
> --- a/usr/klibc/arch/ppc/MCONFIG
> +++ b/usr/klibc/arch/ppc/MCONFIG
> @@ -13,9 +13,9 @@ KLIBCBITSIZE = 32
> # Extra linkflags when building the shared version of the library
> # This address needs to be reachable using normal inter-module
> # calls, and work on the memory models for this architecture
> -# 256-16 MB - normal binaries start at 256 MB, and jumps are limited
> +# 256-8 MB - normal binaries start at 256 MB, and jumps are limited
> # to +/- 16 MB
> -KLIBCSHAREDFLAGS = -Ttext 0x0f000200
> +KLIBCSHAREDFLAGS = -Ttext 0x0f800200
>
> # The kernel so far has both asm-ppc* and asm-powerpc.
> KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)arch/$(KLIBCARCH)/include
^ permalink raw reply
* Re: >=2.6.17-rc4-mm1 kernel compilation problem (relocation truncated to fit)
From: H. Peter Anvin @ 2006-05-31 16:49 UTC (permalink / raw)
To: Nathan Pilatzke; +Cc: linuxppc-dev
In-Reply-To: <447DAAE4.7010503@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Nathan Pilatzke wrote:
> I am getting compilation errors for 2.6.17-rc5-mm1 all the way back to
> 2.6.17-rc4-mm1. Kernel 2.6.17-rc3-mm1 compiles better for me (I get the
> undefined reference to __udivdi3 error that has been reported
> previously). Here are the errors that I get for 2.6.17-rc5-mm1:
>
Could you try the following patch?
-hpa
[-- Attachment #2: ppc32.so.address --]
[-- Type: text/plain, Size: 758 bytes --]
diff --git a/usr/klibc/arch/ppc/MCONFIG b/usr/klibc/arch/ppc/MCONFIG
index 8b51e65..e101453 100644
--- a/usr/klibc/arch/ppc/MCONFIG
+++ b/usr/klibc/arch/ppc/MCONFIG
@@ -13,9 +13,9 @@ KLIBCBITSIZE = 32
# Extra linkflags when building the shared version of the library
# This address needs to be reachable using normal inter-module
# calls, and work on the memory models for this architecture
-# 256-16 MB - normal binaries start at 256 MB, and jumps are limited
+# 256-8 MB - normal binaries start at 256 MB, and jumps are limited
# to +/- 16 MB
-KLIBCSHAREDFLAGS = -Ttext 0x0f000200
+KLIBCSHAREDFLAGS = -Ttext 0x0f800200
# The kernel so far has both asm-ppc* and asm-powerpc.
KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)arch/$(KLIBCARCH)/include
^ permalink raw reply related
* howto allocate memory using scatter/gather
From: Muneeswaran P - TLS, Chennai @ 2006-05-31 15:40 UTC (permalink / raw)
To: kernelnewbies, linuxppc-embedded
Hi,
How do allocate the memory using scatter/gather method ?
Can I allocate memory of size of 50 KBytes using=20
scatter/gather list method and then memory map that area to=20
user space ?
=20
Please give me the way.
Regards,
Munees.
DISCLAIMER=20
The contents of this e-mail and any attachment(s) are confidential and =
intended for the=20
named recipient(s) only. It shall not attach any liability on the =
originator or HCL or its=20
affiliates. Any views or opinions presented in this email are solely =
those of the author and=20
may not necessarily reflect the opinions of HCL or its affiliates. Any =
form of reproduction,=20
dissemination, copying, disclosure, modification, distribution and / or =
publication of this=20
message without the prior written consent of the author of this e-mail =
is strictly=20
prohibited. If you have received this email in error please delete it =
and notify the sender=20
immediately. Before opening any mail and attachments please check them =
for viruses and=20
defect.
^ permalink raw reply
* >=2.6.17-rc4-mm1 kernel compilation problem (relocation truncated to fit)
From: Nathan Pilatzke @ 2006-05-31 14:40 UTC (permalink / raw)
To: linuxppc-dev
I am getting compilation errors for 2.6.17-rc5-mm1 all the way back to
2.6.17-rc4-mm1. Kernel 2.6.17-rc3-mm1 compiles better for me (I get the
undefined reference to __udivdi3 error that has been reported
previously). Here are the errors that I get for 2.6.17-rc5-mm1:
... (previous output snipped)
KLIBCCC usr/kinit/ipconfig/main.o
KLIBCCC usr/kinit/ipconfig/netdev.o
KLIBCCC usr/kinit/ipconfig/packet.o
KLIBCCC usr/kinit/ipconfig/dhcp_proto.o
KLIBCCC usr/kinit/ipconfig/bootp_proto.o
LD usr/kinit/ipconfig/lib.a
KLIBCLD usr/kinit/ipconfig/static/ipconfig
KLIBCLD usr/kinit/ipconfig/shared/ipconfig
usr/kinit/ipconfig/main.o: In function `complete_device':
main.c:(.text+0x6c): relocation truncated to fit: R_PPC_REL24 against
symbol `inet_ntoa' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x84): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xac): relocation truncated to fit: R_PPC_REL24 against
symbol `inet_ntoa' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xc4): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xe4): relocation truncated to fit: R_PPC_REL24 against
symbol `inet_ntoa' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0xfc): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x134): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x158): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x17c): relocation truncated to fit: R_PPC_REL24 against
symbol `printf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x19c): relocation truncated to fit: R_PPC_REL24 against
symbol `snprintf' defined in .text section in
/usr/src/linux-2.6.17-rc5-mm1/usr/klibc/libc.so
main.c:(.text+0x1ac): additional relocation overflows omitted from the
output
make[3]: *** [usr/kinit/ipconfig/shared/ipconfig] Error 1
make[2]: *** [usr/kinit/ipconfig] Error 2
make[1]: *** [_usr_kinit] Error 2
make: *** [usr] Error 2
I assume that the errors I am seeing are regarding the klibc changes
that went into 2.6.17-rc4-mm1 (and apparently no one else is seeing
these errors as I would think that I would have found them reported
somewhere). I am running a gentoo system on an eMac 7450 PowerPC.
Here's my gcc info:
# gcc -v
Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/specs
Configured with: /var/tmp/portage/gcc-3.4.5-r1/work/gcc-3.4.5/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.5
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/g++-v3
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --disable-libgcj
--enable-languages=c,c++,f77 --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)
Need anything else? Can anyone offer some help or ideas?
Thanks, nathanp.
(please cc me on responses)
^ permalink raw reply
* Fwd: execve of /sbin/init fails
From: Steve Iribarne (GMail) @ 2006-05-31 13:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <b4b98b690605310630l3da5a027x57adc8654cfbd4c1@mail.gmail.com>
Whoops.. forgot to replyall.
---------- Forwarded message ----------
From: Steve Iribarne (GMail) <netstv@gmail.com>
Date: May 31, 2006 6:30 AM
Subject: Re: execve of /sbin/init fails
To: Anantharaman Chetan-W16155 <Chetan.S.Anantharaman@motorola.com>
On 5/30/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
> Thanks for your reply. Yes, the file /sbin/init is in the ramdisk file
> system with execute permissions on it. I am running Busybox (how can I
> check the version?),
I think you can check the version when you do "make menuconfig". I
think the version info is in there somewhere. Also it may be in the
README.
>but my /sbin/init is not Busybox's init.
Right.. so if you are not using Busybox's init, make sure you told
Busybox this. When you do "make menuconfig" in Busybox, I think it is
under the General tab, there is a check for using Busybox's init or
not. I think in 1.00-rc3 they turned that on by default. They may
have always turned it on, I can't remember.
>
> One thing I'd like to mention is, I have used the same ramdisk
> filesystem and the same version of Linux 2.4 kernel and U-Boot
> bootloader and have been able to successfully execute the /sbin/init.
> This board has a Xilinx Virtex 2 Pro FPGA with a PPC405. On my new
> board, with a Xilinx Virtex 4 FX100 FPGA, with the kernel running on a
> PPC405 and the same filesystem, the execve of /sbin/init "hangs". By
> hangs, I mean there is no output on the console after the below output
> and it does not return (which indicates that it has not encountered an
> error of some sort, since execve returns on error only). So, I am not
> sure where it is stuck and is there any way to tell where it's stuck at?
>
> Hope this above info and below screen capture provide a bit more
> background to the issue.
>
>
> Below is a capture of the screen output:
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> OCP uart ver 1.6.2 init complete
> LSP Revision 42
> ikconfig 0.5 with /proc/ikconfig
> Starting kswapd
> Disabling the Out Of Memory Killer
> Journalled Block Device driver loaded
> devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
> devfs: boot_options: 0x1
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with no serial options enabled
> ttyS00 at 0xfdfff003 (irq = 22) is a 16550A
> xgpio #0 at 0x50000000 mapped to 0xC5000000
> RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
> loop: loaded (max 8 devices)
> Tracer: Initialization complete
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 5104k freed
> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
> VFS: Mounted root (ext2 filesystem).
> Mounted devfs on /dev
> Freeing unused kernel memory: 40k init
>
>
>
> -----Original Message-----
> From: Jeff.Fellin@rflelect.com [mailto:Jeff.Fellin@rflelect.com]
> Sent: Tuesday, May 30, 2006 3:55 PM
> To: Anantharaman Chetan-W16155
> Cc: linuxppc-embedded@ozlabs.org;
> linuxppc-embedded-bounces+jeff.fellin=rflelect.com@ozlabs.org
> Subject: Re: execve of /sbin/init fails
>
>
>
> "Anantharaman Chetan-W16155"
>
> <Chetan.S.Anantharaman@motorola.com>
> To: <linuxppc-embedded@ozlabs.org>
> Sent by:
> cc:
> linuxppc-embedded-bounces+jeff.fellin=rflelect.com
> Subject: execve of /sbin/init fails
> @ozlabs.org
>
>
>
>
>
> 05/30/2006 15:59
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >Hi,
> >I am trying to bring up a custom board with a PPC405 processor running
> Linux 2.4.20 (MontaVista Release) and am >having problems with the call
> to
> execve("/sbin/init", argv_init, envp_init) not returning in the file
> main.c. The processor >just hangs and there is no output on the
> terminal. I
> have tried to see if I can run "bin/sh" and even this execve call does
> >not
> return. Some things about the board are, the networking option has been
> disabled in the Linux .config file. I am >running U-Boot 1.1.1 as the
> bootloader and am downloading the uImage (compressed kernel) and the
> initrd.boot >(filesystem) into RAM and accessing the filesystem in RAM.
> Chetan, I would check the contents of the initrd filesystem you created
> to
> verify the files are in the image. If they are monitor the console
> output
> to verfiy the ramdisk filesystem is found and installed into ram.
> Jeff Fellin
>
> >Any help as to what could be causing this to happen or how to debug
> this
> issue would be appreciated. Also, I've tried >to capture the return
> value
> of the execve call but since the call does not return, this has not
> helped
> any.
>
> Thanks,
> Chetan Anantharaman
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: PPC exception 0x320
From: Becky Bruce @ 2006-05-30 17:01 UTC (permalink / raw)
To: jeanwelly; +Cc: linuxppc-embedded
In-Reply-To: <200605292222280467864@126.com>
Jeanwelly,
I'd really like to help you here, but you still haven't explained =20
what you mean by "PPC alarmed exception 0x320". Since there is no =20
such exception that I'm aware of on the 750, I'm trying very hard to =20
figure out what you mean, and it's impossible for me to do that =20
without more information from you. I need to know exactly what it =20
is that you're seeing in order to help you. If the kernel is =20
printing out a message, please include the *entire message* in your =20
email.
Are you getting a message that says "Bad trap at PC: ....."?
A quick mini-tutorial on PPC exceptions: Whenever hardware detects =20
an exception condition, the hardware starts executing at a vector =20
location for that particular exception. On the PPC 750, these =20
exception vectors are, for the most part, aligned at multiples of =20
0x100. There is a list of exception vectors and their associated =20
causes in Table 4.2 of the User's manual (see below for a URL). Some =20=
exceptions are caused by software, and others, like the Decrementer =20
Interrupt, are generated by the hardware itself. There is often more =20
than one way to cause a particular exception.
For example, a DSI exception can be caused by a miss in the hardware =20
page table, or by a load to a direct-store segment, among other =20
things. *All* of these events will result in running the exception =20
vector starting at 0x300 because all of these conditions cause a =20
DSI. Although there are multiple causes for DSI, they all go to the =20
same vector address. The system software at that address must use =20
methods described in the user's manual to determine what kind of DSI =20
exception has occurred so it can handle the fault.
While the hardware detects the exception, it is the job of the system =20=
software to handle it. The User's manual for a processor will list =20
the events that hardware will detect and cause an exception. You =20
have to look at your system software source code to figure out if =20
your operating system supports a given exception. In Linux, this =20
code is mostly in arch/ppc/head.S and arch/ppc/traps.c.
You can get a copy of the 750 User's Manual at:
http://www.freescale.com/files/32bit/doc/ref_manual/MPC750UM.pdf
The exception information is in Chapter 4.
Cheers,
Becky
On May 29, 2006, at 9:22 AM, jeanwelly wrote:
> Hi Becky Bruce,
> Sorry for late response. I got mail traffic...
>
> I encountered the exception 0x320 which caused the PPC card crash. =20
> Based on my understanding, I think exception is a HW behaviour, so =20
> I guess there maybe exist some reference on all the supported =20
> exceptions of some version of PPC. Do you know this?
>
> My system take that exception as an "unknown exception" and crash =20
> the card. So, I think the exception is from the PPC CPU, but don't =20
> the concrete meanings.
>
> Appreciate your suggestions.
> ---
> Jeanwelly
>
> ----------------------------------------
>
>> Is there some error message you can show me?
>>
>> -B
>>
>> On Apr 25, 2006, at 10:03 AM, jeanwelly wrote:
>>
>>> Hi Becky Bruce,
>>> I'm using PPC 750... Just as you said, 0x300 is for DSI, and I
>>> guess they are a set of exceptions, not just one. And 0x320 is one
>>> of them.
>>> I got a board crash, and PPC alarmed exception 0x320. Could you
>>> show me the mechanism of handling of a special exception not one =20
>>> set.
>>> =09
>>>
>>> =3D=3D=3D=3D=3D=3D=3D 2006-04-25 02:53:35 =
=E6=82=A8=E5=9C=A8=E6=9D=A5=E4=BF=A1=E4=B8=AD=E5=86=99=E9=81=93=EF=BC=9A=3D=
=3D=3D=3D=3D=3D=3D
>>>
>>>> Could you try to be more specific? What processor do you have, =20
>>>> what
>>>> linux version are you running, and what do you mean exactly when =20=
>>>> you
>>>> say you "encountered PPC exception 0x320"? As far as I know, the
>>>> powerpc architecture does not define an exception 0x320. 0x300 is
>>>> usually DSI on classic powerpc parts. BookE parts handle things
>>>> differently.
>>>>
>>>> Thanks,
>>>> -Becky
>>>>
>>>> On Apr 24, 2006, at 8:51 AM, jeanwelly wrote:
>>>>
>>>>> Hi,
>>>>> I encountered PPC exception 0x320, but don't know what it for. Any
>>>>> one could help me on this?
>>>>> Thanks!
>>>>> =09
>>>>>
>>>>> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=
=80jeanwelly
>>>>> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=
=80jeanwelly@126.com
>>>>> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=
=80=E3=80=80=E3=80=802006-04-24
>>>>> _______________________________________________
>>>>> Linuxppc-embedded mailing list
>>>>> Linuxppc-embedded@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>> .
>>>
>>> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D
>>> =09
>>>
>>> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
=E8=87=B4
>>> =E7=A4=BC=EF=BC=81
>>>
>>> =09
>>> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
jeanwelly
>>> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
jeanwelly@126.com
>>> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
=E3=80=80=E3=80=802006-04-25
>>>
>>
>>
>> .
>
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D =3D
> =09
>
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
=E8=87=B4
> =E7=A4=BC=EF=BC=81
>
> =09
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
jeanwelly
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
jeanwelly@126.com
> =E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=E3=80=80=
=E3=80=80=E3=80=802006-05-29
>
^ permalink raw reply
* Re: [SOLVED] LXT973 support (dual PHY with single MDIO)
From: Andy Fleming @ 2006-05-30 16:23 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060530182250.6ec4fb3b@vitb.ru.mvista.com>
On May 30, 2006, at 09:22, Vitaly Bordug wrote:
> On Tue, 30 May 2006 11:28:48 +0200
> Laurent Pinchart <laurent.pinchart@tbox.biz> wrote:
>
>> Hi,
>>
>> once again, posting to a mailing list helped me solving my
>> problem. It should
>> have been obvious that the MDIO bus is really a bus, and can as
>> such support
>> several devices. The issue was that the drivers/net/fs_enet driver
>> set
>> bus->phy_mask to ~0x9, and the LXT973 uses addresses 0 and 1.
>> Address 1 thus
>> never got probed. What's the reason for probing addresses 0 and 3
>> only ?
>
> The reason is obvious: bitbang read of PHY id with not-existent
> PHY, does not return expected (0, iirc), that confuse mdio bus
> device-driver bound (it assumes error and returns -1), and prevents
> from probing other phys. So, as that seems to be a "feature" on
> CPM2 only, we are working that around specifying phy_mask to
> prevent probing inexistent phys w/over bitbang thing.
Hopefully, this isn't being set in the driver, but is set in the
board code, instead. This is a board-specific setting.
Andy
^ permalink raw reply
* unresolved symbol dma_spin_lock with CONFIG_DEBUG_SPINLOCK enabled
From: Jan Veldeman @ 2006-05-31 9:19 UTC (permalink / raw)
To: linuxppc-dev
Hi,
when compiling for a platform without CONFIG_GENERIC_ISA_DMA set and with
CONFIG_DEBUG_SPINLOCK enabled, the linker complains about an unresolved symbol
to dma_spin_lock (which is declared in kernel/dma.c but doesn't get compiled).
Without CONFIG_DEBUG_SPINLOCK, these statements are removed by the compiler,
so that dma_spin_lock isn't referenced.
I see 3 possible solutions for this problem:
1. compile in kernel/dma.c when CONFIG_DEBUG_SPINLOCK is enabled
diff --git a/kernel/Makefile b/kernel/Makefile
index 58908f9..6cab2a3 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_FUTEX) += futex.o
ifeq ($(CONFIG_COMPAT),y)
obj-$(CONFIG_FUTEX) += futex_compat.o
endif
+obj-$(CONFIG_DEBUG_SPINLOCK) += dma.o
obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
obj-$(CONFIG_SMP) += cpu.o spinlock.o
obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o
as it's a debug build, the extra space shouldn't mind.
It will also solve similar problems for other architectures (if they exist, I
didn't check this)
2. stub the claim/release_dma_lock in include/asm-powerpc/dma.h
diff --git a/include/asm-powerpc/dma.h b/include/asm-powerpc/dma.h
index 4bb57fe..de5efc7 100644
--- a/include/asm-powerpc/dma.h
+++ b/include/asm-powerpc/dma.h
@@ -182,6 +182,8 @@ extern long ppc_cs4232_dma, ppc_cs4232_d
#define DMA_AUTOINIT 0x10
+#ifdef CONFIG_GENERIC_ISA_DMA
+
extern spinlock_t dma_spin_lock;
static __inline__ unsigned long claim_dma_lock(void)
@@ -196,6 +198,22 @@ static __inline__ void release_dma_lock(
spin_unlock_irqrestore(&dma_spin_lock, flags);
}
+#else /* CONFIG_GENERIC_ISA_DMA */
+
+/* dma_spin_lock isn't declared because kernel/dma.c doesn't get compiled,
+ * so stub these functions */
+
+static __inline__ unsigned long claim_dma_lock(void)
+{
+ return 0;
+}
+
+static __inline__ void release_dma_lock(unsigned long flags)
+{
+}
+
+#endif /* CONFIG_GENERIC_ISA_DMA */
+
/* enable/disable a specific DMA channel */
static __inline__ void enable_dma(unsigned int dmanr)
{
but this just doesn't feel right
3. fix the driver using claim_dma_lock on platforms without
CONFIG_GENERIC_ISA_DMA
This just looks like a lot of work and would make it harder for drivers.
Any suggestions/remarks?
Best regards,
Jan
^ permalink raw reply related
* [RFT] snd-aoa has headphone and line-out detection now
From: Johannes Berg @ 2006-05-31 9:23 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]
Hey,
I committed the code necessary in snd-aoa to support headphone and
line-out detection, but I need help with one thing:
When you plug in an optical connector into the combo thingie, is a
regular interrupt generated? Since nothing will actually be printed out,
I suggest the following method to find out:
1) start alsamixer
2) enable all outputs
3) plug in optical connector into the headphone/line-out plug
4) observe if anything changes
5) remove optical connector again
6) disable all outputs
7) plug in optical connector again
8) reply to this mail telling me what happens in alsamixer when doing it
If nothing happens then I suppose no interrupt is generated, otherwise,
there must be. But I'll need to change the code a bit in any case.
The headphone detection is intentionally not doing much, for one it
reports the current state in the mixer element 'Headphone Detected', and
you get the choice of switching to headphone on detect, which also turns
off all the others, and enables speakers when removing. Also, the
initial status is based on it.
If you want more options, run a userspace daemon that listens to changes
on 'Headphone Detected' and changes stuff appropriately. Keep in mind
that it must disable the automatic handling then. And no, I haven't
written one :)
johannes
PS: For those who care, here are some technical details:
(1) I decided not to make the fabric handle *all* the interrupts
because that gets messy quickly with the allowed transfer items.
Also, it is hard to handle because sometimes some inputs are
mutually exclusive, while outputs controlled by amps are not, etc.
(2) I will need to change the code so that the fabric handles all the
outputs, that is move the S/PDIF control to the fabric and have
the codec have a call for enabling/disabling it... Yes, this is
going into the direction of having the fabric control all of it,
but see (1). Maybe that code will enable having the fabric control
it all, I dunno.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* pmf_register_irq_client gives sleep with locks held warning
From: Johannes Berg @ 2006-05-30 20:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
Hi,
When testing headphone detection stuff I got this:
[ 634.218762] BUG: sleeping function called from invalid context at mm/slab.c:2794
[ 634.218774] in_atomic():0, irqs_disabled():1
[ 634.218777] Call Trace:
[ 634.218779] [D67ADC00] [C00085F8] show_stack+0x50/0x190 (unreliable)
[ 634.218794] [D67ADC30] [C0024030] __might_sleep+0xcc/0xe8
[ 634.218804] [D67ADC40] [C0076C04] __kmalloc+0xf4/0xf8
[ 634.218815] [D67ADC60] [C00B37D4] proc_create+0x9c/0xe8
[ 634.218827] [D67ADC90] [C00B3930] proc_mkdir_mode+0x2c/0x88
[ 634.218833] [D67ADCB0] [C005227C] register_handler_proc+0xe4/0xfc
[ 634.218844] [D67ADD50] [C0051D70] setup_irq+0x118/0x16c
[ 634.218850] [D67ADD70] [C0051E68] request_irq+0xa4/0xb8
[ 634.218855] [D67ADDA0] [C0020BA0] macio_do_gpio_irq_enable+0x40/0x50
[ 634.218860] [D67ADDB0] [C00208BC] pmf_register_irq_client+0x88/0x9c
[..., not important]
The problem obviously is that request_irq via setup_irq and ... may
sleep via kmalloc, while pmf_register_irq_client spin_lock_irqsave()s
around the call.
The solution is probably to use spin_lock() instead of
spin_lock_irqsave() here.
Comments?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* AW: MPC8270 on Microsys PM827 Kernel 2.6 Oops: kernel access of bad area, sig: 11 [#1]
From: Behre, Frederik - LT @ 2006-05-31 7:49 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Thanks for answer me.=20
I want to install Xenomai on this mpc8270. Therefor I need 2.6.14 =
,because I need the adeos patch.=20
Thanks for helping me
Freddy
-----Urspr=FCngliche Nachricht-----
Von: wd@denx.de [mailto:wd@denx.de]=20
Gesendet: Dienstag, 30. Mai 2006 22:44
An: Behre, Frederik - LT
Cc: linuxppc-embedded@ozlabs.org
Betreff: Re: MPC8270 on Microsys PM827 Kernel 2.6 Oops: kernel access of =
bad area, sig: 11 [#1]
In message <CC692F5386B0AA47A62B7484A7CA2B6D02B52CB0@frmx1.litef.de> you =
wrote:
>=20
> I compile my kernel with
> pm82x_deconfig and PCI disabled.
...
> MPC8260 Reset Status: External Soft, External Hard
Why do you use pm82x_deconfig with a MPC8260 processor? You should =
use pm826_deconfig instead.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de =
That's the thing about people who think they hate computers. What =
they really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"
^ permalink raw reply
* Re: [PATCH] fix of_parse_dma_window. was: Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Jeremy Kerr @ 2006-05-31 4:17 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev
In-Reply-To: <1149014320.23168.11.camel@localhost.localdomain>
> Unless there is a more elegant solution... :-)
>
> Signed-off-by: Will Schmidt <willschm@us.ibm.com>
Ack, for a temporary fix. I'm working on a nicer solution at the moment.
Jeremy
^ 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