* [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
* Re: fs_enet segfaults when adding network interface to bridge
From: Vitaly Bordug @ 2006-05-31 0:58 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <C7B65358-8BEF-42E7-A11C-3FBC501BB324@freescale.com>
On Tue, 30 May 2006 16:54:42 -0500
Andy Fleming <afleming@freescale.com> wrote:
>
> On May 30, 2006, at 08:39, Laurent Pinchart wrote:
>
> >>> Hi everybody,
> >>>
> >>> I ran into a segfault in the fs_enet driver when adding the
> >>> network interface to an ethernet bridge. This only happens when
> >>> the interface is
> >>> down.
> >>>
> >>> ----- Kernel version -----
> >>> Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30
> >>> 13:25:37 CEST
> >>> 2006 ppc unknown
> >>> (from main linux-2.6 git repository)
> >>> ----- End of kernel version -----
> >>>
> >>> ----- Oops report -----
> >>> Oops: kernel access of bad area, sig: 11 [#1]
> >>> NIP: C0109884 LR: C010D420 CTR: 00000000
> >>> REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-
> >>> g7f02f290-dirty)
> >>> MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
> >>> DAR: 00000140, DSISR: 20000000
> >>> TASK = c0851090[42] 'brctl' THREAD: c027c000
> >>> GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF
> >>> F00000A0
> >>> EFFFFFFF GPR08: C026E380 C0210000 00000000 C0230000 C0210000
> >>> 1001D150
> >>> 00FFE000 00000001 GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0
> >>> 00000000
> >>> 10072C94 7FDD0AD8 10072CA4 GPR24: 00000000 10000A48 00000000
> >>> C027D8D0
> >>> C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884]
> >>> phy_ethtool_gset+0x0/0x48
> >>> LR [C010D420] fs_get_settings+0x34/0x48
> >>> Call Trace:
> >>> [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
> >>> [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
> >>> [C027DC40] [C018CBC0] port_cost+0x58/0x108
> >>> [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
> >>> [C027DCE0] [C018D9AC] add_del_if+0x94/0x98
> >>> [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
> >>> [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
> >>> [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
> >>> [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
> >>> [C027DEE0] [C0067164] do_ioctl+0x88/0x9c
> >>> [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
> >>> [C027DF10] [C00675A8] sys_ioctl+0x40/0x74
> >>> [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
> >>> Instruction dump:
> >>> 7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001
> >>> 40bdff70
> >>> 3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144
> >>> 90040008
> >>> ----- End of oops report -----
> >>>
> >>> ----- Source lines -----
> >>> [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
> >>> [C010D414] fs_get_settings+0x28/0x48
> >>> (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0]
> >>> dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
> >>> [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
> >>> ----- End of source lines -----
> >>>
> >>> phy_ethtool_gset segfaults when trying to access phydev->supported
> >>> because phydev is NULL.
> >>>
> >>> As I'm not familiar with the fs_enet driver, I'm looking for
> >>> advices regarding what to fix and how to fix it.
> >>
> >> IIRC, fs_enet got bound to phydev only being ->up. So in down
> >> state, phydev
> >> may be either null, or last assigned (need to have a look into
> >> source to
> >> tell for certain). So what is the proper behavior from your point
> >> of view?
> >
> > I have no idea :-) What I know is that the driver should not
> > segfault when
> > asked to report the port speed. Either we should return an error
> > or have the
> > phy device bound to fs_enet at all time. It might also be a bridge
> > issue,
> > maybe the bridge code should turn the interface up before reading
> > its speed.
> > How do other ethernet drivers proceed ?
>
>
> Well, gianfar only invokes phy_ethtool_gset() after checking to see
> that phydev is not NULL. fs_enet should do this as well. It may be
> preferable to move that check into phy_ethtool_gset(). Certainly a
> workable solution, though I'm inclined to feel that the PHY layer
> should be able to assume that a given PHY exists. The sort of
> problem also exists if you try to use ethtool to find the ring sizes
> before the device has been opened.
>
> Anyway, the easy fix is for fs_enet to check for NULL before calling
> phy_ethtool_gset().
>
Andy,
Thanks for pointing it out, I was just going to seek into gianfar
behavior.
That issue seems not the only problem - there are plenty of cases I
saw, where if initially PHY got failed to be bound, fs_enet seems to
be really unhappy with phydev == NULL and direct dereferences of the
latter.
I'll try to address that stuff as time permits...
-Vitaly
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Benjamin Herrenschmidt @ 2006-05-30 23:10 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1149029585.6507.39.camel@brick>
> The fact that the allocation may be sparse does not mean it actually
> will be. As long as code expects arbitrary remappings it will have a
> degree of robustness; but that does not mean that the mechanism by which
> remappings are done cannot instantiate simple mappings. In other words,
> I'd like to see the concept of "irq offsets" being banished, but having
> re-mapping code be smart enough so that, for example, an MPIC that must
> deal with interrupt vectors 0..127 has these vectors made visible to the
> system at 16..143.
>
> I think that the current virt irq remapping algorithm would provide you
> with exactly this behavior.
The current virt irq remapper is not very efficient. It's especially
slow in the critical path of real -> virt translation which is probably
why xics locally has a radix tree version. I suppose we could generalize
that in a "better" remapper using both the array and the radix tree
though.
Offsets sounded like a simpler thing, specially for platforms that don't
need arbitrary remappings, and less code/memory hungry (embedded
platformns would like that for example).
> In cases where we have a struct device_node, the struct device_node
> should have a pointer to the PIC (or the PIC's device_node), and the
> raw, unmodified interrupt line values. When one wants to present an
> irq to generic code, we use the (PIC,line) information from the
> device_node to instantiate a virq.
>
> If there is no struct device_node, you still have to come up with a
> (PIC,line) pair in order to get a virq.
I won't add anything to struct device node. Only remove from it. The
device node is only used initially when binding a given device to an
irq, no need to "cache" that in the struct device node or whatever. The
generic code will provide means for walking the interrupt tree along the
lines I described to obtain a line,PIC pair, which will then be looked
up in a table of PICs so an offset can be obtained or a remapping of
the line into a global virq.
> virt_irq_create_mapping() (or whatever replaces it) should take the
> physical line and a PIC identifier/pointer as arguments so that it can
> inform the PIC about a mapping it has instantiated (in case we really
> have to make an arbitrary re-mapping) and so that it can try to
> instantiate an identity or offset-only translation if possible. In the
> latter case, the PIC object will tell the remapper what offset range to
> use.
Sounds over complicated to me.
> I think our thoughts on this differ only on the aspect of whether the
> remapper is considered to be an arbitrary remapper, a smart
> implementation of which results in IRQ being remapped via offsets,
> versus multi-level remapping, with offsets first followed by arbitrary
> remappings as necessary (and the distinction between offsets and
> arbitrary remapping being visible beyond the remapper function).
Beware of over engineering :)
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Michal Ostrowski @ 2006-05-30 22:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1149027185.9986.46.camel@localhost.localdomain>
On Wed, 2006-05-31 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> > A PIC would not need to reserve anything is when it is allocated. Only
> > when interrupt numbers need to be presented to generic kernel code is a
> > virq number required.
>
> We could have completely sparse allocation indeed and any virt number
> matching any PIC but I don't like that too much. Complicates things
> unnecessarily don't you think ? I like irq numbers to be somewhat stable
> on a given platform :) Helps debugging & diagnosing problems...
>
The fact that the allocation may be sparse does not mean it actually
will be. As long as code expects arbitrary remappings it will have a
degree of robustness; but that does not mean that the mechanism by which
remappings are done cannot instantiate simple mappings. In other words,
I'd like to see the concept of "irq offsets" being banished, but having
re-mapping code be smart enough so that, for example, an MPIC that must
deal with interrupt vectors 0..127 has these vectors made visible to the
system at 16..143.
I think that the current virt irq remapping algorithm would provide you
with exactly this behavior.
> > One can use irq_desc->chip_data to easily go from virq -> (PIC, line).
> > The PIC then maintains an array to map each of it's lines to virq.
> > This allows for all re-mappings to always be arbitrary in nature and
> > still allows for O(1) look-up in either direction.
>
> I'll think about it, but I'm really tempted to keep simple ranges for
> now... we'll see.
>
> > > - Interrupt 0..15 are reserved. 0 is always invalid. Only ISA PICs that
> > > carry legacy devices can request those (by passing a special flag to the
> > > allocation routine).
> >
> > > Any other gets remapped (including powermac MPICs).
> > > That will avoid endless problems that we never properly solved with
> > > legacy drivers and the fact that Linus decided that 0 should be the
> > > invalid interrupt number on all platforms
> > >
> > > - Provide in prom_parse.c functions for obtaining the PIC node and
> > > local interrupt number of a given device based on a passed-in array
> > > matching the semantics of an "interrupts" property and a parent node.
> > > Along with a helper that may just take a child node. The former is
> > > needed for PCI devices that have no device node. Provide a
> > > pci_ppc_map_interrupt() that takes a pci_dev and does the interrupt
> > > mapping, either by using the standard OF approach if a device-node is
> > > present, or walking up the PCI tree while doing standard swizzling until
> > > it reaches a device node
> >
> > How is this different from the current use of map_interrupt() in
> > finish_node_interrupts()?
>
> Slightly... basically cleaned up version of it.
>
> > It seems to me that it would be better to have the struct device_node
> > store the raw interrupt vector data as presented in the dev tree
> > (without remapping) along with a pointer to the struct device_node for
> > the appropriate PIC.
>
> I don't understand what you have in mind. Remember we are working with
> cases where devices may not have a node. There is no such thing as "an
> interrupt == a node" anyway. Beside, I want to _remove_ anything in
> struct device_node that isn't specifically the node linkage and property
> list. All the pre-parsed junk has to go.
>
In cases where we have a struct device_node, the struct device_node
should have a pointer to the PIC (or the PIC's device_node), and the
raw, unmodified interrupt line values. When one wants to present an
irq to generic code, we use the (PIC,line) information from the
device_node to instantiate a virq.
If there is no struct device_node, you still have to come up with a
(PIC,line) pair in order to get a virq.
virt_irq_create_mapping() (or whatever replaces it) should take the
physical line and a PIC identifier/pointer as arguments so that it can
inform the PIC about a mapping it has instantiated (in case we really
have to make an arbitrary re-mapping) and so that it can try to
instantiate an identity or offset-only translation if possible. In the
latter case, the PIC object will tell the remapper what offset range to
use.
> I'm not sure how your scheme differs from what I have in mind at this
> point except from the fact that you'll shuffle interrupt numbers way
> more than I intend to. I suppose it _might_ be simpler to go through the
> virt irq remapper once rather than having both a set of ranges +
> eventually the remapper, and I've thought about using the remapper for
> everything too, but I'd still like to keep the concept of ranges, thus
> I'm tempted to still allocate all irqs for a given controller
> continuously in the remapper when instanciating the PIC rather than when
> actually looking for IRQs....
I think our thoughts on this differ only on the aspect of whether the
remapper is considered to be an arbitrary remapper, a smart
implementation of which results in IRQ being remapped via offsets,
versus multi-level remapping, with offsets first followed by arbitrary
remappings as necessary (and the distinction between offsets and
arbitrary remapping being visible beyond the remapper function).
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* [PATCH] dtc: add setting of physical boot cpu
From: Michael Neuling @ 2006-05-30 22:31 UTC (permalink / raw)
To: linuxppc-dev, Jon Loeliger
In-Reply-To: <20060518170017.B15E367A6C@ozlabs.org>
dtc always sets the physical boot CPU to 0xfeedbeef. Add a -b option to
set this. Also add warnings when using the wrong property with the
wrong blob version.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Retransmission with updated warnings after discussion with Jimi.
dtc.c | 14 ++++++++++----
dtc.h | 8 +++++---
flattree.c | 16 ++++++++++------
livetree.c | 17 ++++++++++++-----
4 files changed, 37 insertions(+), 18 deletions(-)
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c
+++ dtc/dtc.c
@@ -95,6 +95,8 @@ static void usage(void)
fprintf(stderr, "\t\tBlob version to produce, defaults to 3 (relevant for dtb\n\t\tand asm output only)\n");
fprintf(stderr, "\t-R <number>\n");
fprintf(stderr, "\t\tMake space for <number> reserve map entries (relevant for \n\t\tdtb and asm output only)\n");
+ fprintf(stderr, "\t-b <number>\n");
+ fprintf(stderr, "\t\tSet the physical boot cpu\n");
fprintf(stderr, "\t-f\n");
fprintf(stderr, "\t\tForce - try to produce output even if the input tree has errors\n");
exit(2);
@@ -113,8 +115,9 @@ int main(int argc, char *argv[])
FILE *outf = NULL;
int outversion = 3;
int reservenum = 1;
+ int boot_cpuid_phys = 0xfeedbeef;
- while ((opt = getopt(argc, argv, "I:O:o:V:R:f")) != EOF) {
+ while ((opt = getopt(argc, argv, "I:O:o:V:R:fb:")) != EOF) {
switch (opt) {
case 'I':
inform = optarg;
@@ -134,6 +137,9 @@ int main(int argc, char *argv[])
case 'f':
force = 1;
break;
+ case 'b':
+ boot_cpuid_phys = strtol(optarg, NULL, 0);
+ break;
default:
usage();
}
@@ -167,7 +173,7 @@ int main(int argc, char *argv[])
if (! bi || ! bi->dt)
die("Couldn't read input tree\n");
- if (! check_device_tree(bi->dt)) {
+ if (! check_device_tree(bi->dt, outversion, boot_cpuid_phys)) {
fprintf(stderr, "Input tree has errors\n");
if (! force)
exit(1);
@@ -185,9 +191,9 @@ int main(int argc, char *argv[])
if (streq(outform, "dts")) {
dt_to_source(outf, bi);
} else if (streq(outform, "dtb")) {
- dt_to_blob(outf, bi, outversion);
+ dt_to_blob(outf, bi, outversion, boot_cpuid_phys);
} else if (streq(outform, "asm")) {
- dt_to_asm(outf, bi, outversion);
+ dt_to_asm(outf, bi, outversion, boot_cpuid_phys);
} else if (streq(outform, "null")) {
/* do nothing */
} else {
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h
+++ dtc/dtc.h
@@ -178,7 +178,7 @@ struct node *chain_node(struct node *fir
void add_property(struct node *node, struct property *prop);
void add_child(struct node *parent, struct node *child);
-int check_device_tree(struct node *dt);
+int check_device_tree(struct node *dt, int outversion, int boot_cpuid_phys);
/* Boot info (tree plus memreserve information */
@@ -207,8 +207,10 @@ struct boot_info *build_boot_info(struct
/* Flattened trees */
-void dt_to_blob(FILE *f, struct boot_info *bi, int version);
-void dt_to_asm(FILE *f, struct boot_info *bi, int version);
+void dt_to_blob(FILE *f, struct boot_info *bi, int version,
+ int boot_cpuid_phys);
+void dt_to_asm(FILE *f, struct boot_info *bi, int version,
+ int boot_cpuid_phys);
struct boot_info *dt_from_blob(FILE *f);
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c
+++ dtc/flattree.c
@@ -301,7 +301,8 @@ static struct data flatten_reserve_list(
}
static void make_bph(struct boot_param_header *bph,
struct version_info *vi,
- int reservesize, int dtsize, int strsize)
+ int reservesize, int dtsize, int strsize,
+ int boot_cpuid_phys)
{
int reserve_off;
@@ -324,12 +325,13 @@ static void make_bph(struct boot_param_h
+ dtsize + strsize);
if (vi->flags & FTF_BOOTCPUID)
- bph->boot_cpuid_phys = 0xfeedbeef;
+ bph->boot_cpuid_phys = cpu_to_be32(boot_cpuid_phys);
if (vi->flags & FTF_STRTABSIZE)
bph->size_dt_strings = cpu_to_be32(strsize);
}
-void dt_to_blob(FILE *f, struct boot_info *bi, int version)
+void dt_to_blob(FILE *f, struct boot_info *bi, int version,
+ int boot_cpuid_phys)
{
struct version_info *vi = NULL;
int i;
@@ -355,7 +357,8 @@ void dt_to_blob(FILE *f, struct boot_inf
reservebuf = flatten_reserve_list(bi->reservelist, vi);
/* Make header */
- make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len);
+ make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len,
+ boot_cpuid_phys);
fwrite(&bph, vi->hdr_size, 1, f);
@@ -395,7 +398,7 @@ static void dump_stringtable_asm(FILE *f
}
}
-void dt_to_asm(FILE *f, struct boot_info *bi, int version)
+void dt_to_asm(FILE *f, struct boot_info *bi, int version, int boot_cpuid_phys)
{
struct version_info *vi = NULL;
int i;
@@ -434,7 +437,8 @@ void dt_to_asm(FILE *f, struct boot_info
vi->last_comp_version);
if (vi->flags & FTF_BOOTCPUID)
- fprintf(f, "\t.long\t0xdeadbeef\t/*boot_cpuid_phys*/\n");
+ fprintf(f, "\t.long\t%i\t/*boot_cpuid_phys*/\n",
+ boot_cpuid_phys);
if (vi->flags & FTF_STRTABSIZE)
fprintf(f, "\t.long\t_%s_strings_end - _%s_strings_start\t/* size_dt_strings */\n",
Index: dtc/livetree.c
===================================================================
--- dtc.orig/livetree.c
+++ dtc/livetree.c
@@ -456,7 +456,7 @@ static int check_root(struct node *root)
return ok;
}
-static int check_cpus(struct node *root)
+static int check_cpus(struct node *root, int outversion, int boot_cpuid_phys)
{
struct node *cpus, *cpu;
struct property *prop;
@@ -518,8 +518,15 @@ static int check_cpus(struct node *root)
}
}
- if (! bootcpu)
- WARNMSG("No cpu has \"linux,boot-cpu\" property\n");
+ if (outversion < 2) {
+ if (! bootcpu)
+ WARNMSG("No cpu has \"linux,boot-cpu\" property\n");
+ } else {
+ if (bootcpu)
+ WARNMSG("\"linux,boot-cpu\" property is deprecated in blob version 2 or higher\n");
+ if (boot_cpuid_phys == 0xfeedbeef)
+ WARNMSG("physical boot CPU not set. Use -b option to set\n");
+ }
return ok;
}
@@ -697,7 +704,7 @@ static void fixup_phandles(struct node *
fixup_phandles(root, child);
}
-int check_device_tree(struct node *dt)
+int check_device_tree(struct node *dt, int outversion, int boot_cpuid_phys)
{
int ok = 1;
@@ -713,7 +720,7 @@ int check_device_tree(struct node *dt)
return 0;
ok = ok && check_root(dt);
- ok = ok && check_cpus(dt);
+ ok = ok && check_cpus(dt, outversion, boot_cpuid_phys);
ok = ok && check_memory(dt);
ok = ok && check_chosen(dt);
if (! ok)
^ permalink raw reply
* RE: execve of /sbin/init fails
From: Anantharaman Chetan-W16155 @ 2006-05-30 22:16 UTC (permalink / raw)
To: Jeff.Fellin, Steve Iribarne (GMail), adgospod
Cc: linuxppc-embedded-bounces+jeff.fellin=rflelect.com,
linuxppc-embedded
In-Reply-To: <OF32D825BB.6DBF6685-ON8525717E.0072AF23@teal.com>
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?), but my /sbin/init is not Busybox's init.
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 =3D 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]=20
Sent: Tuesday, May 30, 2006 3:55 PM
To: Anantharaman Chetan-W16155
Cc: linuxppc-embedded@ozlabs.org;
linuxppc-embedded-bounces+jeff.fellin=3Drflelect.com@ozlabs.org
Subject: Re: execve of /sbin/init fails
=20
"Anantharaman Chetan-W16155"
<Chetan.S.Anantharaman@motorola.com>
To: <linuxppc-embedded@ozlabs.org> =20
Sent by:
cc: =20
=
linuxppc-embedded-bounces+jeff.fellin=3Drflelect.com
Subject: execve of /sbin/init fails =20
@ozlabs.org
=20
=20
05/30/2006 15:59
=20
=20
>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: execve of /sbin/init fails
From: Andy Gospodarek @ 2006-05-30 22:15 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: Anantharaman Chetan-W16155, linuxppc-embedded
In-Reply-To: <b4b98b690605301429q4f474ec4g9545005de192e1d6@mail.gmail.com>
On 5/30/06, Steve Iribarne (GMail) <netstv@gmail.com> wrote:
> On 5/30/06, Anantharaman Chetan-W16155
> <Chetan.S.Anantharaman@motorola.com> wrote:
> >
> >
> >
> >
> > 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.
>
>
> Hmm.. Ok.. so I've read the other suggestions all good, but I think we
> are missing some info. Are you running Busybox? If you are using
> Busybox, what version? Also, what init are you using? Are you using
> busyboxes?
>
> The ramdisk suggestion was a good one. First off, check what is in
> your ramdisk. Also check the rights of the files in the ramdisk.
> Make sure you have the execute bit set. I've seen exactly what you
> are seeing when my rights on the file init were messed up.
>
> Also I think I've seen a hang with an older version of Busybox using
> their version of init. I just got sysinit and that seemed to fix it,
> (Although I had to reconfig Busybox to not use their version of init)
>
I guess I totally assumed busybox was being used, so good suggestion.
I too saw this with an older version of busybox (0.60 maybe?) and I
ended up editing the config to contain only init and then compiled it
statically and placed it on the rootfs. It turned out to be just the
right size and functionality for my needs. I think I later updated to
a 1.0 or 1.1-series and didn't have to use the same hack.
>
>
>
> > The processor just hangs and there is no output on the terminal.
>
>
> When you say the process just "hangs", where are you in the boot
> cycle? Is it before you see the linux kernel starting to load? Or do
> you see any kernel messages start to spew out?
>
> Hope this helps a little.
>
> -stv
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
From: Benjamin Herrenschmidt @ 2006-05-30 22:13 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: linuxppc-dev
In-Reply-To: <1148997289.25048.153.camel@brick>
> A PIC would not need to reserve anything is when it is allocated. Only
> when interrupt numbers need to be presented to generic kernel code is a
> virq number required.
We could have completely sparse allocation indeed and any virt number
matching any PIC but I don't like that too much. Complicates things
unnecessarily don't you think ? I like irq numbers to be somewhat stable
on a given platform :) Helps debugging & diagnosing problems...
> One can use irq_desc->chip_data to easily go from virq -> (PIC, line).
> The PIC then maintains an array to map each of it's lines to virq.
> This allows for all re-mappings to always be arbitrary in nature and
> still allows for O(1) look-up in either direction.
I'll think about it, but I'm really tempted to keep simple ranges for
now... we'll see.
> > - Interrupt 0..15 are reserved. 0 is always invalid. Only ISA PICs that
> > carry legacy devices can request those (by passing a special flag to the
> > allocation routine).
>
> Always create an ISA PIC that immediately requests lines 0..15.
Well, if we use your suggested "sparse" allocation method, then yes, we
need to request them right away before anything else. But I'd like to
start with the range allocation in which case simply reserving that
range for use by whatever PIC says "I'm the legacy ISA PIC" is enough.
> Should one actually exists, we can associate the ISA PIC with the
> appropriate device node. Should ISA devices exist, once they request
> interrupts (using (PIC,line) as arguments) we'll short-circuit virq
> allocation since all ISA PIC mappings already exists.
I'm not sure I understand there. ISA devices don't "request interrupts
using (PCI,line)" or whatever... we don't necessarily know in advance.
Part of the reasoning here is to also make sure that if no ISA PIC
allocated 0...15 then a stupid legacy driver loaded by the user will
fail it's call to request_irq()
> Then there's no need to special case anything (and all other interrupts
> are forced to be remapped out of the 0..15 range, without an explicit
> "offset" concept).
/me is a bit dubious...
> > Any other gets remapped (including powermac MPICs).
> > That will avoid endless problems that we never properly solved with
> > legacy drivers and the fact that Linus decided that 0 should be the
> > invalid interrupt number on all platforms
> >
> > - Provide in prom_parse.c functions for obtaining the PIC node and
> > local interrupt number of a given device based on a passed-in array
> > matching the semantics of an "interrupts" property and a parent node.
> > Along with a helper that may just take a child node. The former is
> > needed for PCI devices that have no device node. Provide a
> > pci_ppc_map_interrupt() that takes a pci_dev and does the interrupt
> > mapping, either by using the standard OF approach if a device-node is
> > present, or walking up the PCI tree while doing standard swizzling until
> > it reaches a device node
>
> How is this different from the current use of map_interrupt() in
> finish_node_interrupts()?
Slightly... basically cleaned up version of it.
> It seems to me that it would be better to have the struct device_node
> store the raw interrupt vector data as presented in the dev tree
> (without remapping) along with a pointer to the struct device_node for
> the appropriate PIC.
I don't understand what you have in mind. Remember we are working with
cases where devices may not have a node. There is no such thing as "an
interrupt == a node" anyway. Beside, I want to _remove_ anything in
struct device_node that isn't specifically the node linkage and property
list. All the pre-parsed junk has to go.
> Later on, when we need to provide interrupt lines to the PCI device
> structures (e.g. pci_read_irq_line()) we have the PIC and the raw
> interrupt vectors identified and we ask the PIC to provide us with a
> kernel/virt IRQ.
Yah, well, in order to have the PIC and the raw IRQ identified, we have
to do the algorithm I described :) Not sure how your scheme differs
except maybe by putting things in the device node itself... We do have a
void * there though we can use for non-PCI devices, thus if the PIC node
is always guaranteed _not_ to be a PCI device, we can use that to get
the PIC quickly but old MPICs are PCI devices afaik, and beside, that is
not a performance critical path.
> Deferring the remapping of the interrupt vectors to this later time
> should allow for some simplification opportunities. All code that
> handles device nodes would not need to deal with offsets or remapping,
I still don't see what you mean here.... the only things that has to
deal with offset and/or remapping are the PIC code itself when it gets
called with virtual numbers and the binding of a device to an irq when
going from the raw number to the virtual number.
> only when IRQ information crosses the boundary between powerpc and
> generic code would one need to be aware of the need to re-map (i.e.
> dev->irq = ??? and ppc_md.get_irq(regs);/ __do_IRQ() interactions ).
> Since arbitrary re-mappings need to be supported, the reservation of
> vectors 0..15 can be hidden as a re-mapping implementation detail.
> Consequently one could eliminate irq_offset_up() and irq_offset_down()
> altogether.
I'm not sure how your scheme differs from what I have in mind at this
point except from the fact that you'll shuffle interrupt numbers way
more than I intend to. I suppose it _might_ be simpler to go through the
virt irq remapper once rather than having both a set of ranges +
eventually the remapper, and I've thought about using the remapper for
everything too, but I'd still like to keep the concept of ranges, thus
I'm tempted to still allocate all irqs for a given controller
continuously in the remapper when instanciating the PIC rather than when
actually looking for IRQs....
Ben.
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: Andy Fleming @ 2006-05-30 22:10 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000201c68335$7c594b90$5201a8c0@GEG2400>
Couldn't you use a work_queue? For the PHY Layer, the MDIO
transactions can't occur at interrupt time (they need to be
interruptible), so the interrupt handler calls schedule_work() to get
the interrupt handled. I'm not sure how much faster it is (if at
all), but it's another method, and sounds less complicated than
waiting on a semaphore.
Of course, I would suggest trying to avoid the buffer allocation
functions you are using, or defer the work using NAPI, but it's
impossible for me to tell whether that's a reasonable solution for you.
On May 29, 2006, at 10:35, Laurent Lagrange wrote:
>
> Hello everybody,
>
> I'm writing a custom network driver based on a MPC8260 FCC device
> for a
> 2.6.9 linux kernel.
> In this driver, I need to use specific buffer allocation functions
> which use
> down and up semaphore functions.
>
> As the interrupt handler can't be scheduled, I have made a kernel
> thread
> which waits forever on a semaphore.
> This semaphore is set when a received packet interrupt occured. All
> that
> mechanism works but the performances
> are very poor.
>
> Is there any solution to increase the kthread priority in the
> scheduler ?
> Is there another solution than the semaphore to quickly wake up a
> kthread ?
>
> Thanks a lot for your help.
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: fs_enet segfaults when adding network interface to bridge
From: Andy Fleming @ 2006-05-30 21:54 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605301539.55319.laurent.pinchart@tbox.biz>
On May 30, 2006, at 08:39, Laurent Pinchart wrote:
>>> Hi everybody,
>>>
>>> I ran into a segfault in the fs_enet driver when adding the network
>>> interface to an ethernet bridge. This only happens when the
>>> interface is
>>> down.
>>>
>>> ----- Kernel version -----
>>> Linux tbox-cp11 2.6.17-rc3-g7f02f290-dirty #549 Tue May 30
>>> 13:25:37 CEST
>>> 2006 ppc unknown
>>> (from main linux-2.6 git repository)
>>> ----- End of kernel version -----
>>>
>>> ----- Oops report -----
>>> Oops: kernel access of bad area, sig: 11 [#1]
>>> NIP: C0109884 LR: C010D420 CTR: 00000000
>>> REGS: c027d7f0 TRAP: 0300 Tainted: P (2.6.17-rc3-
>>> g7f02f290-dirty)
>>> MSR: 00009032 <EE,ME,IR,DR> CR: 24000222 XER: 00000000
>>> DAR: 00000140, DSISR: 20000000
>>> TASK = c0851090[42] 'brctl' THREAD: c027c000
>>> GPR00: C010D414 C027D8A0 C0851090 00000000 C027D8D0 FFFFFFFF
>>> F00000A0
>>> EFFFFFFF GPR08: C026E380 C0210000 00000000 C0230000 C0210000
>>> 1001D150
>>> 00FFE000 00000001 GPR16: FFFFFFFF 00000000 007FFF00 7FDD0AC0
>>> 00000000
>>> 10072C94 7FDD0AD8 10072CA4 GPR24: 00000000 10000A48 00000000
>>> C027D8D0
>>> C027D8D0 C08A1A60 C027DC50 C08A1800 NIP [C0109884]
>>> phy_ethtool_gset+0x0/0x48
>>> LR [C010D420] fs_get_settings+0x34/0x48
>>> Call Trace:
>>> [C027D8A0] [C010D414] fs_get_settings+0x28/0x48 (unreliable)
>>> [C027D8C0] [C013DDC0] dev_ethtool+0x9bc/0x13c8
>>> [C027DC40] [C018CBC0] port_cost+0x58/0x108
>>> [C027DCB0] [C018D3E8] br_add_if+0x174/0x2f4
>>> [C027DCE0] [C018D9AC] add_del_if+0x94/0x98
>>> [C027DD00] [C018DD68] br_dev_ioctl+0x70/0xae4
>>> [C027DE00] [C013B42C] dev_ifsioc+0x17c/0x404
>>> [C027DE20] [C013BA4C] dev_ioctl+0x398/0x4e8
>>> [C027DEB0] [C012EEFC] sock_ioctl+0x154/0x220
>>> [C027DEE0] [C0067164] do_ioctl+0x88/0x9c
>>> [C027DEF0] [C0067230] vfs_ioctl+0xb8/0x3f0
>>> [C027DF10] [C00675A8] sys_ioctl+0x40/0x74
>>> [C027DF40] [C00040E0] ret_from_syscall+0x0/0x38
>>> Instruction dump:
>>> 7c0803a6 4e800020 2f800000 409eff78 4bffffb8 8804000e 2b800001
>>> 40bdff70
>>> 3860ffea 4bffffd4 61200040 4bffff84 <81230140> 91240004 80030144
>>> 90040008
>>> ----- End of oops report -----
>>>
>>> ----- Source lines -----
>>> [C0109884] phy_ethtool_gset+0x0/0x48 (drivers/net/phy/phy.c:290)
>>> [C010D414] fs_get_settings+0x28/0x48
>>> (drivers/net/fs_enet/fs_enet-main.c:885) [C013DDC0]
>>> dev_ethtool+0x9bc/0x13c8 (net/core/ethtool.c:122)
>>> [C018CBC0] port_cost+0x58/0x108 (net/bridge/br_if.c:54)
>>> ----- End of source lines -----
>>>
>>> phy_ethtool_gset segfaults when trying to access phydev->supported
>>> because phydev is NULL.
>>>
>>> As I'm not familiar with the fs_enet driver, I'm looking for advices
>>> regarding what to fix and how to fix it.
>>
>> IIRC, fs_enet got bound to phydev only being ->up. So in down
>> state, phydev
>> may be either null, or last assigned (need to have a look into
>> source to
>> tell for certain). So what is the proper behavior from your point
>> of view?
>
> I have no idea :-) What I know is that the driver should not
> segfault when
> asked to report the port speed. Either we should return an error or
> have the
> phy device bound to fs_enet at all time. It might also be a bridge
> issue,
> maybe the bridge code should turn the interface up before reading
> its speed.
> How do other ethernet drivers proceed ?
Well, gianfar only invokes phy_ethtool_gset() after checking to see
that phydev is not NULL. fs_enet should do this as well. It may be
preferable to move that check into phy_ethtool_gset(). Certainly a
workable solution, though I'm inclined to feel that the PHY layer
should be able to assume that a given PHY exists. The sort of
problem also exists if you try to use ethtool to find the ring sizes
before the device has been opened.
Anyway, the easy fix is for fs_enet to check for NULL before calling
phy_ethtool_gset().
Andy
^ permalink raw reply
* Re: execve of /sbin/init fails
From: Steve Iribarne (GMail) @ 2006-05-30 21:29 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6DE@de01exm68.ds.mot.com>
On 5/30/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
>
>
>
> 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.
Hmm.. Ok.. so I've read the other suggestions all good, but I think we
are missing some info. Are you running Busybox? If you are using
Busybox, what version? Also, what init are you using? Are you using
busyboxes?
The ramdisk suggestion was a good one. First off, check what is in
your ramdisk. Also check the rights of the files in the ramdisk.
Make sure you have the execute bit set. I've seen exactly what you
are seeing when my rights on the file init were messed up.
Also I think I've seen a hang with an older version of Busybox using
their version of init. I just got sysinit and that seemed to fix it,
(Although I had to reconfig Busybox to not use their version of init)
> The processor just hangs and there is no output on the terminal.
When you say the process just "hangs", where are you in the boot
cycle? Is it before you see the linux kernel starting to load? Or do
you see any kernel messages start to spew out?
Hope this helps a little.
-stv
^ permalink raw reply
* Re: execve of /sbin/init fails
From: Andy Gospodarek @ 2006-05-30 21:15 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D6DE@de01exm68.ds.mot.com>
You could also try compiling init statically. I've had success with
that in the past until I figured out what the actual problem was.
On 5/30/06, Anantharaman Chetan-W16155
<Chetan.S.Anantharaman@motorola.com> wrote:
>
>
>
>
> 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.
>
>
>
> 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
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