* Re: [LTP] [PATCH] Fix Makefile of testcase/kernel/mem/ksm/
From: Bian Naimeng @ 2011-01-26 7:07 UTC (permalink / raw)
To: Garrett Cooper; +Cc: ltp-list
In-Reply-To: <AANLkTin52dVdOUf0K25Sma2NrGLmet9aK7tbUmg3fKds@mail.gmail.com>
Garrett Cooper wrote:
> On Tue, Jan 25, 2011 at 10:54 PM, Bian Naimeng <biannm@cn.fujitsu.com> wrote:
>> There is not any directory at testcase/kernel/mem/ksm/,
>> so replace generic_trunk_target.mk by generic_leaf_target.mk
>>
>> Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
>>
>> ---
>> testcases/kernel/mem/ksm/Makefile | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/testcases/kernel/mem/ksm/Makefile b/testcases/kernel/mem/ksm/Makefile
>> index 81509bf..22190f1 100644
>> --- a/testcases/kernel/mem/ksm/Makefile
>> +++ b/testcases/kernel/mem/ksm/Makefile
>> @@ -39,5 +39,5 @@ trunk-clean:: | lib-clean
>> lib-clean:: $(LIBDIR)
>> $(MAKE) -C $^ -f "$(abs_srcdir)/$^/Makefile" clean
>>
>> -include $(top_srcdir)/include/mk/generic_trunk_target.mk
>> include $(top_srcdir)/include/mk/testcases.mk
>> +include $(top_srcdir)/include/mk/generic_leaf_target.mk
>
> Forgot about that Makefile that Cai submitted. How about this instead?
Looks better than mine. Please commit it.
Thanks
Bian
> Thanks,
> -Garrett
>
> diff --git a/testcases/kernel/mem/ksm/Makefile
> b/testcases/kernel/mem/ksm/Makefile
> index 81509bf..fdff5fc 100644
> --- a/testcases/kernel/mem/ksm/Makefile
> +++ b/testcases/kernel/mem/ksm/Makefile
> @@ -18,7 +18,7 @@
>
> top_srcdir ?= ../../../..
>
> -include $(top_srcdir)/include/mk/env_pre.mk
> +include $(top_srcdir)/include/mk/testcases.mk
>
> LDLIBS += $(NUMA_LIBS) -lmem
> LIBDIR := ../lib
> @@ -39,5 +39,4 @@ trunk-clean:: | lib-clean
> lib-clean:: $(LIBDIR)
> $(MAKE) -C $^ -f "$(abs_srcdir)/$^/Makefile" clean
>
> -include $(top_srcdir)/include/mk/generic_trunk_target.mk
> -include $(top_srcdir)/include/mk/testcases.mk
> +include $(top_srcdir)/include/mk/generic_leaf_target.mk
>
>
--
Regards
Bian Naimeng
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix error handling in ath5k_hw_dma_stop
From: Stanislaw Gruszka @ 2011-01-26 7:05 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, mickflemm, Bruno Randolf, jirislaby,
lrodriguez
In-Reply-To: <20110126015034.GA8600@hash.localnet>
On Tue, Jan 25, 2011 at 08:50:34PM -0500, Bob Copeland wrote:
> From: Bob Copeland <me@bobcopeland.com>
> Date: Mon, 24 Jan 2011 09:25:11 -0500
> Subject: [PATCH] ath5k: fix error handling in ath5k_hw_dma_stop
>
> Review spotted a problem with the error handling in ath5k_hw_dma_stop:
> a successful return from ath5k_hw_stop_tx_dma will be treated as
> an error, so we always bail out of the loop after processing a single
> active queue. As a result, we may not actually stop some queues during
> reset.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
>
> > Patch is good, but does not make code fully correct. When last queue
> > is inactive, we return -EINVAL from ath5_hw_dma_stop(). So we need
> > also:
> >
> > if (err && err != -EINVAL)
> > return err;
> > + err = 0;
> > }
>
> > But perhaps, would be better just return 0 from
> > ath5k_hw_stop_tx_dma() when queue is inactive.
>
> How about this version instead?
It's better :)
> diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
> index 0064be7..21091c2 100644
> --- a/drivers/net/wireless/ath/ath5k/dma.c
> +++ b/drivers/net/wireless/ath/ath5k/dma.c
> @@ -838,9 +838,9 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
> for (i = 0; i < qmax; i++) {
> err = ath5k_hw_stop_tx_dma(ah, i);
> /* -EINVAL -> queue inactive */
> - if (err != -EINVAL)
> + if (err && err != -EINVAL)
> return err;
> }
>
> - return err;
> + return 0;
> }
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [LTP] [PATCH] Fix Makefile of testcase/kernel/mem/ksm/
From: CAI Qian @ 2011-01-26 7:06 UTC (permalink / raw)
To: Garrett Cooper; +Cc: ltp-list
In-Reply-To: <AANLkTin52dVdOUf0K25Sma2NrGLmet9aK7tbUmg3fKds@mail.gmail.com>
----- Original Message -----
> On Tue, Jan 25, 2011 at 10:54 PM, Bian Naimeng <biannm@cn.fujitsu.com>
> wrote:
> > There is not any directory at testcase/kernel/mem/ksm/,
> > so replace generic_trunk_target.mk by generic_leaf_target.mk
> >
> > Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
> >
> > ---
> > testcases/kernel/mem/ksm/Makefile | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/testcases/kernel/mem/ksm/Makefile
> > b/testcases/kernel/mem/ksm/Makefile
> > index 81509bf..22190f1 100644
> > --- a/testcases/kernel/mem/ksm/Makefile
> > +++ b/testcases/kernel/mem/ksm/Makefile
> > @@ -39,5 +39,5 @@ trunk-clean:: | lib-clean
> > lib-clean:: $(LIBDIR)
> > $(MAKE) -C $^ -f "$(abs_srcdir)/$^/Makefile" clean
> >
> > -include $(top_srcdir)/include/mk/generic_trunk_target.mk
> > include $(top_srcdir)/include/mk/testcases.mk
> > +include $(top_srcdir)/include/mk/generic_leaf_target.mk
>
> Forgot about that Makefile that Cai submitted. How about this instead?
It is not me but Lucas.
> Thanks,
> -Garrett
>
> diff --git a/testcases/kernel/mem/ksm/Makefile
> b/testcases/kernel/mem/ksm/Makefile
> index 81509bf..fdff5fc 100644
> --- a/testcases/kernel/mem/ksm/Makefile
> +++ b/testcases/kernel/mem/ksm/Makefile
> @@ -18,7 +18,7 @@
>
> top_srcdir ?= ../../../..
>
> -include $(top_srcdir)/include/mk/env_pre.mk
> +include $(top_srcdir)/include/mk/testcases.mk
>
> LDLIBS += $(NUMA_LIBS) -lmem
> LIBDIR := ../lib
> @@ -39,5 +39,4 @@ trunk-clean:: | lib-clean
> lib-clean:: $(LIBDIR)
> $(MAKE) -C $^ -f "$(abs_srcdir)/$^/Makefile" clean
>
> -include $(top_srcdir)/include/mk/generic_trunk_target.mk
> -include $(top_srcdir)/include/mk/testcases.mk
> +include $(top_srcdir)/include/mk/generic_leaf_target.mk
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply
* [PATCH] ARM: DT: Add SMDKV310 machine with device tree support.
From: Thomas Abraham @ 2011-01-26 7:03 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: kgene.kim-Sze3O3UU22JBDgjK7y7TUQ
This patch adds a new SMDKV310 machine that boots with a minimal
device tree support. The bootargs and memory information is obtained
from the device tree during boot.
This patch is based on git://git.secretlab.ca/git/linux-2.6 devicetree/arm
Signed-off-by: Thomas Abraham <thomas.ab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/mach-s5pv310/Kconfig | 8 ++
arch/arm/mach-s5pv310/Makefile | 1 +
arch/arm/mach-s5pv310/mach-smdkv310-dt.c | 108 ++++++++++++++++++++++++++++++
3 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/mach-smdkv310-dt.c
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index 09c4c21..c0ef0f8 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -127,6 +127,14 @@ config MACH_SMDKV310
help
Machine support for Samsung SMDKV310
+config MACH_SMDKV310_DT
+ bool "SMDKV310 with device tree support"
+ select CPU_S5PV310
+ select USE_OF
+ select S3C_DEV_WDT
+ help
+ Machine support for Samsung SMDKV310 with device tree based initialization.
+
endmenu
comment "Configuration for HSMMC bus width"
diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile
index 036fb38..59545aa 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_MACH_SMDKC210) += mach-smdkc210.o
obj-$(CONFIG_MACH_SMDKV310) += mach-smdkv310.o
+obj-$(CONFIG_MACH_SMDKV310_DT) += mach-smdkv310-dt.o
obj-$(CONFIG_MACH_UNIVERSAL_C210) += mach-universal_c210.o
# device support
diff --git a/arch/arm/mach-s5pv310/mach-smdkv310-dt.c b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
new file mode 100644
index 0000000..1e5f379
--- /dev/null
+++ b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
@@ -0,0 +1,108 @@
+/* linux/arch/arm/mach-s5pv310/mach-smdkv310.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <linux/serial_core.h>
+#include <linux/gpio.h>
+#include <linux/mmc/host.h>
+#include <linux/platform_device.h>
+#include <linux/smsc911x.h>
+#include <linux/io.h>
+#include <linux/i2c.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+
+#include <plat/regs-serial.h>
+#include <plat/regs-srom.h>
+#include <plat/s5pv310.h>
+#include <plat/cpu.h>
+#include <plat/devs.h>
+#include <plat/sdhci.h>
+#include <plat/iic.h>
+#include <plat/pd.h>
+
+#include <mach/map.h>
+
+/* Following are default values for UCON, ULCON and UFCON UART registers */
+#define SMDKV310_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
+ S3C2410_UCON_RXILEVEL | \
+ S3C2410_UCON_TXIRQMODE | \
+ S3C2410_UCON_RXIRQMODE | \
+ S3C2410_UCON_RXFIFO_TOI | \
+ S3C2443_UCON_RXERR_IRQEN)
+
+#define SMDKV310_ULCON_DEFAULT S3C2410_LCON_CS8
+
+#define SMDKV310_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \
+ S5PV210_UFCON_TXTRIG4 | \
+ S5PV210_UFCON_RXTRIG4)
+
+static struct s3c2410_uartcfg smdkv310_uartcfgs[] __initdata = {
+ [0] = {
+ .hwport = 0,
+ .flags = 0,
+ .ucon = SMDKV310_UCON_DEFAULT,
+ .ulcon = SMDKV310_ULCON_DEFAULT,
+ .ufcon = SMDKV310_UFCON_DEFAULT,
+ },
+ [1] = {
+ .hwport = 1,
+ .flags = 0,
+ .ucon = SMDKV310_UCON_DEFAULT,
+ .ulcon = SMDKV310_ULCON_DEFAULT,
+ .ufcon = SMDKV310_UFCON_DEFAULT,
+ },
+ [2] = {
+ .hwport = 2,
+ .flags = 0,
+ .ucon = SMDKV310_UCON_DEFAULT,
+ .ulcon = SMDKV310_ULCON_DEFAULT,
+ .ufcon = SMDKV310_UFCON_DEFAULT,
+ },
+ [3] = {
+ .hwport = 3,
+ .flags = 0,
+ .ucon = SMDKV310_UCON_DEFAULT,
+ .ulcon = SMDKV310_ULCON_DEFAULT,
+ .ufcon = SMDKV310_UFCON_DEFAULT,
+ },
+};
+
+static struct platform_device *smdkv310_devices[] __initdata = {
+ &s3c_device_wdt,
+};
+
+static void __init smdkv310_map_io(void)
+{
+ s5p_init_io(NULL, 0, S5P_VA_CHIPID);
+ s3c24xx_init_clocks(24000000);
+ s3c24xx_init_uarts(smdkv310_uartcfgs, ARRAY_SIZE(smdkv310_uartcfgs));
+}
+
+static void __init smdkv310_machine_init(void)
+{
+ platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
+}
+
+static const char *smdkv310_dt_compat[] = {
+ "samsung,smdkv310",
+ NULL
+};
+
+MACHINE_START(SMDKV310, "SMDKV310")
+ /* Maintainer: Kukjin Kim <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> */
+ /* Maintainer: Changhwan Youn <chaos.youn-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> */
+ .boot_params = S5P_PA_SDRAM + 0x100,
+ .init_irq = s5pv310_init_irq,
+ .map_io = smdkv310_map_io,
+ .init_machine = smdkv310_machine_init,
+ .timer = &s5pv310_timer,
+ .dt_compat = smdkv310_dt_compat,
+MACHINE_END
--
1.6.6.rc2
^ permalink raw reply related
* Re: Master stability update
From: Xu, Dongxiao @ 2011-01-26 7:01 UTC (permalink / raw)
To: Wold, Saul, Richard Purdie; +Cc: poky
In-Reply-To: <4D3FC60D.5000003@intel.com>
Saul Wold wrote:
> On 01/25/2011 02:07 PM, Richard Purdie wrote:
>> We merged the features into master. I just want to highlight the
>> status of the following issues:
>>
>> * pseudo problem causing failure of meta-toolchain and corruption of
>> certain file permissions - fixed in master
>>
>> * the -live image issues some people and the autobuilder were seeing
>> -
>> fixed in master
>>
>> * the perf issue for linux-yocto-stable - fixed in master
>>
>> The following are know issues with master:
>>
>> * Using rm_work and switching machines to machines of the same
>> "multimachine" architecture breaks.
>>
>> * When switching machines of the same "multimachine" architecture
>> (e.g.
>> emenlow to atom-pc), some sstate packages are changing checksums when
>> at first glance they shouldn't (e.g. perl do_install). A quick scan
>> of
>> my sstate directory:
>>
>> $ ls *core2* | sed -e 's#core2-2-.*_#core2-2_#' | sort | uniq -cd |
>> grep -v siginfo
>>
>> yields:
>>
>> 2
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-ipk.tgz
>> 2
>> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-rpm.tgz
>> 2
>> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_package.tgz
>> 2
>> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_populate-sysroot.tgz
>> 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-ipk.tgz 2
>> sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-rpm.tgz 2
>> sstate-netbase-core2-poky-linux-4.44-r0-core2-2_package.tgz 2
>> sstate-netbase-core2-poky-linux-4.44-r0-core2-2_populate-sysroot.tgz
>> 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-ipk.tgz 2
>> sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-rpm.tgz 2
>> sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_package.tgz 2
>> sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_populate-sysroot.tgz
>> 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-ipk.tgz 2
>> sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-rpm.tgz 2
>> sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_package.tgz 2
>> sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_populate-sysroot.tgz 2
>> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-ipk.tgz
>> 2
>> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-rpm.tgz
>> 2
>> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_package.tgz
>> 2
>> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_populate-sysroot.tgz
>> 2
>> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-ipk.tgz
>> 2
>> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-rpm.tgz
>> 2
>> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_package.tgz
>> 2
>> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be24391
>> 49d9ede37531-r3-core2-2_populate-sysroot.tgz
>>
>> which isn't too bad but shows there are some issues creeping in
>> there.
>> These need investigating and fixing, there is a strong rpm theme
>> going
>> on there. Also note this was just a minimal image, sato will likely
>> reveal other issues.
>>
>> Cheers,
>>
>> Richard
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>>
>
> We are looking pretty good after the nightly has been running, a
> couple of issues were discovered by the Autobuilder, but we are more
> stable than we have been for a while.
>
> Thanks to everyone for their hard work.
>
> Seems that we have a couple of additional issues that need to be
> addressed.
>
> 1) Recent changes to the send-pull-request have caused the problem
> with the email now coming from poky-bounces. * dvhart or sgarman
> should investigate this please
>
> 2) atom-pc connman failure, Dongxiao may have already submitted a
> patch
This should be the same issue of doing "rm_work" when building the first machine (autobuilder inherits rm_work.bbclass).
I just sent out a fix patch for review.
Thanks,
Dongxiao
>
> 3) emenlow rootfs failure, may be related to zypper/rpm, need to
> verify with Mark and his patch.
>
> Thanks
> Sau!
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
^ permalink raw reply
* kernel message of xen 4.0.1
From: wenche_chang @ 2011-01-26 6:59 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 5088 bytes --]
Hi
I use xen 4.0.1 and 2.6.32.23-170 by myoung, and create about 30 VMs in hypervisor
When I try to migrate them randomly in the same time , I got the following kernel message or reboot in some machines
Jan 26 06:27:23 nc-11 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
Jan 26 06:27:23 nc-11 kernel: IP: [<ffffffff811efbc3>] inode_has_perm+0x65/0x90
Jan 26 06:27:23 nc-11 kernel: PGD 14886067 PUD 20c85067 PMD 0
Jan 26 06:27:23 nc-11 kernel: Oops: 0000 [#6] SMP
Jan 26 06:27:23 nc-11 kernel: last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
Jan 26 06:27:23 nc-11 kernel: CPU 3
Jan 26 06:27:23 nc-11 kernel: Modules linked in: xt_mac xt_physdev tun ceph libceph libcrc32c blktap fuse xt_temac 8021q garp ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc ipv6 xen_netback xen_blkback blkback_pagemap xen_gntdev xen_evtchn xenfs dcdbas bnx2 iTCO_wdt power_meter iTCO_vendor_support joydev usb_storage [last unloaded: scsi_wait_scan]
Jan 26 06:27:23 nc-11 kernel: Pid: 5333, comm: ls Tainted: G D 2.6.32.23-170.Elaster.xendom0.fc12.x86_64 #1 PowerEdge R210
Jan 26 06:27:23 nc-11 kernel: RIP: e030:[<ffffffff811efbc3>] [<ffffffff811efbc3>] inode_has_perm+0x65/0x90
Jan 26 06:27:23 nc-11 kernel: RSP: e02b:ffff8800222ebd08 EFLAGS: 00010282
Jan 26 06:27:23 nc-11 kernel: RAX: ffff880003210d60 RBX: ffff880033f92cc0 RCX: ffff8800222ebda8
Jan 26 06:27:23 nc-11 kernel: RDX: 0000000000000010 RSI: ffff880068045d48 RDI: ffff88006ee560c0
Jan 26 06:27:23 nc-11 kernel: RBP: ffff8800222ebd98 R08: ffff8800222ebda8 R09: 0000000000000001
Jan 26 06:27:23 nc-11 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800b93eb300
Jan 26 06:27:23 nc-11 kernel: R13: ffff880068045d48 R14: 00007fff0de41f00 R15: 0000000000eea690
Jan 26 06:27:23 nc-11 kernel: FS: 00007f9ef2cff7a0(0000) GS:ffff88000c6be000(0000) knlGS:0000000000000000
Jan 26 06:27:23 nc-11 kernel: CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
Jan 26 06:27:23 nc-11 kernel: CR2: 0000000000000020 CR3: 00000000565b4000 CR4: 0000000000002660
Jan 26 06:27:23 nc-11 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 26 06:27:23 nc-11 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jan 26 06:27:23 nc-11 kernel: Process ls (pid: 5333, threadinfo ffff8800222ea000, task ffff88004587aea0)
Jan 26 06:27:23 nc-11 kernel: Stack:
Jan 26 06:27:23 nc-11 kernel: 0000000000100000 0000000000000000 ffffffff8100ef91 ffff8800222ebda8
Jan 26 06:27:23 nc-11 kernel: <0> ffffffff8100f6c2 0000000000100000 0000000000000001 0000000000000000
Jan 26 06:27:23 nc-11 kernel: <0> 0000000000000000 ffffea0002870200 ffffea000287f700 0000000000000000
Jan 26 06:27:23 nc-11 kernel: Call Trace:
Jan 26 06:27:23 nc-11 kernel: [<ffffffff8100ef91>] ? xen_force_evtchn_callback+0xd/0xf
Jan 26 06:27:23 nc-11 kernel: [<ffffffff8100f6c2>] ? check_events+0x12/0x20
Jan 26 06:27:23 nc-11 kernel: [<ffffffff8100f6af>] ? xen_restore_fl_direct_end+0x0/0x1
Jan 26 06:27:23 nc-11 kernel: [<ffffffff8110ef42>] ? kmem_cache_free+0x7e/0xb4
Jan 26 06:27:23 nc-11 kernel: [<ffffffff811f0030>] dentry_has_perm+0x5a/0x70
Jan 26 06:27:23 nc-11 kernel: [<ffffffff811f00c6>] selinux_inode_getattr+0x2c/0x2e
Jan 26 06:27:23 nc-11 kernel: [<ffffffff811e9225>] security_inode_getattr+0x25/0x27
Jan 26 06:27:23 nc-11 kernel: [<ffffffff81121972>] vfs_getattr+0x25/0x66
Jan 26 06:27:23 nc-11 kernel: [<ffffffff8112d311>] ? filldir+0x0/0xc4
Jan 26 06:27:23 nc-11 kernel: [<ffffffff811219fe>] vfs_fstatat+0x4b/0x62
Jan 26 06:27:23 nc-11 kernel: [<ffffffff81121a70>] vfs_lstat+0x1e/0x20
Jan 26 06:27:23 nc-11 kernel: [<ffffffff81121a91>] sys_newlstat+0x1f/0x3d
Jan 26 06:27:23 nc-11 kernel: [<ffffffff8145f495>] ? do_page_fault+0x2c2/0x2f2
Jan 26 06:27:23 nc-11 kernel: [<ffffffff810aa585>] ? audit_syscall_entry+0x11e/0x14a
Jan 26 06:27:23 nc-11 kernel: [<ffffffff81012d32>] system_call_fastpath+0x16/0x1b
Jan 26 06:27:23 nc-11 kernel: Code: 8b 96 30 02 00 00 44 8b 48 04 75 1f 4c 8d 85 70 ff ff ff b9 20 00 00 00 44 89 d8 4c 89 c7 f3 ab c6 85 70 ff ff ff 01 48 89 75 90 <41> 0f b7 42 20 41 8b 72 1c 89 d1 44 89 cf 89 c2 e8 3a e4 ff ff
Jan 26 06:27:23 nc-11 kernel: RIP [<ffffffff811efbc3>] inode_has_perm+0x65/0x90
Jan 26 06:27:23 nc-11 kernel: RSP <ffff8800222ebd08>
Jan 26 06:27:23 nc-11 kernel: CR2: 0000000000000020
Jan 26 06:27:23 nc-11 kernel: ---[ end trace b4379c3d3e1ecb00 ]---
It's a bug of kernel or xen or anything?
Thanks
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
[-- Attachment #1.2: Type: text/html, Size: 10339 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [RFC] arm devicetree meeting/hacking day
From: Jon Masters @ 2011-01-26 6:59 UTC (permalink / raw)
To: Grant Likely
Cc: Paul E. McKenney, linaro-dev, aneesh.v-QSEj5FYQhm4dnm+yROfE0A,
Loïc Minier, devicetree-discuss, Jason Hui, Deepak Saxena,
David Rusling, Thomas Abraham, Mounir Bsaibes, Jeremy Kerr,
Shawn Guo, arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A,
Lennert Buytenhek
In-Reply-To: <AANLkTi=1kQR2yFY8xJw=XX0aH5PG53sVmZCXf5fuUOu0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2011-01-24 at 13:25 -0700, Grant Likely wrote:
> For the hacking day, how does Tuesday(west)/Wednesday(east) sound for
> everyone? I'll be available on IRC, and I'll also keep my schedule
> clear so that I'll be available for phone calls.
Timing is key for me. I can lurk on IRC and poke at stuff, but it's
certainly easier "out of hours" as I'm not paid to do any of this :)
That said, I can make things fit and I want to be involved. Thanks for
reviving this (ARM), and for your many varied dt postings recently.
Jon.
^ permalink raw reply
* Re: Master stability update
From: Saul Wold @ 2011-01-26 6:58 UTC (permalink / raw)
To: Richard Purdie; +Cc: poky
In-Reply-To: <1295993245.27814.133.camel@rex>
On 01/25/2011 02:07 PM, Richard Purdie wrote:
> We merged the features into master. I just want to highlight the status
> of the following issues:
>
> * pseudo problem causing failure of meta-toolchain and corruption of
> certain file permissions - fixed in master
>
> * the -live image issues some people and the autobuilder were seeing -
> fixed in master
>
> * the perf issue for linux-yocto-stable - fixed in master
>
> The following are know issues with master:
>
> * Using rm_work and switching machines to machines of the same
> "multimachine" architecture breaks.
>
> * When switching machines of the same "multimachine" architecture (e.g.
> emenlow to atom-pc), some sstate packages are changing checksums when at
> first glance they shouldn't (e.g. perl do_install). A quick scan of my
> sstate directory:
>
> $ ls *core2* | sed -e 's#core2-2-.*_#core2-2_#' | sort | uniq -cd | grep -v siginfo
>
> yields:
>
> 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-ipk.tgz
> 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-rpm.tgz
> 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_package.tgz
> 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_populate-sysroot.tgz
> 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-ipk.tgz
> 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-rpm.tgz
> 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_package.tgz
> 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_populate-sysroot.tgz
> 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-ipk.tgz
> 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-rpm.tgz
> 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_package.tgz
> 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_populate-sysroot.tgz
> 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-ipk.tgz
> 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-rpm.tgz
> 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_package.tgz
> 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_populate-sysroot.tgz
> 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-ipk.tgz
> 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-rpm.tgz
> 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_package.tgz
> 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_populate-sysroot.tgz
> 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-ipk.tgz
> 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-rpm.tgz
> 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_package.tgz
> 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_populate-sysroot.tgz
>
> which isn't too bad but shows there are some issues creeping in there.
> These need investigating and fixing, there is a strong rpm theme going
> on there. Also note this was just a minimal image, sato will likely
> reveal other issues.
>
> Cheers,
>
> Richard
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
We are looking pretty good after the nightly has been running, a couple
of issues were discovered by the Autobuilder, but we are more stable
than we have been for a while.
Thanks to everyone for their hard work.
Seems that we have a couple of additional issues that need to be addressed.
1) Recent changes to the send-pull-request have caused the problem with
the email now coming from poky-bounces.
* dvhart or sgarman should investigate this please
2) atom-pc connman failure, Dongxiao may have already submitted a patch
3) emenlow rootfs failure, may be related to zypper/rpm, need to verify
with Mark and his patch.
Thanks
Sau!
^ permalink raw reply
* Re: [LTP] [PATCH] Fix Makefile of testcase/kernel/mem/ksm/
From: Garrett Cooper @ 2011-01-26 6:58 UTC (permalink / raw)
To: Bian Naimeng; +Cc: ltp-list
In-Reply-To: <4D3FC51B.3080306@cn.fujitsu.com>
On Tue, Jan 25, 2011 at 10:54 PM, Bian Naimeng <biannm@cn.fujitsu.com> wrote:
> There is not any directory at testcase/kernel/mem/ksm/,
> so replace generic_trunk_target.mk by generic_leaf_target.mk
>
> Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
>
> ---
> testcases/kernel/mem/ksm/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/testcases/kernel/mem/ksm/Makefile b/testcases/kernel/mem/ksm/Makefile
> index 81509bf..22190f1 100644
> --- a/testcases/kernel/mem/ksm/Makefile
> +++ b/testcases/kernel/mem/ksm/Makefile
> @@ -39,5 +39,5 @@ trunk-clean:: | lib-clean
> lib-clean:: $(LIBDIR)
> $(MAKE) -C $^ -f "$(abs_srcdir)/$^/Makefile" clean
>
> -include $(top_srcdir)/include/mk/generic_trunk_target.mk
> include $(top_srcdir)/include/mk/testcases.mk
> +include $(top_srcdir)/include/mk/generic_leaf_target.mk
Forgot about that Makefile that Cai submitted. How about this instead?
Thanks,
-Garrett
diff --git a/testcases/kernel/mem/ksm/Makefile
b/testcases/kernel/mem/ksm/Makefile
index 81509bf..fdff5fc 100644
--- a/testcases/kernel/mem/ksm/Makefile
+++ b/testcases/kernel/mem/ksm/Makefile
@@ -18,7 +18,7 @@
top_srcdir ?= ../../../..
-include $(top_srcdir)/include/mk/env_pre.mk
+include $(top_srcdir)/include/mk/testcases.mk
LDLIBS += $(NUMA_LIBS) -lmem
LIBDIR := ../lib
@@ -39,5 +39,4 @@ trunk-clean:: | lib-clean
lib-clean:: $(LIBDIR)
$(MAKE) -C $^ -f "$(abs_srcdir)/$^/Makefile" clean
-include $(top_srcdir)/include/mk/generic_trunk_target.mk
-include $(top_srcdir)/include/mk/testcases.mk
+include $(top_srcdir)/include/mk/generic_leaf_target.mk
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply related
* Why rpm install process is not working out of the pseudo context
From: Lu, Lianhao @ 2011-01-26 6:57 UTC (permalink / raw)
To: poky@yoctoproject.org
Hi guys,
Does anyone know why the RPM install process should be all executed in the pseudo context? Thank you!
I found that the rpm install process is not working when I manually enter the rpm command in the terminal (without pseudo).
The install process for rpm is:
1. generate db from solved db
${RPM} -D "_rpmds_sysinfo_path ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/etc/rpm/sysinfo" \
-D "_dbpath ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/install" -D "`cat ${RPMCONF_TARGET_BASE}.macro`" \
-D "__dbi_cdb create mp_mmapsize=128Mb mp_size=1Mb nofsync" \
-U --justdb --noscripts --notriggers --noparentdirs --nolinktos --ignoresize \
${SDK_OUTPUT}/${SDKTARGETSYSROOT}/install/install.manifest
2. pull out a list of what to install
${RPM} -D "_dbpath ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/install" -qa --yaml \
| grep -i 'Packageorigin' | cut -d : -f 2 > ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/install/install_solution.manifest
3. actual install
${RPM} --root ${SDK_OUTPUT}/${SDKTARGETSYSROOT} \
-D "_rpmds_sysinfo_path ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/etc/rpm/sysinfo" \
-D "_dbpath ${rpmlibdir}" \
--noscripts --notriggers --noparentdirs --nolinktos \
-D "__dbi_cdb create mp_mmapsize=128Mb mp_size=1Mb nofsync private" \
-Uhv ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/install/install_solution.manifest
If we put all the 3 steps under pseudo context, it works fine. But if all the 3 steps are out of pseudo context, the step 2) would fail complaining about:
rpmdb: configured environment flags incompatible with existing environment
error: cannot open Package(0) index using db3 - Invalid argument (22)
error: cannot open Package database in /home/lulianhao/poky-build/meta-toolchain/tmp/work/mips-poky-linux/meta-toolchain-sdk-1.0-r1/sdk/image//opt/poky/0.9+snapshot/sysroots/mips-poky-linux/install
If I add -D "__dbi_cdb create mp_mmapsize=128Mb mp_size=1Mb nofsync" options to step 2), it would succeed. But in step 3), nothing actually gets installed though the rpm doesn't report any error in step 3).
Best Regards,
-Lianhao Lu
^ permalink raw reply
* [LTP] [PATCH] Fix Makefile of testcase/kernel/mem/ksm/
From: Bian Naimeng @ 2011-01-26 6:54 UTC (permalink / raw)
To: Garrett Cooper; +Cc: ltp-list
There is not any directory at testcase/kernel/mem/ksm/,
so replace generic_trunk_target.mk by generic_leaf_target.mk
Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
---
testcases/kernel/mem/ksm/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/testcases/kernel/mem/ksm/Makefile b/testcases/kernel/mem/ksm/Makefile
index 81509bf..22190f1 100644
--- a/testcases/kernel/mem/ksm/Makefile
+++ b/testcases/kernel/mem/ksm/Makefile
@@ -39,5 +39,5 @@ trunk-clean:: | lib-clean
lib-clean:: $(LIBDIR)
$(MAKE) -C $^ -f "$(abs_srcdir)/$^/Makefile" clean
-include $(top_srcdir)/include/mk/generic_trunk_target.mk
include $(top_srcdir)/include/mk/testcases.mk
+include $(top_srcdir)/include/mk/generic_leaf_target.mk
--
1.7.0.4
--
Regards
Bian Naimeng
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply related
* Re: [GIT PULL 00/29] perf/core improvements for 2.6.39
From: Ingo Molnar @ 2011-01-26 6:52 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: linux-kernel, 2nddept-manager, Franck Bui-Huu,
Frederic Weisbecker, Han Pingtian, Masami Hiramatsu,
Mike Galbraith, Paul Mackerras, Peter Zijlstra, Srikar Dronamraju,
Stephane Eranian, Steven Rostedt, Tom Zanussi,
Arnaldo Carvalho de Melo
In-Reply-To: <1295976112-2796-1-git-send-email-acme@infradead.org>
* Arnaldo Carvalho de Melo <acme@infradead.org> wrote:
> Hi Ingo,
>
> Please consider pulling from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 perf/core
>
> The 'stat', 'record' and 'top' tools now share the event selector
> lifecycle routines, in the process 'top' switched to using just one mmap per
> CPU, using ioctl(PERF_EVENT_IOC_SET_OUTPUT) to set all events to just the first
> counter on a cpu, etc.
>
> I'm now working on a thin python binding for these abstractions, to
> ease prototyping monitoring apps.
>
> Regards,
>
> - Arnaldo
>
> Arnaldo Carvalho de Melo (20):
> perf evsel: Introduce perf_evlist
> perf evlist: Adopt the pollfd array
> perf evsel: Support event groups
> perf evsel: Allow specifying if the inherit bit should be set
> perf top: Use perf_evsel__open
> perf record: Use perf_evsel__open
> perf evsel: Introduce mmap support
> perf record: Use struct perf_mmap and helpers
> perf record: Move perf_mmap__write_tail to perf.h
> perf evlist: Move the mmap array from perf_evsel
> perf record: Use perf_evlist__mmap
> perf tools: Add missing cpu_map__delete()
> perf test: Check counts on all cpus in test__open_syscall_event_on_all_cpus
> perf evlist: Steal mmap reading routine from 'perf top'
> perf test: Add test for the evlist mmap routines
> perf top: Add native_safe_halt to skip symbols
> perf tools: Pass the struct opt to the wildcard parsing routine
> perf threads: Move thread_map to separate file
> perf tools: Move event__parse_sample to evsel.c
> perf evsel: Introduce perf_evsel__{in,ex}it
>
> Franck Bui-Huu (1):
> perf record: auto detect when stdout is a pipe
>
> Frederic Weisbecker (4):
> perf callchain: Feed callchains into a cursor
> perf callchain: Rename cumul_hits into callchain_cumul_hits
> perf callchain: Rename register_callchain_param into callchain_register_param
> perf callchain: Don't give arbitrary gender to callchain tree nodes
>
> Han Pingtian (1):
> perf test: check if cpu_map__new() return NULL
>
> Masami Hiramatsu (3):
> perf probe: Introduce lines walker interface
> perf probe: Enable to put probe inline function call site
> perf probe: Add --funcs to show available functions in symtab
>
> tools/perf/Documentation/perf-probe.txt | 4 +
> tools/perf/Makefile | 4 +
> tools/perf/builtin-probe.c | 29 +++-
> tools/perf/builtin-record.c | 328 ++++++++++++-----------------
> tools/perf/builtin-report.c | 29 ++--
> tools/perf/builtin-stat.c | 39 ++--
> tools/perf/builtin-test.c | 184 +++++++++++++++-
> tools/perf/builtin-top.c | 283 ++++++++-----------------
> tools/perf/perf.h | 26 +++
> tools/perf/util/callchain.c | 224 ++++++++++----------
> tools/perf/util/callchain.h | 74 ++++++-
> tools/perf/util/cpumap.c | 5 +
> tools/perf/util/cpumap.h | 2 +-
> tools/perf/util/event.c | 125 -----------
> tools/perf/util/event.h | 5 +-
> tools/perf/util/evlist.c | 170 +++++++++++++++
> tools/perf/util/evlist.h | 41 ++++
> tools/perf/util/evsel.c | 318 ++++++++++++++++++++++++++--
> tools/perf/util/evsel.h | 33 +++-
> tools/perf/util/header.c | 17 +-
> tools/perf/util/header.h | 7 +-
> tools/perf/util/hist.c | 15 +-
> tools/perf/util/hist.h | 2 +
> tools/perf/util/include/linux/list.h | 1 +
> tools/perf/util/parse-events.c | 71 ++-----
> tools/perf/util/parse-events.h | 7 -
> tools/perf/util/probe-event.c | 68 ++++++-
> tools/perf/util/probe-event.h | 1 +
> tools/perf/util/probe-finder.c | 361 ++++++++++++++++++-------------
> tools/perf/util/session.c | 26 ++-
> tools/perf/util/session.h | 20 ++-
> tools/perf/util/thread.c | 55 -----
> tools/perf/util/thread.h | 14 --
> tools/perf/util/thread_map.c | 64 ++++++
> tools/perf/util/thread_map.h | 15 ++
> tools/perf/util/ui/browsers/hists.c | 2 +-
> 36 files changed, 1647 insertions(+), 1022 deletions(-)
> create mode 100644 tools/perf/util/evlist.c
> create mode 100644 tools/perf/util/evlist.h
> create mode 100644 tools/perf/util/thread_map.c
> create mode 100644 tools/perf/util/thread_map.h
Pulled, thanks a lot Arnaldo!
Ingo
^ permalink raw reply
* Re: [PATCH v2 01/11] msm: Add CPU queries
From: David Brown @ 2011-01-26 6:52 UTC (permalink / raw)
To: Stepan Moskovchenko
Cc: Zhaohui Wang, 'Daniel Walker', linux-arm-msm,
linux-arm-kernel
In-Reply-To: <65e852891f18ed0cd764fba918bb842b.squirrel@www.codeaurora.org>
On Tue, Jan 25 2011, Stepan Moskovchenko wrote:
>> On Tue, Jan 25 2011, Zhaohui Wang wrote:
>>
>>> Maybe it's not appropriate to cut in your discussion.
>>
>> It's quite appropriate.
>>
>>> Can anyone explain what's the difference between qsd8X50 and msm8x60?
>>> No msm8x50, right?
>>
>> Well, they're just part numbers, and the numbering isn't all that
>> consistent over time:
>> http://www.qualcomm.com/products_services/chipsets/snapdragon.html
>>
>> The first snapdragon device was calls a QSD (8250 and 8660). They are
>
> David, I think you mean "8250 and 8650" here. QSD8250 and QSD8650 are
> identical as far as Linux is concerned, whereas MSM8660 is different,
> having two cores, etc.
Yes, thanks.
David
^ permalink raw reply
* [PATCH v2 01/11] msm: Add CPU queries
From: David Brown @ 2011-01-26 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65e852891f18ed0cd764fba918bb842b.squirrel@www.codeaurora.org>
On Tue, Jan 25 2011, Stepan Moskovchenko wrote:
>> On Tue, Jan 25 2011, Zhaohui Wang wrote:
>>
>>> Maybe it's not appropriate to cut in your discussion.
>>
>> It's quite appropriate.
>>
>>> Can anyone explain what's the difference between qsd8X50 and msm8x60?
>>> No msm8x50, right?
>>
>> Well, they're just part numbers, and the numbering isn't all that
>> consistent over time:
>> http://www.qualcomm.com/products_services/chipsets/snapdragon.html
>>
>> The first snapdragon device was calls a QSD (8250 and 8660). They are
>
> David, I think you mean "8250 and 8650" here. QSD8250 and QSD8650 are
> identical as far as Linux is concerned, whereas MSM8660 is different,
> having two cores, etc.
Yes, thanks.
David
^ permalink raw reply
* Re: [PATCH] langwell_gpio: Fix deprecated refs to irq_desc->chip and chip->eoi
From: David Miller @ 2011-01-26 6:50 UTC (permalink / raw)
To: alek.du; +Cc: buytenh, linux-kernel
In-Reply-To: <1865303E0DED764181A9D882DEF65FB685DF499ACF@shsmsx502.ccr.corp.intel.com>
From: "Du, Alek" <alek.du@intel.com>
Date: Wed, 26 Jan 2011 14:48:02 +0800
> Another patch from Feng Tang already covers this and picked up by Andrew Morton.
>
> [patch 04/23] langwell_gpio: modify EOI handling following change of kernel irq subsystem
Ok, thanks.
^ permalink raw reply
* [U-Boot] [PATCH V2 3/5] serial: add pantheon soc support
From: Prafulla Wadaskar @ 2011-01-26 6:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110125212520.88286B187@gemini.denx.de>
> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Tuesday, January 25, 2011 1:25 PM
> To: Prafulla Wadaskar
> Cc: u-boot at lists.denx.de; Lei Wen; Yu Tang; Ashish Karkare; Prabhanjan
> Sarnaik; adrian . wenl @ gmail . com "
> Subject: Re: [U-Boot] [PATCH V2 3/5] serial: add pantheon soc support
>
> Dear Prafulla,
>
> In message <1294632087-8025-4-git-send-email-leiwen@marvell.com> Lei Wen
> wrote:
> > Signed-off-by: Lei Wen <leiwen@marvell.com>
> > ---
> > drivers/serial/serial.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
> > index cd3439e..4032dfd 100644
> > --- a/drivers/serial/serial.c
> > +++ b/drivers/serial/serial.c
> > @@ -33,6 +33,8 @@
> > #include <asm/arch/orion5x.h>
> > #elif defined(CONFIG_ARMADA100)
> > #include <asm/arch/armada100.h>
> > +#elif defined(CONFIG_PANTHEON)
> > +#include <asm/arch/pantheon.h>
> > #endif
> >
> > #if defined (CONFIG_SERIAL_MULTI)
>
> Acked-by: Wolfgang Denk <wd@denx.de>
>
> Please pull with rest of patch series through your repository.
> Thanks.
Dear Wolfgang,
This is a patch series, need to be pulled all together. I will do it with v6, if there is no further review feedback for v6 patch series.
Regards..
Prafulla . .
^ permalink raw reply
* Re: [PATCH 01/18] move do_timer() from kernel/timer.c into kernel/time/timekeeping.c
From: Yong Zhang @ 2011-01-26 6:49 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Thomas Gleixner, john stultz, Torben Hohn, LKML, hch
In-Reply-To: <20110126055610.GA2593@windriver.com>
On Wed, Jan 26, 2011 at 1:56 PM, Yong Zhang <yong.zhang0@gmail.com> wrote:
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Subject: [PATCH] sched: Move the calc_global_load() call into the scheduler
>
> Remove the calc_global_load() call from the timekeeping code and make
> it local to the scheduler.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
> ---
> include/linux/sched.h | 2 --
> kernel/sched.c | 34 +++++++++++++++++++++++-----------
> kernel/timer.c | 1 -
> 3 files changed, 23 insertions(+), 14 deletions(-)
> +
> +static __init void start_calc_global_timer()
should be
static __init void start_calc_global_timer(void)
^ permalink raw reply
* RE: [PATCH] langwell_gpio: Fix deprecated refs to irq_desc->chip and chip->eoi
From: Du, Alek @ 2011-01-26 6:48 UTC (permalink / raw)
To: David Miller, buytenh@secretlab.ca; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20110125.222948.112596409.davem@davemloft.net>
Another patch from Feng Tang already covers this and picked up by Andrew Morton.
[patch 04/23] langwell_gpio: modify EOI handling following change of kernel irq subsystem
Thanks,
Alek
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Wednesday, January 26, 2011 2:30 PM
To: buytenh@secretlab.ca
Cc: Du, Alek; linux-kernel@vger.kernel.org
Subject: [PATCH] langwell_gpio: Fix deprecated refs to irq_desc->chip and chip->eoi
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/gpio/langwell_gpio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/langwell_gpio.c b/drivers/gpio/langwell_gpio.c
index d81cc74..a0d0c7b 100644
--- a/drivers/gpio/langwell_gpio.c
+++ b/drivers/gpio/langwell_gpio.c
@@ -206,7 +206,7 @@ static void lnw_irq_handler(unsigned irq, struct irq_desc *desc)
/* clear the edge detect status bit */
writel(gedr_v, gedr);
}
- desc->chip->eoi(irq);
+ desc->irq_data.chip->irq_eoi(&desc->irq_data);
}
static int __devinit lnw_gpio_probe(struct pci_dev *pdev,
--
1.7.3.4
^ permalink raw reply related
* Re: Is the grammar of .la files changed in new libtool 2.4?
From: Khem Raj @ 2011-01-26 6:43 UTC (permalink / raw)
To: Lu, Lianhao; +Cc: poky@yoctoproject.org
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F20A8339044@shsmsx502.ccr.corp.intel.com>
On (26/01/11 13:56), Lu, Lianhao wrote:
> Hi Scott,
>
> I'm wondering whether the grammar of the .la files generated by new libtool 2.4 is different from the old ones. Take the file libxcb-res.la generated by libxcb for example, it contains a line:
>
> dependency_libs=' =/usr/lib/libxcb.la =/usr/lib/libXau.la'
>
> While in the old libxcb.la file, this line appeared to be
>
> dependency_libs=' /usr/lib/libxcb.la /usr/lib/libxcb.la'
>
> Is the "=" a new grammar for liblool 2.4?
yes its new and it means that sysroot will be prepended to this when
resolving
Because in meta-toolchain, it needs to fix these .la files by replacing all the "/usr/lib" to "${SDKTARGETSYSROOT}/usr/lib", etc. This new "=" causes the original regular expression not work.
>
> b.t.w. Do we still need the code in meta-toolchain to fix broken .la files? According to my understanding, the new sysroot support in libtool 2.4 should solve this problem, right? Thanks!
>
> Best Regards,
> - Lianhao Lu
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
^ permalink raw reply
* Re: [PATCH 0/3] [GIT PULL][v2.6.38] tracing: fix unaligned event arrays
From: Ingo Molnar @ 2011-01-26 6:47 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, Andrew Morton, Frederic Weisbecker, David Miller,
Mathieu Desnoyers
In-Reply-To: <20110126040459.289776311@goodmis.org>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> Ingo,
>
> It was discovered that the alignment of the trace event sections
> break sparc64. The trace events are created by linker magic, so
> gcc does not realize that the structures being allocated will end
> up in an array. Without adding any alignment, x86_64 would create
> the trace event arrays with holes that would break reading the
> events in serial. The fix for that was to force a align(4) to
> keep gcc and the linker from spacing the event structures at various
> alignments. But recent changes have caused this change to break
> sparc due to bad alignment in the structures, caused by the 4 byte
> alignment.
>
> After some discussions, Mathieu came up with the following patch set
> to correctly fix the alignment issues with the trace event structures.
>
> Please pull the latest tip/perf/urgent tree, which can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> tip/perf/urgent
>
>
> Mathieu Desnoyers (3):
> Introduce __u64_aligned and U64_ALIGN() for structure alignment in custom sections
> tracing: Fix sparc64 alignment crash with __u64_aligned/U64_ALIGN()
> tracepoints: Use __u64_aligned/U64_ALIGN()
>
> ----
> include/asm-generic/vmlinux.lds.h | 27 +++++++++++-------
> include/linux/align-section.h | 54 +++++++++++++++++++++++++++++++++++++
> include/linux/compiler.h | 8 +++--
> include/linux/ftrace_event.h | 2 +-
> include/linux/syscalls.h | 12 ++++----
> include/linux/tracepoint.h | 12 +++-----
> include/trace/ftrace.h | 8 +++---
> include/trace/syscall.h | 2 +-
> kernel/trace/trace.h | 2 +-
> kernel/trace/trace_export.c | 2 +-
> 10 files changed, 94 insertions(+), 35 deletions(-)
Pulled, thanks a lot Steve!
Ingo
^ permalink raw reply
* Re: [PATCH] a patch to fix the cpu-offline-online problem caused by pm_idle
From: Luming Yu @ 2011-01-26 6:42 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: LKML, Len Brown, H. Peter Anvin
In-Reply-To: <1295946736.28776.479.camel@laptop>
[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]
On Tue, Jan 25, 2011 at 4:12 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2011-01-24 at 20:59 -0500, Luming Yu wrote:
>>
>> > Ow god this is ugly.. pm_idle should die asap, not find it way into generic code, so NAK!
>>
>> Without the ugly fix, we seem not able to fix the problem in short time.
>> Or , Are you suggesting to wrap pm_idle or similar in some generic
>> code that would not disappear in foreseeable future ,
>
> There are patches out there removing pm_idle from x86 (at least).
> pm_idle is a horribly broken interface that really should die.
>
>> Or Are you just
>> suggesting me don't do the stuff in kerne/cpu.c, and do it in Arch
>> code?
>
> Well, as it stand only about half the architectures out there even have
> a pm_idle pointer, so your patch would break the other half.
>
> If you really need to do this, do it in arch code, but really, why is
> this needed at all? The changelog failed to explain wth happens and why
> this solves it.
Ok, How about the new patch in the attachment?
We have seen an extremely slow system under the CPU-OFFLINE-ONLIE test
on a 4-sockets NHM-EX system.
The test case of off-line-on-line a cpu 1000 times and its performance
is dominated by IPI and ipi_handler performance. On NHM-EX, Sending
IPI not through broadcast is very slow. Needs to wake up processor by
IPI from deep-c-state also incurs heavy weight delay in set_mtrr
synchronization in stop_machinecontext. NHM-EX's c3-stop-APIC timer
adds more trouble to the problem. If I understand the problem
correctly, We probably need to tweak IPI code in upstream to get a
clean solution for NHM-EX's slow IPI delivery problem to get
reschedule tick processed without any delay on CPU which was in deep c state.
But it needs more time. So A quick fix is provided to make the test pass.
Without the patch the current CPU Office Online feature would not work
reliably, since it currently unnecessarily implicitly interact with
CPU power management.
--Luming
[-- Attachment #2: switch-idle-procedure.patch --]
[-- Type: application/octet-stream, Size: 1534 bytes --]
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 083e99d..832bbdc 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -83,6 +83,7 @@ DEFINE_PER_CPU(int, cpu_state) = { 0 };
* for idle threads.
*/
#ifdef CONFIG_HOTPLUG_CPU
+static struct notifier_block pm_idle_cpu_notifier;
/*
* Needed only for CONFIG_HOTPLUG_CPU because __cpuinitdata is
* removed after init for !CONFIG_HOTPLUG_CPU.
@@ -1162,6 +1163,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
uv_system_init();
set_mtrr_aps_delayed_init();
+ register_hotcpu_notifier(&pm_idle_cpu_notifier);
out:
preempt_enable();
}
@@ -1469,6 +1471,42 @@ void native_play_dead(void)
hlt_play_dead();
}
+static void (*pm_idle_saved)(void);
+
+static inline void save_pm_idle(void)
+{
+ pm_idle_saved = pm_idle;
+ pm_idle = default_idle;
+ cpu_idle_wait();
+}
+
+static inline void restore_pm_idle(void)
+{
+ pm_idle = pm_idle_saved;
+ cpu_idle_wait();
+}
+
+static int pm_idle_callback(struct notifier_block *nfb,
+ unsigned long action, void *hcpu)
+{
+ switch (action) {
+ case CPU_UP_PREPARE:
+ case CPU_DOWN_PREPARE:
+ save_pm_idle();
+ break;
+ case CPU_ONLINE:
+ case CPU_UP_CANCELED:
+ case CPU_DOWN_FAILED:
+ case CPU_DEAD:
+ restore_pm_idle();
+ break;
+ }
+ return NOTIFY_OK;
+}
+static struct notifier_block __refdata pm_idle_cpu_notifier = {
+ .notifier_call = pm_idle_callback,
+};
+
#else /* ... !CONFIG_HOTPLUG_CPU */
int native_cpu_disable(void)
{
^ permalink raw reply related
* Re: [PATCH v4] smc91x: add devicetree support
From: David Miller @ 2011-01-26 6:42 UTC (permalink / raw)
To: grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTindbigYzY0zJufpr-D25m_B5Gjqp09ZbcaN-aZ9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Date: Tue, 25 Jan 2011 22:52:36 -0700
> On Tue, Jan 25, 2011 at 10:22 PM, Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org> wrote:
>> Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
>> ---
>> v2 specify part numbers in compat as Grant suggested.
>> v3 more specific part name.
>> v4 include match table only for OF as David suggested.
>>
>> drivers/net/smc91x.c | 13 +++++++++++++
>> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> Looks okay to me.
>
> Reviewed-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH v4] smc91x: add devicetree support
From: David Miller @ 2011-01-26 6:42 UTC (permalink / raw)
To: grant.likely
Cc: thomas, linux-kernel, nios2-dev, devicetree-discuss, nico, netdev
In-Reply-To: <AANLkTindbigYzY0zJufpr-D25m_B5Gjqp09ZbcaN-aZ9@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Tue, 25 Jan 2011 22:52:36 -0700
> On Tue, Jan 25, 2011 at 10:22 PM, Thomas Chou <thomas@wytron.com.tw> wrote:
>> Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
>> ---
>> v2 specify part numbers in compat as Grant suggested.
>> v3 more specific part name.
>> v4 include match table only for OF as David suggested.
>>
>> drivers/net/smc91x.c | 13 +++++++++++++
>> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> Looks okay to me.
>
> Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: Is the grammar of .la files changed in new libtool 2.4?
From: Lu, Lianhao @ 2011-01-26 6:39 UTC (permalink / raw)
To: Garman, Scott A; +Cc: poky@yoctoproject.org
In-Reply-To: <4D3FBCB0.1030609@intel.com>
Garman, Scott A wrote on 2011-01-26:
> On 01/25/2011 09:56 PM, Lu, Lianhao wrote:
>> Hi Scott,
>>
>> I'm wondering whether the grammar of the .la files generated by new
>> libtool 2.4 is different from the old ones. Take the file
>> libxcb-res.la generated by libxcb for example, it contains a line:
>>
>> dependency_libs=' =/usr/lib/libxcb.la =/usr/lib/libXau.la'
>>
>> While in the old libxcb.la file, this line appeared to be
>>
>> dependency_libs=' /usr/lib/libxcb.la /usr/lib/libxcb.la'
>>
>> Is the "=" a new grammar for liblool 2.4? Because in meta-toolchain,
>> it needs to fix these .la files by replacing all the "/usr/lib" to
>> "${SDKTARGETSYSROOT}/usr/lib", etc. This new "=" causes the original
>> regular expression not work.
>
> Hi Lianhao,
>
> I'm not sure if the "=" grammar changed with Libtool 2.4 or not, as I
> haven't spent any time digging into Libtool when we used 2.2 a while ago.
>
> I do believe you will run into problems if you try to set
> dependency_libs to =/usr/lib. The reason is that you should not be
> adding system default directories to dependency_libs.
> =${SDKTARGETSYSROOT}/usr/lib should be fine.
>
> Where is the regular expression you're referring to above? Since Poky
> has been using Libtool 2.4 for a while now (I simply enabled sysroot
> support), I would think this error would have cropped up much earlier.
>
>> b.t.w. Do we still need the code in meta-toolchain to fix broken .la
>> files? According to my understanding, the new sysroot support in
>> libtool 2.4 should solve this problem, right? Thanks!
>
> Again, which code snippet are you referring to (file and line #,
> please)? There are some changes I made to remove .la munging code, and
> I'm pretty sure Richard reviewed it giving consideration to how it
> would impact the meta-toolchain builds.
The code snippet I mentioned about fixing broken .la files is in function do_populate_sdk() in file meta/recipies-core/meta/meta-toolchina.bb, you might search for "# Fix or remove broken .la files" to locate the code.
> Once I have the code sections to examine we should be able to iron
> this out more clearly.
>
I have one more question about how to use the new libtool (sysroot enabled libroot 2.4) in meta-toolchain. Is there anything missing in the following sequence(takes mips as example)? Thank you!
$libtoolize --automake
$aclocal -I <m4 dir containing m4 files from libtool 2.4>
$autoconf
$autoheader
$automake -a
$./configure --host=mips-poky-linux --target=mips-poky-linux --with-libtool-sysroot=<mips sysroot dir>
Best Regards,
Lianhao
^ permalink raw reply
* Re: fatal: protocol error: bad line length character: GET <<<<<
From: Alan Sargent @ 2011-01-26 6:40 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20110126055955.GA13304@LK-Perkele-VI.localdomain>
Ah! Thank you very much.
:)
On Wed, Jan 26, 2011 at 1:59 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Jan 26, 2011 at 12:53:11PM +0800, Alan Sargent wrote:
>> Hello,
>>
>> The "fatal: protocol error: bad line length character" seems fairly
>> common, but in the archive and the faq there isn't reference to this
>> particular instances - GET.
>>
>> alan@toaster:~$ git init myrepo
>> Initialized empty Git repository in /home/nev/myrepo/.git/
>> alan@toaster:~$ cd myrepo
>> alan@toaster:~/myrepo$ git daemon
>> fatal: protocol error: bad line length character: GET << just hitting
>> F5 in the browser
>> fatal: protocol error: bad line length character: GET
> [...]
>
> Git daemon serves git:// protocol, not HTTP, you can't access it from
> web browser.
>
> If you are looking for Git repository web interface, look at gitweb
> or cgit.
>
> The error is because HTTP begins the request with "GET " and git
> daemon is trying to interpret that as length of packet, failing
> and spitting out a fatal error.
>
> -Ilari
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.