* Re: [PATCH] FIXED_MII_100_FDX
From: Kumar Gala @ 2008-01-26 15:40 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list, Jeff Garzik, netdev
In-Reply-To: <479AD93D.30202@pikatech.com>
On Jan 26, 2008, at 12:54 AM, Sean MacLennan wrote:
> On the last git pull, FIXED_MII_100_FDX was removed from the phy
> Kconfig, but the Kconfig for CPMAC still tried to select it.
>
> Cheers,
> Sean
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 9af05a2..297a4b5 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1710,7 +1710,6 @@ config CPMAC
> depends on NET_ETHERNET && EXPERIMENTAL && AR7
> select PHYLIB
> select FIXED_PHY
> - select FIXED_MII_100_FDX
> help
> TI AR7 CPMAC Ethernet support
This patch isn't sufficient. AntonV has posted a proper fix that we
need Jeff to pick up.
http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050330.html
- k
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 16:22 UTC (permalink / raw)
To: Zoltan HERPAI; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <479AF8C5.6030404@uid0.hu>
On Sat, 26 Jan 2008 10:09:25 +0100
Zoltan HERPAI <wigyori@uid0.hu> wrote:
> Kumar Gala wrote:
> > 4xx:
> > EBONY
> >
> I have an Ebony at hand, so if no one takes it, I'll give it a try to
> port it over.
It's ported. It was the first 4xx board to be ported. Thanks for
offering though!
josh
^ permalink raw reply
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Olof Johansson @ 2008-01-26 17:36 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <20080126052454.GA27403@suse.de>
On Fri, Jan 25, 2008 at 09:24:54PM -0800, Greg KH wrote:
> On Fri, Jan 25, 2008 at 09:40:55PM -0600, Olof Johansson wrote:
> > On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> > > Dynamically create the kset instead of declaring it statically. We also
> > > rename devices_subsys to devices_kset to catch all users of the
> > > variable.
> >
> > Guess what, you broke powerpc again!
>
> I did this ON PURPOSE!!!
>
> The linux-kernel archives hold the details, and I was told by the PPC64
> IBM people that they would fix this properly for 2.6.25, and not to hold
> back on my changes. This has been known for many months now.
Yeah, my bad. :( I thought this was new, but it was just not exposed by
my scripts because of the EHEA build errors (they were actual compile
errors, while this was a link error, so it never go this far). That's
why I didn't see it in -rc8-mm1 and thought it was new.
> > -extern struct kset devices_subsys; /* needed for vio_find_name() */
> > +extern struct kset *devices_kset; /* needed for vio_find_name() */
>
> No, this just papers over the real problem here. For some reason, the
> vio code thinks it is acceptable to walk the whole device tree and match
> by a name and just assume that they got the correct device. You call
> this "enterprise grade"? :)
>
> You need to just put your device on a real bus, and then just walk the
> bus. That's the ONLY way you can guarantee the proper name will return
> what you want, and you get the pointer that you really think you are
> getting.
Hmm, they are already on a bus. Odd, must be done like this for legacy
reasons.
[...]
> So no, I'm going to leave the build broken for this code, because that
> is what it really is.
>
> Please fix it correctly.
Alright, I'll leave that to people who care about vio and can test the
proper fix. After a quick glance it looks like it should be easy to use
bus_find_device() for it instead.
-Olof
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Josh Boyer @ 2008-01-26 17:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
On Sat, 26 Jan 2008 17:16:38 +1100
Paul Mackerras <paulus@samba.org> wrote:
> This includes commits pulled from Josh Boyer, Kumar Gala, Grant
> Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
> PowerPC" commit because it changed behaviour even when the fake numa
> command-line option wasn't given.
>
> I'll be asking Linus to pull within the next few days, so please
> remind me about anything else that should go in 2.6.25.
I have a couple patches that depend on the netdev and USB
trees being merged first. And I'm sure we'll have some bug fix patches
at some point to deal with the clash-o-git trees that seems to be
coming.
josh
^ permalink raw reply
* Re: [BUILD FAILURE]2.6.24-git{1,2} kernel powerpc linkage failure
From: Greg KH @ 2008-01-26 20:45 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: LKML, linuxppc-dev, Badari Pulavarty, Andrew Morton,
Linus Torvalds
In-Reply-To: <479B3453.3030105@linux.vnet.ibm.com>
On Sat, Jan 26, 2008 at 06:53:31PM +0530, Kamalesh Babulal wrote:
> Hi,
>
> The 2.6.24-git2 kernel build fails on the power boxes with following build failure
>
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/powerpc/kernel/built-in.o: In function `fphalf':
> arch/powerpc/kernel/vector.S:(.toc+0x1428): undefined reference to `devices_subsys'
> make: *** [.tmp_vmlinux1] Error 1
>
> This built-failure was seen in the mm broken-out-2007-11-06-02-32, I have tested
> the patch posted to lkml at http://lkml.org/lkml/2007/11/6/208 fixes this issue.
And that patch is wrong, see my post on lkml about this yesterday.
Paul is working on a "correct" patch, and if I get some time this
afternoon, I'll do one too.
thanks,
greg k-h
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Grant Likely @ 2008-01-26 23:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
Paul, please pull the following mpc52xx changes.
Also, I'd like to have the following patch picked up, but I'm a bit
nervous about it. Kumar has said it looks good, but I'm still not
100% sure about eliminating the KBUILD_IMAGE and BOOTIMAGE variables.
I *think* it's safe, but I'm not a build system expert.
http://patchwork.ozlabs.org/linuxppc/patch?person=486&id=16264
Cheers,
g.
The following changes since commit 55852bed57a97b08ab56028f1054d48d45de3aec:
Paul Mackerras (1):
Revert "[POWERPC] Fake NUMA emulation for PowerPC"
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25
Grant Likely (6):
[POWERPC] mpc52xx: clean up Kconfig
[POWERPC] mpc5200: normalize compatible property bindings
[POWERPC] mpc5200: make dts files conform to generic names
recommended practice
[POWERPC] Efika: prune fixups and make them more carefull
[POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
[POWERPC] mpc52xx_psc_spi device driver must not touch port_config and cdm
Paul Gortmaker (1):
[POWERPC] mpc5200: add #address-cells and #size-cells to soc node.
arch/powerpc/boot/dts/cm5200.dts | 60 +++++------
arch/powerpc/boot/dts/lite5200.dts | 96 +++++++----------
arch/powerpc/boot/dts/lite5200b.dts | 93 +++++++---------
arch/powerpc/boot/dts/motionpro.dts | 68 +++++-------
arch/powerpc/boot/dts/tqm5200.dts | 45 ++++-----
arch/powerpc/boot/serial.c | 2 +-
arch/powerpc/kernel/prom_init.c | 149 ++++++++++++++------------
arch/powerpc/platforms/52xx/Kconfig | 41 +++-----
arch/powerpc/platforms/52xx/efika.c | 3 +
arch/powerpc/platforms/52xx/lite5200.c | 28 ++++--
arch/powerpc/platforms/52xx/lite5200_pm.c | 9 ++-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 117 ++++++++++++++++-----
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 10 ++-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 16 +++-
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 9 ++-
arch/powerpc/sysdev/bestcomm/bestcomm.c | 16 ++-
arch/ppc/syslib/mpc52xx_setup.c | 36 ++++++
drivers/ata/pata_mpc52xx.c | 6 +-
drivers/net/fec_mpc52xx.c | 6 +-
drivers/net/fec_mpc52xx_phy.c | 8 +-
drivers/serial/mpc52xx_uart.c | 4 +-
drivers/spi/mpc52xx_psc_spi.c | 82 +-------------
drivers/usb/host/ohci-ppc-of.c | 2 +
include/asm-powerpc/mpc52xx.h | 9 +-
25 files changed, 478 insertions(+), 443 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] Fix powerpc vio_find_name to not use devices_subsys
From: Paul Mackerras @ 2008-01-27 0:45 UTC (permalink / raw)
To: Greg KH, linux-kernel, linuxppc-dev; +Cc: sfr
This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
currently broken because it tries to use devices_subsys. That is bad
for two reasons: (1) it's doing (or trying to do) a scan of all
devices when it should only be scanning those on the vio bus, and
(2) devices_subsys was an internal symbol of the device system code
which was never meant for external use and has now gone away, and
thus the kernel fails to compile on pSeries.
The new version uses bus_find_device() on the vio bus (vio_bus_type).
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Greg, do you want to send this to Linus or will I do that? Or do you
have a better version? :)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 19a5656..b179b7e 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -37,8 +37,6 @@
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/iommu.h>
-extern struct kset devices_subsys; /* needed for vio_find_name() */
-
static struct bus_type vio_bus_type;
static struct vio_dev vio_bus_device = { /* fake "parent" device */
@@ -361,19 +359,23 @@ EXPORT_SYMBOL(vio_get_attribute);
#ifdef CONFIG_PPC_PSERIES
/* vio_find_name() - internal because only vio.c knows how we formatted the
* kobject name
- * XXX once vio_bus_type.devices is actually used as a kset in
- * drivers/base/bus.c, this function should be removed in favor of
- * "device_find(kobj_name, &vio_bus_type)"
*/
-static struct vio_dev *vio_find_name(const char *kobj_name)
+static int name_cmp(struct device *dev, void *data)
+{
+ const char *name = data;
+
+ return !strcmp(name, dev->bus_id);
+}
+
+static struct vio_dev *vio_find_name(const char *name)
{
- struct kobject *found;
+ struct device *found;
- found = kset_find_obj(&devices_subsys, kobj_name);
+ found = bus_find_device(&vio_bus_type, NULL, (void *)name, name_cmp);
if (!found)
return NULL;
- return to_vio_dev(container_of(found, struct device, kobj));
+ return to_vio_dev(found);
}
/**
^ permalink raw reply related
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Jon Smirl @ 2008-01-27 0:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <fa686aa40801261509o2f6fd195h2f2662e67c022ec@mail.gmail.com>
On 1/26/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> Grant Likely (6):
> [POWERPC] mpc52xx: clean up Kconfig
> [POWERPC] mpc5200: normalize compatible property bindings
> [POWERPC] mpc5200: make dts files conform to generic names
> recommended practice
> [POWERPC] Efika: prune fixups and make them more carefull
> [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
> [POWERPC] mpc52xx_psc_spi device driver must not touch port_config and cdm
Does this fix these warnings...
CC drivers/spi/mpc52xx_psc_spi.o
drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_activate_cs':
drivers/spi/mpc52xx_psc_spi.c:110: warning: passing argument 1 of
'in_be16' from incompatible pointer type
drivers/spi/mpc52xx_psc_spi.c:116: warning: passing argument 1 of
'out_be16' from incompatible pointer type
drivers/spi/mpc52xx_psc_spi.c: In function 'mpc52xx_psc_spi_port_config':
drivers/spi/mpc52xx_psc_spi.c:417: warning: passing argument 1 of
'out_be16' from incompatible pointer type
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Michael Ellerman @ 2008-01-27 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18330.53318.857148.409675@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
On Sat, 2008-01-26 at 17:16 +1100, Paul Mackerras wrote:
> This includes commits pulled from Josh Boyer, Kumar Gala, Grant
> Likely, and Olof Johansson. I reverted the "Fake NUMA emulation for
> PowerPC" commit because it changed behaviour even when the fake numa
> command-line option wasn't given.
>
> I'll be asking Linus to pull within the next few days, so please
> remind me about anything else that should go in 2.6.25.
Can you grab these four assuming there's no objections in the meantime.
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16430
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16433
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16434
http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16437
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix powerpc vio_find_name to not use devices_subsys
From: Greg KH @ 2008-01-27 5:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, sfr
In-Reply-To: <18331.54314.379281.960297@cargo.ozlabs.ibm.com>
On Sun, Jan 27, 2008 at 11:45:30AM +1100, Paul Mackerras wrote:
> This fixes vio_find_name() in arch/powerpc/kernel/vio.c, which is
> currently broken because it tries to use devices_subsys. That is bad
> for two reasons: (1) it's doing (or trying to do) a scan of all
> devices when it should only be scanning those on the vio bus, and
> (2) devices_subsys was an internal symbol of the device system code
> which was never meant for external use and has now gone away, and
> thus the kernel fails to compile on pSeries.
>
> The new version uses bus_find_device() on the vio bus (vio_bus_type).
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> Greg, do you want to send this to Linus or will I do that? Or do you
> have a better version? :)
I'll send it to him, with a minor change (I'm going to make this a core
function, as others also use the same functionality, no need for
everyone to re-invent the wheel all the time.
I also have some other patches to send him to fix up the fall-out of
these driver core changes :)
thanks,
greg k-h
^ permalink raw reply
* Re: [patch 04/11] ps3fb: Inline macros that are used only once
From: Andrew Morton @ 2008-01-27 6:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert.Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
adaplas
In-Reply-To: <20080125153107.177014292@vixen.sonytel.be>
> On Fri, 25 Jan 2008 16:06:27 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>
> ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros,
> as they're used in one place only
>
I think the term "open-code" would be more suitable here. "inlining" means
"make it an inline function". I'll update the changelog.
> -#define X_OFF(i) (ps3fb_res[i].xoff) /* left/right margin (pixel) */
> -#define Y_OFF(i) (ps3fb_res[i].yoff) /* top/bottom margin (pixel) */
> -#define WIDTH(i) (ps3fb_res[i].xres) /* width of FB */
> -#define HEIGHT(i) (ps3fb_res[i].yres) /* height of FB */
> #define BPP 4 /* number of bytes per pixel */
>
> -/* Start of the virtual frame buffer (relative to fullscreen ) */
> -#define VP_OFF(i) ((WIDTH(i) * Y_OFF(i) + X_OFF(i)) * BPP)
> -
>
> static int ps3fb_mode;
> module_param(ps3fb_mode, int, 0);
> @@ -611,7 +604,10 @@ static int ps3fb_set_par(struct fb_info
>
> par->width = info->var.xres;
> par->height = info->var.yres;
> - offset = VP_OFF(i);
> +
> + /* Start of the virtual frame buffer (relative to fullscreen) */
> + offset = ps3fb_res[i].yoff * ddr_line_length + ps3fb_res[i].xoff * BPP;
> +
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Andrew Morton @ 2008-01-27 6:01 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080125150623.202631389@vixen.sonytel.be>
> On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Hare are the ps3av/fb patches for 2.6.25:
I would have to say: it's a bit late to be submitting things of this nature
for 2.6.25. Given the mess everyone has made of everything there's little
chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
into mainline without public testing.
I don't think many people care much about ps3 so whatever. But if it were
core code or a popular driver then I would probably slip this back to
2.6.26.
We haven't heard from Tony in a while so I guess I'm fbdev maintainer
again. Be afraid.
^ permalink raw reply
* Re: [patch 09/11] ps3fb: Round up video modes
From: Andrew Morton @ 2008-01-27 6:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert.Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
adaplas
In-Reply-To: <20080125153107.478948955@vixen.sonytel.be>
> On Fri, 25 Jan 2008 16:06:32 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
> const struct fb_var_screeninfo *var)
> {
> - /* resolution + black border must match a native resolution */
> - if (vmode->left_margin + vmode->xres + vmode->right_margin !=
> - var->left_margin + var->xres + var->right_margin ||
> - vmode->upper_margin + vmode->yres + vmode->lower_margin !=
> - var->upper_margin + var->yres + var->lower_margin)
> + long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
> + long dx, dy;
I don't think these need to be longs? And they probably don't need to be
signed either.
If a switch to u32 improves the code any, it might be worth doing..
All the typecasting which this patch adds makes me wonder if the choice
of types requires a general revisit...
^ permalink raw reply
* Load Kernel 2.6 using U-boot on ML403
From: Yedu Jathavedan @ 2008-01-27 7:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Plaintext Version of Message --]
[-- Type: text/plain, Size: 6997 bytes --]
Hi,
/I have downloaded the 2.6 kernel from
/http://git.secretlab.ca/git/linux-2.6-virtex.git , installed &
compiled it. I used "make ARCH=ppc CROSS_COMPILE=ppc_4xx-
ml403_defconfig" to build the .config file. (As explained in
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex)PROBLEM -
1)Downloaded(sourceforge.net) & compiled the U-boot 1.1.6 files to
get u-boot, u-boot.srec & u-boot.bin (I didn't find ml403 board config
for the uboot. So used ml300_config).
After this, I tried to convert the u-boot (README says that this is
an ELF file) into an ace file. But, it gave me the error saying unable
to read elf file. Is it because ML403 board is not supported or is it
possible that the u-boot image that I created is corrupted?
$ xmd -tcl genace.tcl -jprog -board ml403 -hw download.bit -elf
u-boot -ace uboot.ace
Xilinx EDK 9.1 Build EDK_J.19
Executing xmd script : $HOME/EDK/data/xmd/genace.tcl
#######################################################################
XMD GenACE utility. Generate SystemACE File from bit/elf/data Files
#######################################################################
Target Type not defined for Processor 1, Using default Target Type ppc_hw
GenACE Options:
Board : ml403
Jtag Devs : xcf32p xc4vfx12 xc95144xl
FPGA pos : 2
JPROG : true
HW File : download.bit
ACE File : uboot.ace
nCPUs : 1
Processor ppc_hw_1 Information
Debug opt : -debugdevice devicenr 2 cpunr 1
ELF files : u-boot
Start PC Address : 0xfff80000
############################################################
Converting Bitstream 'download.bit' to SVF file 'download.svf'
Executing 'impact -batch bit2svf.scr'
Copying download.svf File to uboot.svf File
############################################################
Converting ELF file 'u-boot' to SVF file 'u-boot.svf'
Error: E02 Failed to download ELF file
ERROR(1053): UNABLE to Read Elf File. The Elf File Maybe Corrupted
: u-boot
#$
-------------------------
PROBLEM -
2) Since generating ace files failed, I tried to search the net for an
u-boot ace file that could run on ML403 & found it at
http://88.191.24.164/docenligne/projets/samba/2006/linux-embarque-sur-ml-403/u-boot-ml403.ace/view
I copied this ace file (u-boot-ml403.ace) along with the kernel 2.6
image (uImage) onto my CF card & booted the board. After loading the
kernel, it fails to read the correct root device. I tried changing the
"bootargs" env variable root = /dev/xsysace/disc0/part2 rw to root =
/dev/xsysace2 rw & root = /dev/xsda2 rw.
But, it failed in both cases. (There was a previous post on
Problem2 a year ago & he solved it by giving root =/dev/xsysace2)
Environment size: 246/1020 bytes
#u-boot> setenv bootargs console=ttyS0,9600 root=/dev/xsysace2 rw
#u-boot> fatload ace 0 0x400000 uImage
reading uImage
952237 bytes read
#u-boot> bootm 0x400000
## Booting image at 00400000 ...
Image Name: Linux-2.6.24-rc3
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 952173 Bytes = 929.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
[ 0.000000] Linux version 2.6.24-rc3 (icdt@icdt05) (gcc version
4.0.0 (DENX ELDK 4.0 4.0.0)) #1 Fri Jan 25 21:23:54 PST 2008
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 16384
[ 0.000000] Normal 16384 -> 16384
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16256
[ 0.000000] Kernel command line: console=ttyS0,9600 ip=off
root=/dev/xsysace root=/dev/xsysace2 rw
[ 0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000179] Console: colour dummy device 80x25
[ 0.000669] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.001431] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.015197] Memory: 62860k available (1452k kernel code, 496k data,
96k init, 0k highmem)
[ 0.204614] Mount-cache hash table entries: 512
[ 0.209345] net_namespace: 64 bytes
[ 0.213840] NET: Registered protocol family 16
[ 0.252576] NET: Registered protocol family 2
[ 0.288713] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.291229] TCP established hash table entries: 2048 (order: 2,
16384 bytes)
[ 0.291535] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.291709] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.291737] TCP reno registered
[ 0.301433] sysctl table check failed: /kernel/l2cr .1.31 Missing strategy
[ 0.301509] Call Trace:
[ 0.301528] [c3c17e80] [c00084f4] show_stack+0x4c/0x174 (unreliable)
[ 0.301611] [c3c17eb0] [c00305e0] set_fail+0x50/0x68
[ 0.301678] [c3c17ed0] [c0030c68] sysctl_check_table+0x670/0x6bc
[ 0.301726] [c3c17f10] [c0030c7c] sysctl_check_table+0x684/0x6bc
[ 0.301771] [c3c17f50] [c001df28] register_sysctl_table+0x5c/0xac
[ 0.301832] [c3c17f70] [c01dca84] register_ppc_htab_sysctl+0x18/0x2c
[ 0.301897] [c3c17f80] [c01d6848] kernel_init+0xc8/0x284
[ 0.301938] [c3c17ff0] [c0004af8] kernel_thread+0x44/0x60
[ 0.307739] io scheduler noop registered
[ 0.307792] io scheduler anticipatory registered (default)
[ 0.307817] io scheduler deadline registered
[ 0.307967] io scheduler cfq registered
[ 0.364669] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
IRQ sharing disabled
[ 0.370815] serial8250.0: ttyS0 at MMIO 0xa0001003 (irq = 9) is a 16450
[ 0.370893] console [ttyS0] enabled
[ 3.286815] RAMDISK driver initialized: 16 RAM disks of 65536K size
1024 blocksize
[ 3.376997] tun: Universal TUN/TAP device driver, 1.6
[ 3.437161] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 3.512736] mice: PS/2 mouse device common for all mice
[ 3.574814] TCP cubic registered
[ 3.613145] NET: Registered protocol family 1
[ 3.665227] NET: Registered protocol family 17
[ 3.720647] VFS: Cannot open root device "xsysace2" or unknown-block(0,0)
[ 3.801333] Please append a correct "root=" boot option; here are
the available partitions:
[ 3.901354] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(0,0)
[ 4.000286] Rebooting in 180 seconds..
-------------------------
Can anyone help me with either one (or both) of the above problems? I
have pretty much run out of ideas. :(
Thanks & Regards,
Yedu
[-- Attachment #1.2: HTML Version of Message --]
[-- Type: text/html, Size: 8005 bytes --]
[-- Attachment #2.1: Type: multipart/alternative, Size: 0 bytes --]
[-- Attachment #2.2: Plaintext Version of Message --]
[-- Type: text/plain, Size: 429 bytes --]
Hi,
/ GOAL - To use the USB Host on ML403 in a PowerPC processor reference
system to store some data on a Thumb Drive./
/BACKGROUND - I downloaded the 2.6 kernel from
/http://git.secretlab.ca/git/linux-2.6-virtex.git , installed &
compiled it to get uImage & zImage.elf files. I used "make
ml403_defconfig" to build the .config file. (As explained in
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex)
[-- Attachment #2.3: HTML Version of Message --]
[-- Type: text/html, Size: 693 bytes --]
^ permalink raw reply
* Re: [patch 04/11] ps3fb: Inline macros that are used only once
From: Geert Uytterhoeven @ 2008-01-27 9:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080126220133.eb99e5c4.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1080 bytes --]
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:27 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> >
> > ps3fb: inline the X_OFF(), Y_OFF(), WIDTH(), HEIGHT(), and VP_OFF() macros,
> > as they're used in one place only
>
> I think the term "open-code" would be more suitable here. "inlining" means
> "make it an inline function". I'll update the changelog.
You're right. Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Geert Uytterhoeven @ 2008-01-27 9:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080126220139.5385f2c7.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1334 bytes --]
Hi Andrew,
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > Hare are the ps3av/fb patches for 2.6.25:
>
> I would have to say: it's a bit late to be submitting things of this nature
> for 2.6.25. Given the mess everyone has made of everything there's little
> chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> into mainline without public testing.
I beg to disagree (of course :-)
I posted these patches before, about 2 months ago. Unfortunately I didn't CC
you at that time, so they slipped under your radar.
But the patches did receive public testing even before that, when they entered
Geoff's ps3-linux.git tree.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 09/11] ps3fb: Round up video modes
From: Geert Uytterhoeven @ 2008-01-27 9:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <20080126220143.16c8f821.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2023 bytes --]
On Sat, 26 Jan 2008, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 16:06:32 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
> > const struct fb_var_screeninfo *var)
> > {
> > - /* resolution + black border must match a native resolution */
> > - if (vmode->left_margin + vmode->xres + vmode->right_margin !=
> > - var->left_margin + var->xres + var->right_margin ||
> > - vmode->upper_margin + vmode->yres + vmode->lower_margin !=
> > - var->upper_margin + var->yres + var->lower_margin)
> > + long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
> > + long dx, dy;
>
> I don't think these need to be longs? And they probably don't need to be
> signed either.
>
> If a switch to u32 improves the code any, it might be worth doing..
>
> All the typecasting which this patch adds makes me wonder if the choice
> of types requires a general revisit...
The problems are:
- Adding up the various fb_var_screeninfo.* timing fields (which are u32) may
cause overflows. That's why I use `long' (which is 64-bit on ppc64).
Perhaps I should change it to s64 for readability?
- If I make xres, yres, left_margin, right_margin, upper_margin, lower_margin
u32, I need more casts for calculating dx and dy. Probably u64 would be OK,
though.
- dx and dy are signed because they can be smaller than 0.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Andrew Morton @ 2008-01-27 10:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, adaplas
In-Reply-To: <Pine.LNX.4.64.0801271041160.10193@vixen.sonytel.be>
> On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Hi Andrew,
>
> On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > Hare are the ps3av/fb patches for 2.6.25:
> >
> > I would have to say: it's a bit late to be submitting things of this nature
> > for 2.6.25. Given the mess everyone has made of everything there's little
> > chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> > into mainline without public testing.
>
> I beg to disagree (of course :-)
>
> I posted these patches before, about 2 months ago. Unfortunately I didn't CC
> you at that time, so they slipped under your radar.
> But the patches did receive public testing even before that, when they entered
> Geoff's ps3-linux.git tree.
>
Should that git tree be in the -mm lineup?
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Geert Uytterhoeven @ 2008-01-27 11:15 UTC (permalink / raw)
To: Andrew Morton, Geoff Levand
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Cell Broadband Engine OSS Development, Antonino Daplas
In-Reply-To: <20080127021659.fb6c72a1.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1621 bytes --]
Hi Andrew,
On Sun, 27 Jan 2008, Andrew Morton wrote:
> > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > > Hare are the ps3av/fb patches for 2.6.25:
> > >
> > > I would have to say: it's a bit late to be submitting things of this nature
> > > for 2.6.25. Given the mess everyone has made of everything there's little
> > > chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> > > into mainline without public testing.
> >
> > I beg to disagree (of course :-)
> >
> > I posted these patches before, about 2 months ago. Unfortunately I didn't CC
> > you at that time, so they slipped under your radar.
> > But the patches did receive public testing even before that, when they entered
> > Geoff's ps3-linux.git tree.
>
> Should that git tree be in the -mm lineup?
That may be a good idea! Geoff?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Paul Mackerras @ 2008-01-27 11:55 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, LKML
In-Reply-To: <20080126071339.GA25328@balbir.in.ibm.com>
Balbir Singh writes:
> Here's a better and more complete fix for the problem. Could you
> please see if it works for you? I tested it on a real NUMA box and it
> seemed to work fine there.
There are a couple of other changes in behaviour that your patch
introduces, and I'd like to understand them better before taking the
patch. First, with your patch we don't set nodes online if they end
up having no memory in them because of the memory limit, whereas
previously we did. Secondly, in the case where we don't have NUMA
information, we now set node 0 online after adding each LMB, whereas
previously we only set it online once.
If in fact these changes are benign, then your patch description
should mention them and explain why they are benign.
Paul.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Jochen Friedrich @ 2008-01-27 13:42 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Arnd Bergmann, linuxppc-dev, David Gibson
In-Reply-To: <20080108184525.GC18445@localhost.localdomain>
Hi Anton,
> +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct port_regs *regs = mm_gc->regs;
> + u32 pin_mask;
> + u32 tmp_val;
> +
> + /* calculate pin location */
> + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> +
> + tmp_val = in_be32(®s->cpdata);
> +
> + if (val == 0)
> + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> + else
> + out_be32(®s->cpdata, pin_mask | tmp_val);
> +}
I see a possible problem with this (and in the corresponding call in CPM1, as well):
if there is a pin configured as open drain, you might accidently switch this pin to 0
while switching a different pin, if an external device is pulling the pin to 0.
i2c-gpio.c and w1-gpio.c (in -mm) are examples of drivers which use open drain pins
and which would fail if another pin on the same port would be set during a transfer.
Thanks,
Jochen
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Josh Boyer @ 2008-01-27 13:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Frame Buffer Device Development, Antonino Daplas, Cell,
Linux/PPC Development, Andrew Morton, Development
In-Reply-To: <Pine.LNX.4.64.0801271215120.10514@vixen.sonytel.be>
On Sun, 27 Jan 2008 12:15:28 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Hi Andrew,
>
> On Sun, 27 Jan 2008, Andrew Morton wrote:
> > > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > On Sat, 26 Jan 2008, Andrew Morton wrote:
> > > > > On Fri, 25 Jan 2008 16:06:23 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > > > > Hare are the ps3av/fb patches for 2.6.25:
> > > >
> > > > I would have to say: it's a bit late to be submitting things of this nature
> > > > for 2.6.25. Given the mess everyone has made of everything there's little
> > > > chance that I'll be able to do a 2.6.24-mm1 so this stuff basically goes
> > > > into mainline without public testing.
> > >
> > > I beg to disagree (of course :-)
> > >
> > > I posted these patches before, about 2 months ago. Unfortunately I didn't CC
> > > you at that time, so they slipped under your radar.
> > > But the patches did receive public testing even before that, when they entered
> > > Geoff's ps3-linux.git tree.
> >
> > Should that git tree be in the -mm lineup?
>
> That may be a good idea! Geoff?
There are lots of powerpc sub-trees. Kumar's, Geoff's, mine, Olof's,
Grant's, Vitaly's are just the ones I can think of the top of my head.
Shouldn't we just ask Paul to sync up more often rather than have
Andrew track X number of trees that eventually all merge into Paul's
anyway?
josh
^ permalink raw reply
* [ppc] Disparity between sys_clock_getres and vdso implementation
From: Sripathi Kodi @ 2008-01-27 14:02 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel, john stultz
Hi Paul,
On PPC, I see a disparity between clock_getres implementations in the
vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
with CONFIG_HIGH_RES_TIMERS=y.
clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
to be returning some pre-defined (incorrect) variables.
Could you please let me know the reason for this? Is it something that
should be fixed in vdso?
Thanks,
Sripathi.
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Balbir Singh @ 2008-01-27 15:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, LKML
In-Reply-To: <18332.28991.658933.763115@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> [2008-01-27 22:55:43]:
> Balbir Singh writes:
>
> > Here's a better and more complete fix for the problem. Could you
> > please see if it works for you? I tested it on a real NUMA box and it
> > seemed to work fine there.
>
> There are a couple of other changes in behaviour that your patch
> introduces, and I'd like to understand them better before taking the
> patch. First, with your patch we don't set nodes online if they end
> up having no memory in them because of the memory limit, whereas
> previously we did. Secondly, in the case where we don't have NUMA
> information, we now set node 0 online after adding each LMB, whereas
> previously we only set it online once.
>
> If in fact these changes are benign, then your patch description
> should mention them and explain why they are benign.
>
Yes, they are. I'll try and justify the changes with a good detailed
changelog. If people prefer it, I can hide fake NUMA nodes under a
config option, so that it does not come enabled by default.
Thanks for keeping me honest.
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Michel Dänzer @ 2008-01-27 16:13 UTC (permalink / raw)
To: vatsa; +Cc: Ingo Molnar, Peter Zijlstra, linuxppc-dev
In-Reply-To: <20080126050757.GB14177@linux.vnet.ibm.com>
On Sat, 2008-01-26 at 10:39 +0530, Srivatsa Vaddagiri wrote:
> On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
>
> > > Also were the dd process and the niced processes running under
> > > different user ids? If so, that is expected behavior, that we divide
> > > CPU equally among users first and then among the processes within each user.
Note that in my test case, the niced infinite loop constantly burns
significantly more than 50% of the cycles; X and its clients never need
more than 20% (high estimate) each to move windows smoothly. So even
under the premise above, it should be possible to have smooth
interaction with X while there is a CPU hog in another group, shouldn't
it?
> > Not that it seems that Michel reported far worse behaviour than what I
> > saw, including pretty hickup'ish X behaviour even without the fair group
> > scheduler compared to 2.6.23. It might be because he's running X niced
> > to -1 (I leave X at 0 and let the scheduler deal with it in general)
> > though.
>
> Hmm ..with X niced to -1, it should get more cpu power leading to a
> better desktop experience.
FWIW, -1 or 0 for X doesn't seem to make any difference for this
problem.
(I've had X at -1 because a long time ago, when it was at 0 some 3D
games could starve it to the point that their input would be delayed)
> Michel,
> You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> was the cause for this bad behavior.
Well, it may not be the cause, but that's where the hickups with
CONFIG_FAIR_USER_SCHED disabled first manifest themselves, yes.
> Do you see behavior change (from good->bad) immediately after applying that patch
> during your bisect process?
Yes, confirmed by trying that commit and its parent again.
> > > 1. Run niced tasks as root. This would bring X and niced tasks in the
> > > same "scheduler group" domain, which would give X much more CPU power
> > > when compared to niced tasks.
Running the niced CPU hog as root or my user instead of as nobody didn't
seem to make a difference, maybe because the X session requires
interaction between processes having different uids, and disturbing
either is sufficient.
> > > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > > cpu share.
> > > # echo 8192 > /sys/kernel/uids/0/cpu_share
> > >
> > > This should bump up root user's priority for running on CPU and also
> > > give a better desktop experience.
I didn't try 8192, but bumping the shares of root and my user up to 4096
didn't seem to help much if at all. Decreasing the share of the user
running the niced CPU hog to 1 resulted in more or less the same
behaviour as with CONFIG_FAIR_USER_SCHED disabled.
> > > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > > could be. sched-devel has a better load balancer, which I am presuming
> > > will go into 2.6.25 soon.
FWIW, the scheduler changes merged after 2.6.24 don't seem to help at
all for my test:
With CONFIG_FAIR_USER_SCHED enabled, X still becomes unusable.
With CONFIG_FAIR_USER_SCHED disabled, X remains mostly usable, but there
are still hickups that weren't there with 2.6.23. (BTW, the hickups seem
related to top running in the terminal window I'm trying to move;
without top running, there are no hickups when moving the window. With
2.6.23, there are no hickups even with top running)
Note that my test case is an exaggerated example constructed from worse
(than with 2.6.23) interactive behaviour I've been seeing with my
day-to-day X session. This isn't just a theoretical problem.
> > > In this case, I suspect that's not the issue. If X and the niced processes are
> > > running under different uids, this (niced processes getting more cpu power) is
> > > on expected lines. Will wait for Ben to confirm this.
> >
> > I would suggest turning the fair group scheduler to default n in stable
> > for now.
>
> I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> think is the desktop experience with that combination?
Seems to be the same as with CONFIG_FAIR_GROUP_SCHED disabled
completely.
In summary, there are two separate problems with similar symptoms, which
had me confused at times:
* With CONFIG_FAIR_USER_SCHED disabled, there are severe
interactivity hickups with a niced CPU hog and top running. This
started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8.
* With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
unusable with a niced CPU hog, with or without top running. I
don't know when this started, possibly when this option was
first introduced.
I don't personally care too much about the latter problem - I can live
well without that option. But it would be nice if the former problem
could be fixed (and the default changed from CONFIG_FAIR_USER_SCHED to
CONFIG_FAIR_CGROUP_SCHED) in 2.6.24.x.
FWIW, the patch below (which reverts commit
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8) restores 2.6.24 interactivity
to the same level as 2.6.23 here with CONFIG_FAIR_USER_SCHED disabled
(my previous report to the contrary was with CONFIG_FAIR_USER_SCHED
enabled because I didn't yet realize the difference it makes), but I
don't know if that's the real fix.
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
struct task_struct *curr = rq->curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = &curr->se, *pse = &p->se;
- unsigned long gran;
if (unlikely(rt_prio(p->prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se->load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, &se->load);
- if (pse->vruntime + gran < se->vruntime)
+ if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
resched_task(curr);
}
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox