* Re: [PATCH] Add support for Analogue & Micro ASP837E board
From: Bryan O'Donoghue @ 2008-05-06 23:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <8D90346B-3E16-4B77-BFF0-35F1FAA1B2B8@kernel.crashing.org>
On Tue, 6 May 2008 08:37:16 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
/;
> > +
> > +/ {
> > + model = "ASP8347E";
> > + compatible = "ASP8347E";
>
> "analogue-and-micro, ASP8347E";
Fair enough.
> > + memory {
> > + device_type = "memory";
> > + reg = <0x00000000 0x8000000>; // 128MB at 0
>
> is memory really fixed on this board or does the bootloader set this
> if, dynamic make it <0 0>
It's fixed as far as I know.
> > + soc8349@ff000000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
> > + ranges = <0x0 0xff000000 0xff100000>;
>
> this is wrong, size should be like 0x100000
Agreed - typo !
> > + enet0: ethernet@24000 {
> > + cell-index = <0>;
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
> > + reg = <0x24000 0x1000>;
> > + local-mac-address = [ 00 08 e5 11 32 33 ];
> > + interrupts = <32 0x8 33 0x8 34 0x8>;
> > + interrupt-parent = <&ipic>;
> > + phy-handle = <&phy0>;
> > + linux,network-index = <0>;
>
> you shouldn't need this anymore. we should be using the aliases.
Aliases sound good to me. Don't know too much about how this should be defined
in a dts though, do you have an example I could use as a base for reference ?
Cheers.
^ permalink raw reply
* [PATCH 1/2] [POWERPC] Fix bogus paca->_current initialization
From: Benjamin Herrenschmidt @ 2008-05-07 0:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
When doing lockdep, I had two patches to initialize paca->_current
early. One bogus, and one correct. Unfortunately both got merged
as the bad one ended up being part of the main lockdep patch by
mistake. This causes memory corruption at boot. This patch removes
the offending code.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/head_64.S | 4 ----
1 file changed, 4 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-05-07 09:54:17.000000000 +1000
+++ linux-work/arch/powerpc/kernel/head_64.S 2008-05-07 09:54:23.000000000 +1000
@@ -1517,10 +1517,6 @@ _INIT_STATIC(start_here_multiplatform)
addi r2,r2,0x4000
add r2,r2,r26
- /* Set initial ptr to current */
- LOAD_REG_IMMEDIATE(r4, init_task)
- std r4,PACACURRENT(r13)
-
/* Do very early kernel initializations, including initial hash table,
* stab and slb setup before we turn on relocation. */
^ permalink raw reply
* [PATCH 2/2] [POWERPC] Document when printk is useable
From: Benjamin Herrenschmidt @ 2008-05-07 0:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
When debugging early boot problems, it's common to sprinkle printk's
all over the place. However, on powerpc 64 bits, this can lead to
memory corruption if done too early due to the PACA pointer and
lockdep core not being initialized.
This adds some comments to early_setup() that document when it is
safe to do so in order to save time to whoever has to debug that
stuff next.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/setup_64.c | 4 ++++
1 file changed, 4 insertions(+)
--- linux-work.orig/arch/powerpc/kernel/setup_64.c 2008-05-07 09:54:52.000000000 +1000
+++ linux-work/arch/powerpc/kernel/setup_64.c 2008-05-07 09:56:31.000000000 +1000
@@ -170,6 +170,8 @@ void __init setup_paca(int cpu)
void __init early_setup(unsigned long dt_ptr)
{
+ /* -------- printk is _NOT_ safe to use here ! ------- */
+
/* Fill in any unititialised pacas */
initialise_pacas();
@@ -185,6 +187,8 @@ void __init early_setup(unsigned long dt
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
+ /* -------- printk is now safe to use ------- */
+
DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
/*
^ permalink raw reply
* [PATCH] [POWERPC] Initialize lockdep earlier
From: Benjamin Herrenschmidt @ 2008-05-07 0:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This moves lockdep_init() to before udbg_early_init() as the later
can call things that acquire spinlocks etc... This also makes printk
safer to use earlier.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/setup_64.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/setup_64.c 2008-05-07 10:23:35.000000000 +1000
+++ linux-work/arch/powerpc/kernel/setup_64.c 2008-05-07 10:23:45.000000000 +1000
@@ -181,14 +181,14 @@ void __init early_setup(unsigned long dt
/* Assume we're on cpu 0 for now. Don't write to the paca yet! */
setup_paca(0);
- /* Enable early debugging if any specified (see udbg.h) */
- udbg_early_init();
-
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
/* -------- printk is now safe to use ------- */
+ /* Enable early debugging if any specified (see udbg.h) */
+ udbg_early_init();
+
DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
/*
^ permalink raw reply
* jffs2 on imx21ads board
From: Nethra @ 2008-05-07 2:35 UTC (permalink / raw)
To: linuxppc-dev
hi all,
I m using imx21ads board, Bootloader is Redboot.
linux is linux-2.6.22 version. Board with Jffs2 root filesystem as root is
not working.
But Ramdisk booting is working...so i tried to mount jffs2 root file system
after
booting board with ramdisk using mount command. It boots up with some error
message as given below.
With df command it shows 100%...
mx27# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "Bootloader"
mtd1: 00200000 00040000 "nor.Kernel1"
mtd2: 00200000 00040000 "nor.kernel2"
mtd3: 00d00000 00040000 "nor.rootfs1"
mtd4: 00d00000 00040000 "nor.rootfs2"
mtd5: 00040000 00040000 "Parameter"
mtd6: 00003000 00010000 "FIS directory"
mtd7: 00001000 00010000 "Redboot config"
mx27# cd /dev/
/dev/input/ /dev/net/ /dev/pts/ /dev/shm/
mx27# mount -t jffs2 /dev/mtdblock3 /mnt
<6>MTDSB: dev_name "/dev/mtdblock3"
[ 27.820000] MTDSB: path_lookup() returned 0, inode c3c50100
[ 27.820000] MTDSB: New superblock for device 3 ("nor.rootfs1")
mx27# [ 30.240000] Erase at 0x00b80000 failed immediately: -EROFS. Is the
sector locked?
[ 30.240000] Erase at 0x00b40000 failed immediately: -EROFS. Is the sector
locked?
[ 30.250000] Erase at 0x00b00000 failed immediately: -EROFS. Is the sector
locked?
[ 30.260000] Erase at 0x00ac0000 failed immediately: -EROFS. Is the sector
locked?
[ 30.270000] Erase at 0x00a80000 failed immediately: -EROFS. Is the sector
locked?
[ 30.270000] Erase at 0x00a40000 failed immediately: -EROFS. Is the sector
locked?
[ 30.280000] Erase at 0x00a00000 failed immediately: -EROFS. Is the sector
locked?
[ 30.290000] Erase at 0x009c0000 failed immediately: -EROFS. Is the sector
locked?
[ 30.300000] Erase at 0x00980000 failed immediately: -EROFS. Is the sector
locked?
[ 30.300000] Erase at 0x00940000 failed immediately: -EROFS. Is the sector
locked?
[ 30.310000] Erase at 0x00900000 failed immediately: -EROFS. Is the sector
locked?
[ 30.320000] Erase at 0x008c0000 failed immediately: -EROFS. Is the sector
locked?
[ 30.330000] Erase at 0x00880000 failed immediately: -EROFS. Is the sector
locked?
[ 30.340000] Erase at 0x00840000 failed immediately: -EROFS. Is the sector
locked?
[ 30.340000] Erase at 0x00800000 failed immediately: -EROFS. Is the sector
locked?
[ 30.350000] Erase at 0x007c0000 failed immediately: -EROFS. Is the sector
locked?
[ 30.360000] Erase at 0x00780000 failed immediately: -EROFS. Is the sector
locked?
[ 30.370000] Erase at 0x00740000 failed immediately: -EROFS. Is the sector
locked?
[ 30.370000] Erase at 0x00700000 failed immediately: -EROFS. Is the sector
locked?
[ 30.380000] Erase at 0x006c0000 failed immediately: -EROFS. Is the sector
locked?
[ 30.390000] Erase at 0x00680000 failed immediately: -EROFS. Is the sector
locked?
[ 30.400000] Erase at 0x00640000 failed immediately: -EROFS. Is the sector
locked?
[ 30.410000] Erase at 0x00600000 failed immediately: -EROFS. Is the sector
locked?
[ 30.410000] Erase at 0x005c0000 failed immediately: -EROFS. Is the sector
locked?
[ 30.420000] Erase at 0x00580000 failed immediately: -EROFS. Is the sector
locked?
[ 30.430000] Erase at 0x00540000 failed immediately: -EROFS. Is the sector
locked?
[ 30.440000] Erase at 0x00500000 failed immediately: -EROFS. Is the sector
locked?
[ 30.440000] Erase at 0x004c0000 failed immediately: -EROFS. Is the sector
locked?
mx27#
mx27#
mx27# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/ram0 7280 4963 1948 72% /
df: /mnt/rwfs: No such file or directory
rwfs 512 232 280 45% /tmp
rwfs 512 232 280 45% /etc
rwfs 512 232 280 45% /var
shm 31560 0 31560 0% /dev/shm
/dev/mtdblock3 13312 13312 0 100% /mnt
mx27#
mx27#
waiting for inputs
tnks,
Nethra
--
View this message in context: http://www.nabble.com/jffs2-on-imx21ads-board-tp17093824p17093824.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: jffs2 on imx21ads board
From: Wolfgang Denk @ 2008-05-07 6:32 UTC (permalink / raw)
To: Nethra; +Cc: linuxppc-dev
In-Reply-To: <17093824.post@talk.nabble.com>
In message <17093824.post@talk.nabble.com> you wrote:
>
> I m using imx21ads board, Bootloader is Redboot.
> linux is linux-2.6.22 version. Board with Jffs2 root filesystem as root is
> not working.
Argh.. You really are ignoring all good advice, aren't you?
After you have been told that this posting wa soff topic on the U-Boot
list and your hsould ask on the ARM mailing list instead, you now post
it again on a PowerPC list?
What makes you think i.MX21 related topics would fit here?
You are off topic again!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Human beings were created by water to transport it uphill.
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-05-07 7:50 UTC (permalink / raw)
To: Andy Fleming; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <C24AB05C-E10D-47F1-A605-C30D4093699C@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
Hi Andy,
On Tue, May 06, 2008 at 05:54:02PM -0500, Andy Fleming wrote:
>> Now back to the first an bigger problem :
>> currently, I have an "old" U-boot and I have written myself a dts file.
>>
>> Problem is : ethernet does not work, but that's not a mac-address problem,
>> but something else that I do not understand yet. The symptom is I get
>>
>> ip route add default via 192.168.85.33 dev eth0
>> RTNETLINK answers: Network is unreachable
>>
>> I surmise this is because my eth0 does not become up, and I surmise
>> again this is because there is no driver selected to drive the phy.
>>
>> In my arch/ppc setup this was automagically handled by fixed@100:1 IIRC
>>
>> Is there something I can put in my dts file to activate a driver for my
>> phy ?
>>
>> Best regards
>
> This slipped under my radar, and I'm only just now finding it again. Have
> your issues been resolved?
This has actually not been resolved as such, but we use now the newest
U-boot version which is dtb-aware, and linux-2.6.25-rc6, and that together
fixes the ethernet problem.
> If not, could you send a bit more of the boot
> log? There should be a little more if the PHY was not found. If you were
> operating with a fixed PHY setup before, then the generic PHY driver (which
> will automatically bind to your PHY) should suffice unless your MDIO bus is
> broken.
>
> Andy
Of course, the dts file also has changed, because it is now filled by
U-boot. I have attached it here for info.
Thanks
Philippe
PS:
What's the recommended way to make a powerpc patch (e.g. my defconfig) appear
in the official kernel sources ? Should I send it to linuxppc-dev@ozlabs.org,
lkml or somewhere else ?
[-- Attachment #2: macq_image_processor.dts --]
[-- Type: text/plain, Size: 4814 bytes --]
/*
* MPC8540 ADS Device Tree Source - Modified by DEVELTECH for MACQ_IMAGE_PROCESSOR
*
* Copyright 2006 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = "MACQ_IMAGE_PROCESSOR";
compatible = "MPC8540ADS", "MPC85xxADS";
#address-cells = <1>;
#size-cells = <1>;
aliases {
ethernet0 = &enet0;
serial0 = &serial0;
pci0 = &pci0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8540@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33.3333 MHz, from uboot
bus-frequency = <0>; // 166 MHz
clock-frequency = <0>; // 666, 833 or 1000 MHz, from uboot
};
};
memory {
device_type = "memory";
reg = <00000000 10000000>; // 256M at 0x0
};
soc8540@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00100000>; // CCSRBAR 1M
bus-frequency = <0>;
memory-controller@2000 {
compatible = "fsl,8540-memory-controller";
reg = <2000 1000>;
interrupt-parent = <&mpic>;
interrupts = <12 2>;
};
l2-cache-controller@20000 {
compatible = "fsl,8540-l2-cache-controller";
reg = <20000 1000>;
cache-line-size = <20>; // 32 bytes
cache-size = <40000>; // L2, 256K
interrupt-parent = <&mpic>;
interrupts = <10 2>;
};
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <2b 2>;
interrupt-parent = <&mpic>;
dfsrr;
rtc@68 {
device_type = "rtc";
compatible = "stm,m41t81";
reg = <68>;
};
temp-sensor@4c {
device_type = "temp-sensor";
compatible = "ns,lm63";
reg = <4c>;
};
temp-sensor@48 {
device_type = "temp-sensor";
compatible = "ns,lm75";
reg = <48>;
};
};
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <24520 20>;
phy0: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <4 1>;
reg = <1>;
device_type = "ethernet-phy";
};
};
enet0: ethernet@26000 {
cell-index = <0>;
device_type = "network";
model = "FEC";
compatible = "gianfar";
reg = <26000 1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <29 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy0>;
};
serial0: serial@4500 {
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>; // reg base, size
clock-frequency = <0>; // should we fill in in uboot?
interrupts = <2a 2>;
interrupt-parent = <&mpic>;
};
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
reg = <21300 4>;
ranges = <0 21100 200>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <0 80>;
cell-index = <0>;
interrupt-parent = <&mpic>;
interrupts = <14 2>;
};
dma-channel@80 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <80 80>;
cell-index = <1>;
interrupt-parent = <&mpic>;
interrupts = <15 2>;
};
dma-channel@100 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <100 80>;
cell-index = <2>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
};
dma-channel@180 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <180 80>;
cell-index = <3>;
interrupt-parent = <&mpic>;
interrupts = <17 2>;
};
};
};
pci0: pci@e0008000 {
cell-index = <0>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x12 */
9000 0 0 1 &mpic 5 1
9000 0 0 2 &mpic 6 1
9000 0 0 3 &mpic 7 1
9000 0 0 4 &mpic 8 1>;
interrupt-parent = <&mpic>;
interrupts = <18 2>;
bus-range = <0 0>;
ranges = <02000000 0 80000000 80000000 0 20000000
01000000 0 00000000 e2000000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e0008000 1000>;
compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
device_type = "pci";
};
};
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Stephen Rothwell @ 2008-05-07 7:54 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080507075048.GA24827@frolo.macqel>
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
Hi Philippe,
On Wed, 7 May 2008 09:50:48 +0200 Philippe De Muyter <phdm@macqel.be> wrote:
>
> What's the recommended way to make a powerpc patch (e.g. my defconfig) appear
> in the official kernel sources ? Should I send it to linuxppc-dev@ozlabs.org,
> lkml or somewhere else ?
linuxppc-dev would be the best place.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* powerpc port for sbc8260-based board problem
From: Boris Shteinbock @ 2008-05-07 8:31 UTC (permalink / raw)
To: linuxppc-dev
Hi.
I am doing a port from ppc to powerpc ARCH on sbc8260 based board.
The problem is, that I can't get SMC1 UART to work.
After SMC console is initialized.
cpm_uart_console_write() hangs here
/* Wait for transmitter fifo to empty.
* Ready indicates output is ready, and xmt is doing
* that, not that it is ready for us to send.
*/
while ((in_be16(&bdp->cbd_sc) & BD_SC_READY) != 0)
;
I am using dts tree modified from ep8248 port since it is the only one that has smc description in it. :
brg@119f0 {
compatible = "fsl,mpc8260-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
clock-frequency = <135000000>;
};
/* Monitor port/SMC1 */
smc1: serial@11a80 {
device_type = "serial";
compatible = "fsl,mpc8260-smc-uart",
"fsl,cpm2-smc-uart";
reg = <0x11a80 0x20 0x1100 0x40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x1d000000>;
linux,my-label = "SMC1";
};
I checked a BRG settings against working u-boot configuration and they are the same. Anyway a wrong BRG setting wouldn't hang this loop
So I have a few questions.
If someone has done sbc8260 dts tree and port to "powerpc" already, I'd be very grateful if he can share it with me.
I couldn't find anything on the internet.
Can someone, also, explain, how "fsl, cpm-command" field works, booting-without-of document doesn't provide much information.
I feel, that just copying this value from ep8248.dts isn't right somehow.
Thank you
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
^ permalink raw reply
* RE: [PATCH 4/4] booting-without-of for Freescale MSI
From: Jin Zhengxiong @ 2008-05-07 9:35 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <d731595be98f00bf5387444b88de4883@kernel.crashing.org>
> >
> > Thanks for your input. I think the name "fsl,MPIC-MSI" and=20
> > "fsl,IPIC-MSI"
> > is somethind specific.
>=20
> This is the third MSI-on-MPIC I've seen, and I doubt it will=20
> be the last. It is likely FSL will make some different one=20
> in the future, as well.
>=20
This is the first patch for the FSL MSI support, I wish it can be
used for most of the freescale board if the PIC is still MPIC or IPIC.
> Please don't use generic names for specific devices.
>=20
How about using "fsl,85xx-MSI" for 85xx board, "fsl,86xx-MSI" for
86xx board and so on.
Jason
^ permalink raw reply
* Re: jffs2 and unaligned access
From: David Woodhouse @ 2008-05-07 10:53 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20080507102724.GE4326@pengutronix.de>
On Wed, 2008-05-07 at 12:27 +0200, Sascha Hauer wrote:
> memcpy_from/to_io() use word aligned accesses on the io side of memory.
> The MPC5200 local plus bus where our flashes are connected does not
> allow unaligned accesses, so we have to use the io versions of memcpy.
But this region of flash is marked as suitable for execute-in-place,
otherwise the point() function wouldn't be working to give a direct
pointer to it. It sounds like we shouldn't be allowing that.
Which in turn means that perhaps we should have a property in the
corresponding node in the device-tree which indicates that it's not
suitable for direct access?
--
dwmw2
^ permalink raw reply
* [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
From: Stefan Roscher @ 2008-05-07 11:19 UTC (permalink / raw)
To: Roland Dreier, LKML, LinuxPPC-Dev, OF-EWG; +Cc: fenkes, raisch
This is necessary because, in a multicore environment, a race between
uverbs async handler and destroy QP could occur.
Signed-off-by: Stefan Roscher <stefan.roscher at de.ibm.com>
---
We are not sure if this should be fixed in the driver or in uverbs itself.
Roland, what's your opinion about this?
drivers/infiniband/hw/ehca/ehca_classes.h | 2 ++
drivers/infiniband/hw/ehca/ehca_irq.c | 4 ++++
drivers/infiniband/hw/ehca/ehca_qp.c | 5 +++++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 00bab60..1e9e99a 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -192,6 +192,8 @@ struct ehca_qp {
int mtu_shift;
u32 message_count;
u32 packet_count;
+ atomic_t nr_events; /* events seen */
+ wait_queue_head_t wait_completion;
};
#define IS_SRQ(qp) (qp->ext_type == EQPT_SRQ)
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c b/drivers/infiniband/hw/ehca/ehca_irq.c
index ca5eb0c..ce1ab05 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -204,6 +204,8 @@ static void qp_event_callback(struct ehca_shca *shca, u64 eqe,
read_lock(&ehca_qp_idr_lock);
qp = idr_find(&ehca_qp_idr, token);
+ if (qp)
+ atomic_inc(&qp->nr_events);
read_unlock(&ehca_qp_idr_lock);
if (!qp)
@@ -223,6 +225,8 @@ static void qp_event_callback(struct ehca_shca *shca, u64 eqe,
if (fatal && qp->ext_type == EQPT_SRQBASE)
dispatch_qp_event(shca, qp, IB_EVENT_QP_LAST_WQE_REACHED);
+ if (atomic_dec_and_test(&qp->nr_events))
+ wake_up(&qp->wait_completion);
return;
}
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index 18fba92..d550200 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -566,6 +566,8 @@ static struct ehca_qp *internal_create_qp(
return ERR_PTR(-ENOMEM);
}
+ atomic_set(&my_qp->nr_events, 0);
+ init_waitqueue_head(&my_qp->wait_completion);
spin_lock_init(&my_qp->spinlock_s);
spin_lock_init(&my_qp->spinlock_r);
my_qp->qp_type = qp_type;
@@ -1934,6 +1936,9 @@ static int internal_destroy_qp(struct ib_device *dev, struct ehca_qp *my_qp,
idr_remove(&ehca_qp_idr, my_qp->token);
write_unlock_irqrestore(&ehca_qp_idr_lock, flags);
+ /* now wait until all pending events have completed */
+ wait_event(my_qp->wait_completion, !atomic_read(&my_qp->nr_events));
+
h_ret = hipz_h_destroy_qp(shca->ipz_hca_handle, my_qp);
if (h_ret != H_SUCCESS) {
ehca_err(dev, "hipz_h_destroy_qp() failed h_ret=%li "
--
1.5.5
^ permalink raw reply related
* [PATCH 0/3] [2.6.26] ehea: Add DLPAR memory remove support
From: Hannes Hering @ 2008-05-07 12:39 UTC (permalink / raw)
To: jeff
Cc: tklein, themann, netdev, linux-kernel, raisch, ossrosch,
linuxppc-dev, ossthema
Hi,
this patchset adds memory remove hotplug support for the ehea driver.
These patches apply against kernel 2.6.26-rc1.
Regards
Hannes
^ permalink raw reply
* [PATCH 1/3] [2.6.26] memory: Introduce exports for memory notifiers
From: Hannes Hering @ 2008-05-07 12:43 UTC (permalink / raw)
To: jeff
Cc: tklein, themann, netdev, linux-kernel, raisch, ossrosch,
linuxppc-dev, ossthema
This patch introduces two exports to allow modules to use memory notifiers.
Signed-off-by: Hannes Hering <hering2@de.ibm.com>
---
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 8ce6de5..937e825 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -53,11 +53,13 @@ int register_memory_notifier(struct notifier_block *nb)
{
return blocking_notifier_chain_register(&memory_chain, nb);
}
+EXPORT_SYMBOL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
blocking_notifier_chain_unregister(&memory_chain, nb);
}
+EXPORT_SYMBOL(unregister_memory_notifier);
/*
* register_memory - Setup a sysfs device for a memory block
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/3] [2.6.26] ehea: Add dependency to Kconfig
From: Hannes Hering @ 2008-05-07 12:43 UTC (permalink / raw)
To: jeff
Cc: tklein, themann, netdev, linux-kernel, raisch, ossrosch,
linuxppc-dev, ossthema
The new ehea memory hot plug implementation depends on MEMORY_HOTPLUG.
Signed-off-by: Hannes Hering <hering2@de.ibm.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f90a86b..181cd86 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2440,7 +2440,7 @@ config CHELSIO_T3
config EHEA
tristate "eHEA Ethernet support"
- depends on IBMEBUS && INET && SPARSEMEM
+ depends on IBMEBUS && INET && SPARSEMEM && MEMORY_HOTPLUG
select INET_LRO
---help---
This driver supports the IBM pSeries eHEA ethernet adapter.
--
1.5.5.1
^ permalink raw reply related
* [PATCH 3/3] [2.6.26] ehea: Add DLPAR memory remove support
From: Hannes Hering @ 2008-05-07 12:43 UTC (permalink / raw)
To: jeff
Cc: tklein, themann, netdev, linux-kernel, raisch, ossrosch,
linuxppc-dev, ossthema
The eHEA driver uses the recently modified walk_memory_resource for powerpc
functionality to detect the memory layout. It further uses the memory hotplug
notifiers to catch memory hotplug events.
Signed-off-by: Hannes Hering <hering2@de.ibm.com>
---
diff -Nurp -X dontdiff linux-2.6.26-rc1/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.26-rc1/drivers/net/ehea/ehea.h 2008-05-03 20:59:44.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea.h 2008-05-07 14:09:50.000000000 +0200
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0090"
+#define DRV_VERSION "EHEA_0091"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -118,6 +118,13 @@
#define EHEA_MR_ACC_CTRL 0x00800000
#define EHEA_BUSMAP_START 0x8000000000000000ULL
+#define EHEA_INVAL_ADDR 0xFFFFFFFFFFFFFFFFULL
+#define EHEA_DIR_INDEX_SHIFT 13 /* 8k Entries in 64k block */
+#define EHEA_TOP_INDEX_SHIFT (EHEA_DIR_INDEX_SHIFT * 2)
+#define EHEA_MAP_ENTRIES (1 << EHEA_DIR_INDEX_SHIFT)
+#define EHEA_MAP_SIZE (0x10000) /* currently fixed map size */
+#define EHEA_INDEX_MASK (EHEA_MAP_ENTRIES - 1)
+
#define EHEA_WATCH_DOG_TIMEOUT 10*HZ
@@ -192,10 +199,20 @@ struct h_epas {
set to 0 if unused */
};
-struct ehea_busmap {
- unsigned int entries; /* total number of entries */
- unsigned int valid_sections; /* number of valid sections */
- u64 *vaddr;
+/*
+ * Memory map data structures
+ */
+struct ehea_dir_bmap
+{
+ u64 ent[EHEA_MAP_ENTRIES];
+};
+struct ehea_top_bmap
+{
+ struct ehea_dir_bmap *dir[EHEA_MAP_ENTRIES];
+};
+struct ehea_bmap
+{
+ struct ehea_top_bmap *top[EHEA_MAP_ENTRIES];
};
struct ehea_qp;
diff -Nurp -X dontdiff linux-2.6.26-rc1/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.26-rc1/drivers/net/ehea/ehea_main.c 2008-05-03 20:59:44.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-05-07 14:09:50.000000000 +0200
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <linux/memory.h>
#include <asm/kexec.h>
#include <linux/mutex.h>
@@ -3503,6 +3504,24 @@ void ehea_crash_handler(void)
0, H_DEREG_BCMC);
}
+static int ehea_mem_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ switch (action) {
+ case MEM_OFFLINE:
+ ehea_info("memory has been removed");
+ ehea_rereg_mrs(NULL);
+ break;
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block ehea_mem_nb = {
+ .notifier_call = ehea_mem_notifier,
+};
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3581,6 +3600,10 @@ int __init ehea_module_init(void)
if (ret)
ehea_info("failed registering reboot notifier");
+ ret = register_memory_notifier(&ehea_mem_nb);
+ if (ret)
+ ehea_info("failed registering memory remove notifier");
+
ret = crash_shutdown_register(&ehea_crash_handler);
if (ret)
ehea_info("failed registering crash handler");
@@ -3604,6 +3627,7 @@ int __init ehea_module_init(void)
out3:
ibmebus_unregister_driver(&ehea_driver);
out2:
+ unregister_memory_notifier(&ehea_mem_nb);
unregister_reboot_notifier(&ehea_reboot_nb);
crash_shutdown_unregister(&ehea_crash_handler);
out:
@@ -3621,6 +3645,7 @@ static void __exit ehea_module_exit(void
ret = crash_shutdown_unregister(&ehea_crash_handler);
if (ret)
ehea_info("failed unregistering crash handler");
+ unregister_memory_notifier(&ehea_mem_nb);
kfree(ehea_fw_handles.arr);
kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
diff -Nurp -X dontdiff linux-2.6.26-rc1/drivers/net/ehea/ehea_qmr.c patched_kernel/drivers/net/ehea/ehea_qmr.c
--- linux-2.6.26-rc1/drivers/net/ehea/ehea_qmr.c 2008-05-03 20:59:44.000000000 +0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.c 2008-05-07 14:09:50.000000000 +0200
@@ -31,8 +31,8 @@
#include "ehea_phyp.h"
#include "ehea_qmr.h"
+struct ehea_bmap *ehea_bmap = NULL;
-struct ehea_busmap ehea_bmap = { 0, 0, NULL };
static void *hw_qpageit_get_inc(struct hw_queue *queue)
@@ -559,125 +559,253 @@ int ehea_destroy_qp(struct ehea_qp *qp)
return 0;
}
-int ehea_create_busmap(void)
+static inline int ehea_calc_index(unsigned long i, unsigned long s)
{
- u64 vaddr = EHEA_BUSMAP_START;
- unsigned long high_section_index = 0;
- int i;
+ return (i >> s) & EHEA_INDEX_MASK;
+}
- /*
- * Sections are not in ascending order -> Loop over all sections and
- * find the highest PFN to compute the required map size.
- */
- ehea_bmap.valid_sections = 0;
-
- for (i = 0; i < NR_MEM_SECTIONS; i++)
- if (valid_section_nr(i))
- high_section_index = i;
+static inline int ehea_init_top_bmap(struct ehea_top_bmap *ehea_top_bmap,
+ int dir)
+{
+ if(!ehea_top_bmap->dir[dir]) {
+ ehea_top_bmap->dir[dir] =
+ kzalloc(sizeof(struct ehea_dir_bmap), GFP_KERNEL);
+ if (!ehea_top_bmap->dir[dir])
+ return -ENOMEM;
+ }
+ return 0;
+}
- ehea_bmap.entries = high_section_index + 1;
- ehea_bmap.vaddr = vmalloc(ehea_bmap.entries * sizeof(*ehea_bmap.vaddr));
+static inline int ehea_init_bmap(struct ehea_bmap *ehea_bmap, int top, int dir)
+{
+ if(!ehea_bmap->top[top]) {
+ ehea_bmap->top[top] =
+ kzalloc(sizeof(struct ehea_top_bmap), GFP_KERNEL);
+ if (!ehea_bmap->top[top])
+ return -ENOMEM;
+ }
+ return ehea_init_top_bmap(ehea_bmap->top[top], dir);
+}
+
+static int ehea_create_busmap_callback(unsigned long pfn,
+ unsigned long nr_pages, void *arg)
+{
+ unsigned long i, mr_len, start_section, end_section;
+ start_section = (pfn * PAGE_SIZE) / EHEA_SECTSIZE;
+ end_section = start_section + ((nr_pages * PAGE_SIZE) / EHEA_SECTSIZE);
+ mr_len = *(unsigned long *)arg;
- if (!ehea_bmap.vaddr)
+ ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
+ if (!ehea_bmap)
return -ENOMEM;
- for (i = 0 ; i < ehea_bmap.entries; i++) {
- unsigned long pfn = section_nr_to_pfn(i);
+ for (i = start_section; i < end_section; i++) {
+ int ret;
+ int top, dir, idx;
+ u64 vaddr;
+
+ top = ehea_calc_index(i, EHEA_TOP_INDEX_SHIFT);
+ dir = ehea_calc_index(i, EHEA_DIR_INDEX_SHIFT);
- if (pfn_valid(pfn)) {
- ehea_bmap.vaddr[i] = vaddr;
- vaddr += EHEA_SECTSIZE;
- ehea_bmap.valid_sections++;
- } else
- ehea_bmap.vaddr[i] = 0;
+ ret = ehea_init_bmap(ehea_bmap, top, dir);
+ if(ret)
+ return ret;
+
+ idx = i & EHEA_INDEX_MASK;
+ vaddr = EHEA_BUSMAP_START + mr_len + i * EHEA_SECTSIZE;
+
+ ehea_bmap->top[top]->dir[dir]->ent[idx] = vaddr;
}
+ mr_len += nr_pages * PAGE_SIZE;
+ *(unsigned long *)arg = mr_len;
+
return 0;
}
+static unsigned long ehea_mr_len;
+
+static DEFINE_MUTEX(ehea_busmap_mutex);
+
+int ehea_create_busmap(void)
+{
+ int ret;
+ mutex_lock(&ehea_busmap_mutex);
+ ehea_mr_len = 0;
+ ret = walk_memory_resource(0, 1ULL << MAX_PHYSMEM_BITS, &ehea_mr_len,
+ ehea_create_busmap_callback);
+ mutex_unlock(&ehea_busmap_mutex);
+ return ret;
+}
+
void ehea_destroy_busmap(void)
{
- vfree(ehea_bmap.vaddr);
+ int top, dir;
+ mutex_lock(&ehea_busmap_mutex);
+ if (!ehea_bmap)
+ goto out_destroy;
+
+ for (top = 0; top < EHEA_MAP_ENTRIES; top++) {
+ if (!ehea_bmap->top[top])
+ continue;
+
+ for (dir = 0; dir < EHEA_MAP_ENTRIES; dir++) {
+ if (!ehea_bmap->top[top]->dir[dir])
+ continue;
+
+ kfree(ehea_bmap->top[top]->dir[dir]);
+ }
+
+ kfree(ehea_bmap->top[top]);
+ }
+
+ kfree(ehea_bmap);
+ ehea_bmap = NULL;
+out_destroy:
+ mutex_unlock(&ehea_busmap_mutex);
}
u64 ehea_map_vaddr(void *caddr)
{
- u64 mapped_addr;
- unsigned long index = __pa(caddr) >> SECTION_SIZE_BITS;
+ int top, dir, idx;
+ unsigned long index, offset;
+
+ if (!ehea_bmap)
+ return EHEA_INVAL_ADDR;
+
+ index = virt_to_abs(caddr) >> SECTION_SIZE_BITS;
+ top = (index >> EHEA_TOP_INDEX_SHIFT) & EHEA_INDEX_MASK;
+ if (!ehea_bmap->top[top])
+ return EHEA_INVAL_ADDR;
- if (likely(index < ehea_bmap.entries)) {
- mapped_addr = ehea_bmap.vaddr[index];
- if (likely(mapped_addr))
- mapped_addr |= (((unsigned long)caddr)
- & (EHEA_SECTSIZE - 1));
- else
- mapped_addr = -1;
- } else
- mapped_addr = -1;
-
- if (unlikely(mapped_addr == -1))
- if (!test_and_set_bit(__EHEA_STOP_XFER, &ehea_driver_flags))
- schedule_work(&ehea_rereg_mr_task);
+ dir = (index >> EHEA_DIR_INDEX_SHIFT) & EHEA_INDEX_MASK;
+ if (!ehea_bmap->top[top]->dir[dir])
+ return EHEA_INVAL_ADDR;
- return mapped_addr;
+ idx = index & EHEA_INDEX_MASK;
+ if (!ehea_bmap->top[top]->dir[dir]->ent[idx])
+ return EHEA_INVAL_ADDR;
+
+ offset = (unsigned long)caddr & (EHEA_SECTSIZE - 1);
+ return ehea_bmap->top[top]->dir[dir]->ent[idx] | offset;
+}
+
+static inline void *ehea_calc_sectbase(int top, int dir, int idx)
+{
+ unsigned long ret = idx;
+ ret |= dir << EHEA_DIR_INDEX_SHIFT;
+ ret |= top << EHEA_TOP_INDEX_SHIFT;
+ return abs_to_virt(ret << SECTION_SIZE_BITS);
+}
+
+static u64 ehea_reg_mr_section(int top, int dir, int idx, u64 *pt,
+ struct ehea_adapter *adapter,
+ struct ehea_mr *mr)
+{
+ void *pg;
+ u64 j, m, hret;
+ unsigned long k = 0;
+ u64 pt_abs = virt_to_abs(pt);
+
+ void *sectbase = ehea_calc_sectbase(top, dir, idx);
+
+ for (j = 0; j < (EHEA_PAGES_PER_SECTION / EHEA_MAX_RPAGE); j++) {
+
+ for (m = 0; m < EHEA_MAX_RPAGE; m++) {
+ pg = sectbase + ((k++) * EHEA_PAGESIZE);
+ pt[m] = virt_to_abs(pg);
+ }
+ hret = ehea_h_register_rpage_mr(adapter->handle, mr->handle, 0,
+ 0, pt_abs, EHEA_MAX_RPAGE);
+
+ if ((hret != H_SUCCESS)
+ && (hret != H_PAGE_REGISTERED)) {
+ ehea_h_free_resource(adapter->handle, mr->handle,
+ FORCE_FREE);
+ ehea_error("register_rpage_mr failed");
+ return hret;
+ }
+ }
+ return hret;
+}
+
+static u64 ehea_reg_mr_sections(int top, int dir, u64 *pt,
+ struct ehea_adapter *adapter,
+ struct ehea_mr *mr)
+{
+ u64 hret = H_SUCCESS;
+ int idx;
+
+ for (idx = 0; idx < EHEA_MAP_ENTRIES; idx++) {
+ if (!ehea_bmap->top[top]->dir[dir]->ent[idx])
+ continue;
+
+ hret = ehea_reg_mr_section(top, dir, idx, pt, adapter, mr);
+ if ((hret != H_SUCCESS) && (hret != H_PAGE_REGISTERED))
+ return hret;
+ }
+ return hret;
+}
+
+static u64 ehea_reg_mr_dir_sections(int top, u64 *pt,
+ struct ehea_adapter *adapter,
+ struct ehea_mr *mr)
+{
+ u64 hret = H_SUCCESS;
+ int dir;
+
+ for (dir = 0; dir < EHEA_MAP_ENTRIES; dir++) {
+ if (!ehea_bmap->top[top]->dir[dir])
+ continue;
+
+ hret = ehea_reg_mr_sections(top, dir, pt, adapter, mr);
+ if ((hret != H_SUCCESS) && (hret != H_PAGE_REGISTERED))
+ return hret;
+ }
+ return hret;
}
int ehea_reg_kernel_mr(struct ehea_adapter *adapter, struct ehea_mr *mr)
{
int ret;
u64 *pt;
- void *pg;
- u64 hret, pt_abs, i, j, m, mr_len;
+ u64 hret;
u32 acc_ctrl = EHEA_MR_ACC_CTRL;
- mr_len = ehea_bmap.valid_sections * EHEA_SECTSIZE;
+ unsigned long top;
- pt = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ pt = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!pt) {
ehea_error("no mem");
ret = -ENOMEM;
goto out;
}
- pt_abs = virt_to_abs(pt);
- hret = ehea_h_alloc_resource_mr(adapter->handle,
- EHEA_BUSMAP_START, mr_len,
- acc_ctrl, adapter->pd,
+ hret = ehea_h_alloc_resource_mr(adapter->handle, EHEA_BUSMAP_START,
+ ehea_mr_len, acc_ctrl, adapter->pd,
&mr->handle, &mr->lkey);
+
if (hret != H_SUCCESS) {
ehea_error("alloc_resource_mr failed");
ret = -EIO;
goto out;
}
- for (i = 0 ; i < ehea_bmap.entries; i++)
- if (ehea_bmap.vaddr[i]) {
- void *sectbase = __va(i << SECTION_SIZE_BITS);
- unsigned long k = 0;
-
- for (j = 0; j < (EHEA_PAGES_PER_SECTION /
- EHEA_MAX_RPAGE); j++) {
-
- for (m = 0; m < EHEA_MAX_RPAGE; m++) {
- pg = sectbase + ((k++) * EHEA_PAGESIZE);
- pt[m] = virt_to_abs(pg);
- }
-
- hret = ehea_h_register_rpage_mr(adapter->handle,
- mr->handle,
- 0, 0, pt_abs,
- EHEA_MAX_RPAGE);
- if ((hret != H_SUCCESS)
- && (hret != H_PAGE_REGISTERED)) {
- ehea_h_free_resource(adapter->handle,
- mr->handle,
- FORCE_FREE);
- ehea_error("register_rpage_mr failed");
- ret = -EIO;
- goto out;
- }
- }
- }
+ if (!ehea_bmap) {
+ ehea_h_free_resource(adapter->handle, mr->handle, FORCE_FREE);
+ ehea_error("no busmap available");
+ ret = -EIO;
+ goto out;
+ }
+
+ for (top = 0; top < EHEA_MAP_ENTRIES; top++) {
+ if (!ehea_bmap->top[top])
+ continue;
+
+ hret = ehea_reg_mr_dir_sections(top, pt, adapter, mr);
+ if((hret != H_PAGE_REGISTERED) && (hret != H_SUCCESS))
+ break;
+ }
if (hret != H_SUCCESS) {
ehea_h_free_resource(adapter->handle, mr->handle, FORCE_FREE);
^ permalink raw reply
* Re: jffs2 and unaligned access
From: Sascha Hauer @ 2008-05-07 13:25 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <1210157630.25560.884.camel@pmac.infradead.org>
On Wed, May 07, 2008 at 11:53:49AM +0100, David Woodhouse wrote:
> On Wed, 2008-05-07 at 12:27 +0200, Sascha Hauer wrote:
> > memcpy_from/to_io() use word aligned accesses on the io side of memory.
> > The MPC5200 local plus bus where our flashes are connected does not
> > allow unaligned accesses, so we have to use the io versions of memcpy.
>
> But this region of flash is marked as suitable for execute-in-place,
> otherwise the point() function wouldn't be working to give a direct
> pointer to it. It sounds like we shouldn't be allowing that.
It actually is suitable for execute-in-place. It's the flash U-Boot
starts from. The compiler will generate a proper alignment for you.
>
> Which in turn means that perhaps we should have a property in the
> corresponding node in the device-tree which indicates that it's not
> suitable for direct access?
So far we did not work with the device-tree flash binding but with the
physmap-flash driver, but ok, this is subject to change anyway.
I gave it a quick try to disable direct accesses. It works, but has a
1:10 performance impact on mounting a jffs2. At least it's a clean
solution.
Sascha
--
Pengutronix e.K. - Linux Solutions for Science and Industry
-----------------------------------------------------------
Kontakt-Informationen finden Sie im Header dieser Mail oder
auf der Webseite -> http://www.pengutronix.de/impressum/ <-
^ permalink raw reply
* [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
From: Kamalesh Babulal @ 2008-05-07 13:22 UTC (permalink / raw)
To: kernel list; +Cc: linuxppc-dev, Balbir Singh
While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel,
task get blocked for more 120 seconds and does not proceeds future.
The task msgctl08 is a ipc testcase, which test the msgget(2) msgctl(2)
syscalls. Machine is stuck in the task, printing the following call trace
more than 5000 times. The oom-killer invoked once in-between.
INFO: task msgctl08:16248 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000762435a0] [0000000000000001] 0x1 (unreliable)
[c000000076243770] [c000000000010acc] .__switch_to+0x128/0x16c
[c000000076243800] [c0000000004b07a4] .schedule+0x7ac/0x890
[c0000000762438f0] [c0000000004b2ba4] .rwsem_down_failed_common+0x260/0x2b0
[c0000000762439b0] [c0000000004b2c60] .rwsem_down_read_failed+0x2c/0x44
[c000000076243a60] [c0000000004b1b84] .down_read+0x44/0x5c
[c000000076243af0] [c000000000295e10] .ipc_lock+0x34/0xe0
[c000000076243b90] [c00000000029690c] .ipc_lock_check+0x24/0x78
[c000000076243c20] [c0000000002972c0] .do_msgsnd+0xb0/0x3f8
[c000000076243d10] [c000000000293ce8] .compat_sys_msgsnd+0x94/0xc0
[c000000076243db0] [c000000000014418] .compat_sys_ipc+0x130/0x1f4
[c000000076243e30] [c000000000008734] syscall_exit+0x0/0x40
msgctl08 invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0
Call Trace:
[c00000001e1c7640] [c0000000000101bc] .show_stack+0x70/0x1bc (unreliable)
[c00000001e1c76f0] [c0000000000c2c78] .oom_kill_process+0x78/0x230
[c00000001e1c77a0] [c0000000000c3390] .out_of_memory+0x28c/0x320
[c00000001e1c7870] [c0000000000c70ac] .__alloc_pages_internal+0x364/0x468
[c00000001e1c7980] [c0000000000e83cc] .alloc_page_vma+0x120/0x14c
[c00000001e1c7a20] [c0000000000e0224] .read_swap_cache_async+0x7c/0x160
[c00000001e1c7ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
[c00000001e1c7ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
[c00000001e1c7c80] [c0000000004b5054] .do_page_fault+0x440/0x624
[c00000001e1c7e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
Mem-info:
Node 0 DMA per-cpu:
CPU 0: hi: 6, btch: 1 usd: 1
CPU 1: hi: 6, btch: 1 usd: 1
Node 1 DMA per-cpu:
CPU 0: hi: 6, btch: 1 usd: 5
CPU 1: hi: 6, btch: 1 usd: 5
Active:31 inactive:2628 dirty:1 writeback:6 unstable:0
free:156 slab:13071 mapped:548 pagetables:41109 bounce:0
Node 0 DMA free:5312kB min:5760kB low:7168kB high:8640kB active:1024kB inactive:768kB present:3928832kB pages_scanned:3912 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Node 1 DMA free:4672kB min:4992kB low:6208kB high:7488kB active:960kB inactive:169792kB present:3404992kB pages_scanned:140140 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Node 0 DMA: 5*64kB 15*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 5312kB
Node 1 DMA: 8*64kB 5*128kB 6*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 4736kB
8185 total pagecache pages
Swap cache: add 29545, delete 21888, find 5602/10373
Free swap = 803712kB
Total swap = 2048128kB
114688 pages of RAM
766 reserved pages
231218 pages shared
7657 pages swap cached
Out of memory: kill process 15371 (msgctl08) score 39223 or a child
Killed process 15373 (msgctl08)
INFO: task msgctl08:15385 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000e9a43290] [0000000000000001] 0x1 (unreliable)
[c0000000e9a43460] [c000000000010acc] .__switch_to+0x128/0x16c
[c0000000e9a434f0] [c0000000004b07a4] .schedule+0x7ac/0x890
[c0000000e9a435e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
[c0000000e9a43670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
[c0000000e9a43750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
[c0000000e9a43800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
[c0000000e9a438e0] [c0000000002d81b0] .submit_bio+0x118/0x140
[c0000000e9a439a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
[c0000000e9a43a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
[c0000000e9a43ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
[c0000000e9a43ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
[c0000000e9a43c80] [c0000000004b5054] .do_page_fault+0x440/0x624
[c0000000e9a43e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
INFO: task msgctl08:15405 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000b1757290] [0000000000000001] 0x1 (unreliable)
[c0000000b1757460] [c000000000010acc] .__switch_to+0x128/0x16c
[c0000000b17574f0] [c0000000004b07a4] .schedule+0x7ac/0x890
[c0000000b17575e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
[c0000000b1757670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
[c0000000b1757750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
[c0000000b1757800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
[c0000000b17578e0] [c0000000002d81b0] .submit_bio+0x118/0x140
[c0000000b17579a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
[c0000000b1757a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
[c0000000b1757ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
[c0000000b1757ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
[c0000000b1757c80] [c0000000004b5054] .do_page_fault+0x440/0x624
[c0000000b1757e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
INFO: task msgctl08:15406 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000eec53290] [0000000000000001] 0x1 (unreliable)
[c0000000eec53460] [c000000000010acc] .__switch_to+0x128/0x16c
[c0000000eec534f0] [c0000000004b07a4] .schedule+0x7ac/0x890
[c0000000eec535e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
[c0000000eec53670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
[c0000000eec53750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
[c0000000eec53800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
[c0000000eec538e0] [c0000000002d81b0] .submit_bio+0x118/0x140
[c0000000eec539a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
[c0000000eec53a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
[c0000000eec53ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
[c0000000eec53ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
[c0000000eec53c80] [c0000000004b5054] .do_page_fault+0x440/0x624
[c0000000eec53e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [RFC] gianfar: low gigabit throughput
From: Anton Vorontsov @ 2008-05-07 13:28 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, linuxppc-dev
In-Reply-To: <4820BA72.3090903@hp.com>
On Tue, May 06, 2008 at 01:07:14PM -0700, Rick Jones wrote:
> Anton Vorontsov wrote:
>> Hi all,
>>
>> Down here few question regarding networking throughput, I would
>> appreciate any thoughts or ideas.
>>
>> On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing
>> relatively low TCP throughput using gianfar driver...
>
> What is the "target" of the test - is it another of those boards, or
> something else?
I've tried in various ways (except for another of these boards, I don't
have any), for example really fast machine with gbit ethernet, but most
of the time I'm testing with MPC8315 and MPC8377 interconnected.
The other interesting thing is that when netserver is running on the
MPC8315 (slow) target, and netperf on the MPC8377 (fast), the TCP
and UDP throughput increases.
root@mpc837x_rdb:~# netperf -l 3 -H 10.0.1.2 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
TCP STREAM TEST to 10.0.1.2
#Cpu utilization 40.66
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
212992 206848 32768 3.00 309.87
So the slow target can receive TCP packets with 300 Mb/s, but TCP
packet generation (or transmitting) is slower.
>>
>> The maximum value I've seen with the current kernels is 142 Mb/s of TCP
>> and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled):
>>
>> root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
>> TCP STREAM TEST to 10.0.1.1
>> #Cpu utilization 0.10
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 206848 212992 32768 10.00 142.40
>>
>> root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157344 -S 157344
>> UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1
>> #Cpu utilization 100.00
>> Socket Message Elapsed Messages
>> Size Size Time Okay Errors Throughput
>> bytes bytes secs # # 10^6bits/sec
>>
>> 212992 32768 10.00 13539 0 354.84
>> 206848 10.00 13539 354.84
>>
>
> I have _got_ to make CPU utilization enabled by default one of these
> days :) At least for mechanisms which don't require calibration.
Heh, I've skipped the calibration chapter in the netperf manual. :-D
Should revert to it.
>> Is this normal?
>
> Does gianfar do TSO?
Afaik, it doesn't. The hardware can do header recognition/verification
including checksums, and also could generate checksums for the TCP/IP.
But IP fragmentation and re-assembly on the software's shoulders.
> If not, what happens when you tell UDP_STREAM to
> send 1472 byte messages to bypass IP fragmentation?
A bit worse throughput:
root@b1:~# netperf -l 3 -H 10.0.1.1 -t UDP_STREAM -- -m 1472 -s 157344 -S 157344
UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1
#Cpu utilization 100.00
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 1472 3.00 73377 0 287.86
206848 3.00 73377 287.86
And 32 * 1472:
root@b1:~# netperf -l 3 -H 10.0.1.1 -t UDP_STREAM -- -m 47104 -s 157344 -S 157344
UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1
#Cpu utilization 100.00
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
212992 47104 3.00 3124 0 392.13
206848 3.00 3124 392.13
So things becomes much better when the message size increases
(I think the netperf then eating less cpu, and gives some precessing
time to the kernel?).
The same for TCP packets with mlen of 1448.
> While stock netperf won't report what the socket buffer size becomes
> when you allow autotuning to rear its head, you can take the top of
> trunk and enable the "omni" tests (./configure --enable-omni) and those
> versions of *_STREAM etc can report what the socket buffer size was at
> the beginning and at the end of the test. You can let the stack autotune
> and see if anything changes there. You can do the same with stock
> netperf, just it will only report the initial socket buffer sizes...
Thanks, will try.
>> netperf running in loopback gives me 329 Mb/s of TCP throughput:
>>
>> root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
>> TCP STREAM TEST to 127.0.0.1
>> #Cpu utilization 100.00
>> #Cpu utilization 100.00
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 212992 212992 32768 10.00 329.60
>>
>>
>> May I consider this as a something that is close to the Linux'
>> theoretical maximum for this setup? Or this isn't reliable test?
>
> I'm always leery of using a loopback number. It excercises both send
> and receive at the same time, but without the driver. Also, lo tends to
> have a much larger MTU than a "standard" NIC and if that NIC doesn't to
> TSO and LRO that can be a big difference in the number of times up and
> down the stack per KB transferred.
I see. Will be cautious with it, too. ;-)
>> I can compare with teh MPC8377E-RDB (very similar board - exactly the same
>> ethernet phy, the same drivers are used, i.e. everything is the same from
>> the ethernet stand point), but running at 666 MHz, CSB at 333MHz:
>>
>> |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s|
>> ------------------------------------------
>> MPC8377| 666| 333| 646| 264|
>> MPC8315| 400| 133| 354| 142|
>> ------------------------------------------
>> RATIO | 1.6| 2.5| 1.8| 1.8|
>>
>> It seems that things are really dependant on the CPU/CSB speed.
>
> What is the nature of the DMA stream between the two tests? I find it
> interesting that the TCP Mb/s went up by more than the CPU MHz and
> wonder how much the Bus MHz came into play there - perhaps there were
> more DMA's to setup or across a broader memory footprint for TCP than
> for UDP.
The gianfar indeed does a lot of dma on the "buffer descriptors", so
probably the bus speed matters a lot. And combination of CPU and Bus
gives the final result.
>>
>> I've tried to tune gianfar driver in various ways... and it gave
>> some positive results with this patch:
>>
>> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
>> index fd487be..b5943f9 100644
>> --- a/drivers/net/gianfar.h
>> +++ b/drivers/net/gianfar.h
>> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
>> #define GFAR_10_TIME 25600
>> #define DEFAULT_TX_COALESCE 1
>> -#define DEFAULT_TXCOUNT 16
>> -#define DEFAULT_TXTIME 21
>> +#define DEFAULT_TXCOUNT 80
>> +#define DEFAULT_TXTIME 105
>> #define DEFAULT_RXTIME 21
>
> No ethtool coalescing tuning support for gianfar?-)
Heh. :-) I should have looked into gianfar_ethtool.c before editing
anything. Yes, there is.
>> Basically this raises the tx interrupts coalescing threshold (raising
>> it more didn't help, as well as didn't help raising rx thresholds).
>> Now:
>>
>> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
>> TCP STREAM TEST to 10.0.1.1
>> #Cpu utilization 100.00
>> Recv Send Send
>> Socket Socket Message Elapsed
>> Size Size Size Time Throughput
>> bytes bytes bytes secs. 10^6bits/sec
>>
>> 206848 212992 32768 3.00 163.04
>>
>>
>> That is +21 Mb/s (14% up). Not fantastic, but good anyway.
>>
>> As expected, the latency increased too:
>>
>> Before the patch:
>>
>> --- 10.0.1.1 ping statistics ---
>> 20 packets transmitted, 20 received, 0% packet loss, time 18997ms
>> rtt min/avg/max/mdev = 0.108/0.124/0.173/0.022 ms
>>
>> After:
>>
>> --- 10.0.1.1 ping statistics ---
>> 22 packets transmitted, 22 received, 0% packet loss, time 20997ms
>> rtt min/avg/max/mdev = 0.158/0.167/0.182/0.004 ms
>>
>>
>> 34% up... heh. Should we sacrifice the latency in favour of throughput?
>> Is 34% latency growth bad thing? What is worse, lose 21 Mb/s or 34% of
>> latency? ;-)
>
> Well, I'm not always fond of that sort of trade-off:
>
> ftp://ftp.cup.hp.com/dist/networking/briefs/
>
> there should be a nic latency vs tput writeup there.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC] gianfar: low gigabit throughput
From: Anton Vorontsov @ 2008-05-07 13:33 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, Rick Jones, linuxppc-dev
In-Reply-To: <E82C3C5F-0D93-4190-ADDC-3FA37D13E250@freescale.com>
On Tue, May 06, 2008 at 03:29:06PM -0500, Andy Fleming wrote:
>>>
>>> I've tried to tune gianfar driver in various ways... and it gave
>>> some positive results with this patch:
>>> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
>>> index fd487be..b5943f9 100644
>>> --- a/drivers/net/gianfar.h
>>> +++ b/drivers/net/gianfar.h
>>> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
>>> #define GFAR_10_TIME 25600
>>> #define DEFAULT_TX_COALESCE 1
>>> -#define DEFAULT_TXCOUNT 16
>>> -#define DEFAULT_TXTIME 21
>>> +#define DEFAULT_TXCOUNT 80
>>> +#define DEFAULT_TXTIME 105
>>> #define DEFAULT_RXTIME 21
>>
>> No ethtool coalescing tuning support for gianfar?-)
>
> Yeah, there's coalescing tuning in gianfar.
>
> Anton, those numbers aren't too surprising on a 400 MHz machine, I
> think.
This is my thinking too, actually. I've seen the MPC885 board with CPU
running at 133 MHz and CSB at 66MHz. It was using the completely
different driver (fs_enet's FEC), and it failed to produce even 60 Mb/s
(with a 100 Mb/s PHY). 50-55 Mb/s was quite normal for that board.
Which means, I think, that ~160 Mb/s is quite good for the 400/133
MHz board.
> But I'd be happy to see any analysis on performance bottlenecks
> in the driver. And patches to fix those bottlenecks are even better! :)
The thing is that I don't see obvious bottlenecks, so I'm afraid we'll
not able to do x2 boost or something... Just fine tuning the driver here
and there... Interrupts coalescing was very obvious step to boost the
troughtput, but there are its drawbacks...
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
From: Adrian Bunk @ 2008-05-07 13:40 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: kernel list, linuxppc-dev, Pierre Peiffer, Nadia Derbey,
Balbir Singh
In-Reply-To: <4821AD2D.8020001@linux.vnet.ibm.com>
On Wed, May 07, 2008 at 06:52:53PM +0530, Kamalesh Babulal wrote:
> While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel,
> task get blocked for more 120 seconds and does not proceeds future.
>
> The task msgctl08 is a ipc testcase, which test the msgget(2) msgctl(2)
> syscalls.
Thanks for your report.
I assume this is reproducible?
If yes, what was the last kernel that worked for you?
I've also added Pierre Peiffer and Nadia Derbey to the Cc since their
recent ipc commits are my first suspects.
> Machine is stuck in the task, printing the following call trace
> more than 5000 times. The oom-killer invoked once in-between.
>
> INFO: task msgctl08:16248 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Call Trace:
> [c0000000762435a0] [0000000000000001] 0x1 (unreliable)
> [c000000076243770] [c000000000010acc] .__switch_to+0x128/0x16c
> [c000000076243800] [c0000000004b07a4] .schedule+0x7ac/0x890
> [c0000000762438f0] [c0000000004b2ba4] .rwsem_down_failed_common+0x260/0x2b0
> [c0000000762439b0] [c0000000004b2c60] .rwsem_down_read_failed+0x2c/0x44
> [c000000076243a60] [c0000000004b1b84] .down_read+0x44/0x5c
> [c000000076243af0] [c000000000295e10] .ipc_lock+0x34/0xe0
> [c000000076243b90] [c00000000029690c] .ipc_lock_check+0x24/0x78
> [c000000076243c20] [c0000000002972c0] .do_msgsnd+0xb0/0x3f8
> [c000000076243d10] [c000000000293ce8] .compat_sys_msgsnd+0x94/0xc0
> [c000000076243db0] [c000000000014418] .compat_sys_ipc+0x130/0x1f4
> [c000000076243e30] [c000000000008734] syscall_exit+0x0/0x40
> msgctl08 invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0
> Call Trace:
> [c00000001e1c7640] [c0000000000101bc] .show_stack+0x70/0x1bc (unreliable)
> [c00000001e1c76f0] [c0000000000c2c78] .oom_kill_process+0x78/0x230
> [c00000001e1c77a0] [c0000000000c3390] .out_of_memory+0x28c/0x320
> [c00000001e1c7870] [c0000000000c70ac] .__alloc_pages_internal+0x364/0x468
> [c00000001e1c7980] [c0000000000e83cc] .alloc_page_vma+0x120/0x14c
> [c00000001e1c7a20] [c0000000000e0224] .read_swap_cache_async+0x7c/0x160
> [c00000001e1c7ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
> [c00000001e1c7ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
> [c00000001e1c7c80] [c0000000004b5054] .do_page_fault+0x440/0x624
> [c00000001e1c7e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
> Mem-info:
> Node 0 DMA per-cpu:
> CPU 0: hi: 6, btch: 1 usd: 1
> CPU 1: hi: 6, btch: 1 usd: 1
> Node 1 DMA per-cpu:
> CPU 0: hi: 6, btch: 1 usd: 5
> CPU 1: hi: 6, btch: 1 usd: 5
> Active:31 inactive:2628 dirty:1 writeback:6 unstable:0
> free:156 slab:13071 mapped:548 pagetables:41109 bounce:0
> Node 0 DMA free:5312kB min:5760kB low:7168kB high:8640kB active:1024kB inactive:768kB present:3928832kB pages_scanned:3912 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Node 1 DMA free:4672kB min:4992kB low:6208kB high:7488kB active:960kB inactive:169792kB present:3404992kB pages_scanned:140140 all_unreclaimable? no
> lowmem_reserve[]: 0 0 0
> Node 0 DMA: 5*64kB 15*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 5312kB
> Node 1 DMA: 8*64kB 5*128kB 6*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 4736kB
> 8185 total pagecache pages
> Swap cache: add 29545, delete 21888, find 5602/10373
> Free swap = 803712kB
> Total swap = 2048128kB
> 114688 pages of RAM
> 766 reserved pages
> 231218 pages shared
> 7657 pages swap cached
> Out of memory: kill process 15371 (msgctl08) score 39223 or a child
> Killed process 15373 (msgctl08)
> INFO: task msgctl08:15385 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Call Trace:
> [c0000000e9a43290] [0000000000000001] 0x1 (unreliable)
> [c0000000e9a43460] [c000000000010acc] .__switch_to+0x128/0x16c
> [c0000000e9a434f0] [c0000000004b07a4] .schedule+0x7ac/0x890
> [c0000000e9a435e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
> [c0000000e9a43670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
> [c0000000e9a43750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
> [c0000000e9a43800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
> [c0000000e9a438e0] [c0000000002d81b0] .submit_bio+0x118/0x140
> [c0000000e9a439a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
> [c0000000e9a43a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
> [c0000000e9a43ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
> [c0000000e9a43ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
> [c0000000e9a43c80] [c0000000004b5054] .do_page_fault+0x440/0x624
> [c0000000e9a43e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
> INFO: task msgctl08:15405 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Call Trace:
> [c0000000b1757290] [0000000000000001] 0x1 (unreliable)
> [c0000000b1757460] [c000000000010acc] .__switch_to+0x128/0x16c
> [c0000000b17574f0] [c0000000004b07a4] .schedule+0x7ac/0x890
> [c0000000b17575e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
> [c0000000b1757670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
> [c0000000b1757750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
> [c0000000b1757800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
> [c0000000b17578e0] [c0000000002d81b0] .submit_bio+0x118/0x140
> [c0000000b17579a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
> [c0000000b1757a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
> [c0000000b1757ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
> [c0000000b1757ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
> [c0000000b1757c80] [c0000000004b5054] .do_page_fault+0x440/0x624
> [c0000000b1757e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
> INFO: task msgctl08:15406 blocked for more than 120 seconds.
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Call Trace:
> [c0000000eec53290] [0000000000000001] 0x1 (unreliable)
> [c0000000eec53460] [c000000000010acc] .__switch_to+0x128/0x16c
> [c0000000eec534f0] [c0000000004b07a4] .schedule+0x7ac/0x890
> [c0000000eec535e0] [c0000000004b0d90] .io_schedule+0x7c/0xe8
> [c0000000eec53670] [c0000000002d7f44] .get_request_wait+0x15c/0x1e0
> [c0000000eec53750] [c0000000002d8950] .__make_request+0x3ec/0x4d8
> [c0000000eec53800] [c0000000002d6624] .generic_make_request+0x35c/0x3b0
> [c0000000eec538e0] [c0000000002d81b0] .submit_bio+0x118/0x140
> [c0000000eec539a0] [c0000000000dfa88] .swap_readpage+0x94/0xb4
> [c0000000eec53a20] [c0000000000e02b8] .read_swap_cache_async+0x110/0x160
> [c0000000eec53ae0] [c0000000000e035c] .swapin_readahead+0x54/0xd4
> [c0000000eec53ba0] [c0000000000d47e8] .handle_mm_fault+0x520/0x9d8
> [c0000000eec53c80] [c0000000004b5054] .do_page_fault+0x440/0x624
> [c0000000eec53e30] [c0000000000053fc] handle_page_fault+0x20/0x5c
> --
> Thanks & Regards,
> Kamalesh Babulal,
> Linux Technology Center,
> IBM, ISTL.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: MPC5200b MMC over SPI into PSC6
From: Fabio Tosetto @ 2008-05-07 12:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40805060836o519bff20yf2506676ff1c3e6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
I've tried to port my exesting configurations to the powerpc tree but
some configurations files are missing.
I need to set PSC3 - PSC4 in uart mode:
before in file *arch/ppc/platforms/lite5200.c* I added
struct mpc52xx_psc_func mpc52xx_psc_functions[] = {
{ .id = 3,
.func = "uart",
},
{ .id = 4,
.func = "uart",
},
{ .id = -1, /* End entry */
.func = NULL,
}
};
I need to set PSC4 as a low level debug: *
*before in file *arch/ppc/platforms/lite5200.h *I added
#define MPC52xx_PF_CONSOLE_PORT 4 /* PSC4 */
Finally I need to set the virtual memory translation on a range of 128 MB:
before in file *arch/ppc/kernel/head.S *I added
/*ori r11,r11,BL_128M<<2|0x2 set up BAT registers for 604 */
ori r11,r11,BL_128M<<2|0x2 /* set up BAT registers for 604 */
could you please explain me how to do the same operations in powerpc tree??
thanks Fabio
Grant Likely ha scritto:
> On Mon, May 5, 2008 at 12:12 PM, Fabio Tosetto <tosettofabio83@libero.it> wrote:
>
>> Hello, I have an embedded system with an on-board processor powerpc MPC5200B
>> and Linux kernel 2.6.22,
>> I must turn over to MMC SPI on the PSC6.
>>
>> First, I
>> have enabled PSC6:
>>
>> in ../arch/ppc/platforms/lite5200.c added PSC6 in SPI mode
>>
>
> You're using arch/ppc which is depreciated. You should move to using
> arch/powerpc (set ARCH=powerpc when compiling). Devices are then
> enabled in the device tree source file
> arch/powerpc/boot/dts/lite5200b.dts.
>
> Many things have changed with MPC5200 support in the last year, you
> should also use the latest kernel release (2.6.25.2 when it is
> released. If you use 2.6.25.1, then there is a trivial bug in the psc
> serial port driver that you'll need to fix. I'll include the link to
> the patch below)
>
> Cheers,
> g.
>
> http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055495.html
>
>
[-- Attachment #2: Type: text/html, Size: 3552 bytes --]
^ permalink raw reply
* Re: ALSA vs. non coherent DMA
From: Timur Tabi @ 2008-05-07 14:22 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Linux Kernel list, linuxppc-dev list
In-Reply-To: <s5hmyn3d7d5.wl%tiwai@suse.de>
Takashi Iwai wrote:
> This is a mmap of the data record to be shared in realtime with apps.
> The app updates its data pointer (appl_ptr) on the mmapped buffer
> while the driver updates the data (e.g. DMA position, called hwptr) on
> the fly on the mmapped record. Due to its real-time nature, it has to
> be coherent -- at least, it was a problem on ARM.
This doesn't sound like a coherency problem to me, and least not one you'd find
on PowerPC. Both the driver and the application run on the host CPU, so there
shouldn't be any coherency problem. My understanding is that a "non coherent"
platform is one where the host CPU isn't aware when a *hardware device* writes
directly to memory, e.g. via DMA.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* All your drivers are belong to us [was WARNING: mutexes are preferred for single holder semaphores]
From: Detlev Zundel @ 2008-05-07 14:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080505004023.05603b93@lappy.seanm.ca>
Hi Sean,
> The code is GPLed but not currently available on the net. It is
> basically a little driver that registers a character device and
> then passes out the minor numbers to the PIKA board drivers.
>
> It was written to isolate all the character/sysfs code to one place
> since we have five drivers, and many debug drivers, that use it.
>
> If anybody is really interested, I can post it here. I doubt it will
> ever be submitted to the mainline kernel however.
Just for the record and because it may be interesting to others, during
the Hannover Messe end of April, in the context of the OSADL Congress[1]
I attended a speech of Greg KH about driver development and citing from
memory he said:
"I am serious, please post all drivers that there are, even if you think
they are useless for other people. We have a driver in mainline for a
device that I know only exists once in the whole world.
Having the drivers in the kernel gives the developers the chance to see
how the infrastructure is being used and to isolate good opportunities
for modularization benefiting the linux kernel.
[...]
It also happened that a driver once posted for what the customer
thought was a completely specific device of his own today supports lots
of different boards from at least four different manufacturers."
The wording is of course not exact but I hope I caught the spirit of
what Greg wanted to say. So yes, please post the driver - maybe Greg KH
will tunnel it into mainline...
Cheers
Detlev
[1] http://www.osadl.org/International-Congress-Open-Source-mee.hannover-2008-congress.0.html
PS: The OSADL pages should be updated in a few days to link to slides of
the talks.
--
Ftpd never switches uid and euid, it uses setfsuid(2) instead. The
main reason is that uid switching has been exploited in several
breakins, but the sheer ugliness of uid switching counts too.
-- pure-ftpd(8)
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [ewg] [PATCH] IB/ehca: Protect QP against destroying until all async events for it are handled.
From: Roland Dreier @ 2008-05-07 15:32 UTC (permalink / raw)
To: Stefan Roscher; +Cc: LinuxPPC-Dev, fenkes, LKML, raisch, OF-EWG
In-Reply-To: <200805071319.37164.ossrosch@linux.vnet.ibm.com>
> We are not sure if this should be fixed in the driver or in uverbs itself.
> Roland, what's your opinion about this?
Would be nice to be able to fix it in uverbs but I don't see how. In
particular a kernel consumer has to have the same guarantee that no
async events will come in after destroy QP returns. And I don't see any
way generic code can provide a guarantee about what low-level driver
code may do internally.
^ 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