* 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
* 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
* 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
* >=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
* 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
* 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
* 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
* 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
* [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
* 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
* 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: [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: 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
* 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: 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
* 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: 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
* 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: 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
* 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: Collecting hypervisor call stats
From: Paul Mackerras @ 2006-05-31 22:40 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev
In-Reply-To: <20060531204144.GA7909@w-mikek2.ibm.com>
Mike Kravetz writes:
> 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.
I suspect that's a very old comment. :)
> 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.
I think that gathering those statistics would be useful. I suggest
you use a per-cpu array for them, to reduce the performance impact.
Paul.
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Mike Kravetz @ 2006-05-31 22:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17534.7026.169023.420733@cargo.ozlabs.ibm.com>
On Thu, Jun 01, 2006 at 08:40:50AM +1000, Paul Mackerras wrote:
> I think that gathering those statistics would be useful. I suggest
> you use a per-cpu array for them, to reduce the performance impact.
Yes, that is a must do.
We need to get a timestamp before and after the call. mftb should do
the trick. Also, I'd prefer to have the code that stuffs the values
into the array be C. So, the decision is to have the assembly code
call out to the C routine -OR- create wrappers for the assembly routines.
I much prefer C wrappers to touching the assembly.
--
Mike
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Becky Bruce @ 2006-05-31 23:06 UTC (permalink / raw)
To: Assaf Hoffman; +Cc: linuxppc-embedded, Rita Shtern, Ronen Shitrit
In-Reply-To: <B9FFC3F97441D04093A504CEA31B7C41A62B2F@msilexch01.marvell.com>
I think we need to hold off on this particular patch for a few days.
I took a look at the manual section you're referencing here, and sure
enough, it says that you shouldn't set both bits in the same mtspr
instruction. The manual says this in more than one place, in fact.
However, that seemed a little bit odd to me, so I talked with a few
of the hardware designers for the 745x family. They assure me that
the manual statement is false. The normal code that sets ICE/ICFI/
DCE/DCFI all on one mtspr should be fully functional on this
processor family. I'm still working on confirming this and getting
some history on *why* the manual says that, but for now I'd say it's
a pretty good bet that the manual is in error. I will let you know
if I find out this is not the case.
You are correct, though, in that an isync is needed prior to the
write of HID0[ICE]. It's probably missing because it's not listed in
the synchronization table in chapter 2 of the manual.
For what it's worth, as soon as I can confirm this, I will make sure
the publications team here at Freescale is made aware of the error so
it can be corrected in the next printing of the manual. I will also
have the synchronization table updated as it also has incorrect
information.
Thanks,
B
^ permalink raw reply
* RE: Linux 2.4 Kernel on Xilinx Virtex4 FX100's PPC
From: Anantharaman Chetan-W16155 @ 2006-05-31 23:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605311235n171f889g135e074685b578bc@mail.gmail.com>
Grant,=20
Can you please provide a link or perhaps point me to the app node that
Xilinx has to modify linuxppc-2.4 tree for V4-FX.
Thanks,=20
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: pmf_register_irq_client gives sleep with locks held warning
From: Benjamin Herrenschmidt @ 2006-06-01 0:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1149020341.5128.7.camel@johannes>
On Tue, 2006-05-30 at 22:19 +0200, Johannes Berg wrote:
> 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]
That's a bug in the PowerMac PMF code. What about this patch ?
This fixes request_irq() potentially called from atomic context.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/platforms/powermac/pfunc_core.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/pfunc_core.c 2006-04-19 15:04:38.000000000 +1000
+++ linux-work/arch/powerpc/platforms/powermac/pfunc_core.c 2006-06-01 10:58:57.000000000 +1000
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <asm/semaphore.h>
#include <asm/prom.h>
@@ -546,6 +547,7 @@
static LIST_HEAD(pmf_devices);
static spinlock_t pmf_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_MUTEX(pmf_irq_mutex);
static void pmf_release_device(struct kref *kref)
{
@@ -864,15 +866,17 @@
spin_lock_irqsave(&pmf_lock, flags);
func = __pmf_find_function(target, name, PMF_FLAGS_INT_GEN);
- if (func == NULL) {
- spin_unlock_irqrestore(&pmf_lock, flags);
+ if (func)
+ func = pmf_get_function(func);
+ spin_unlock_irqrestore(&pmf_lock, flags);
+ if (func == NULL)
return -ENODEV;
- }
+ mutex_lock(&pmf_irq_mutex);
if (list_empty(&func->irq_clients))
func->dev->handlers->irq_enable(func);
list_add(&client->link, &func->irq_clients);
client->func = func;
- spin_unlock_irqrestore(&pmf_lock, flags);
+ mutex_unlock(&pmf_irq_mutex);
return 0;
}
@@ -881,16 +885,16 @@
void pmf_unregister_irq_client(struct pmf_irq_client *client)
{
struct pmf_function *func = client->func;
- unsigned long flags;
BUG_ON(func == NULL);
- spin_lock_irqsave(&pmf_lock, flags);
+ mutex_lock(&pmf_irq_mutex);
client->func = NULL;
list_del(&client->link);
if (list_empty(&func->irq_clients))
func->dev->handlers->irq_disable(func);
- spin_unlock_irqrestore(&pmf_lock, flags);
+ mutex_unlock(&pmf_irq_mutex);
+ pmf_put_function(func);
}
EXPORT_SYMBOL_GPL(pmf_unregister_irq_client);
^ 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