* [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
So that access to cross trigger interface can be allowed, which
will be introduce in later patches.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 393afac..c7289a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5276,6 +5276,30 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+static struct omap_hwmod_class omap44xx_emu_hwmod_class = {
+ .name = "emu",
+};
+
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+ { .name = "cti0", .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = "cti1", .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+ .name = "emu",
+ .class = &omap44xx_emu_hwmod_class,
+ .clkdm_name = "emu_sys_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .mpu_irqs = omap44xx_emu_irqs,
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5422,6 +5446,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
+ /*emu class*/
+ &omap44xx_emu_hwmod,
NULL,
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 5/7] arm: omap4: create pmu device via hwmod
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
The following modules is required to be enabled before configuring
cross trigger interface for enabling pmu irq:
emu, l3_instr, l3_main_3
so build the arm-pmu device via the three hwmods.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 61 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0f8e0eb..6e16274 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -384,14 +384,67 @@ static struct platform_device omap_pmu_device = {
.num_resources = 1,
};
-static void omap_init_pmu(void)
+static struct arm_pmu_platdata omap4_pmu_data;
+static struct omap_device_pm_latency omap_pmu_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static struct platform_device* __init omap4_init_pmu(void)
{
- if (cpu_is_omap24xx())
+ int id = -1;
+ const char *hw;
+ struct platform_device *pd;
+ struct omap_hwmod* oh[3];
+ char *dev_name = "arm-pmu";
+
+ hw = "l3_main_3";
+ oh[0] = omap_hwmod_lookup(hw);
+ if (!oh[0]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+ hw = "l3_instr";
+ oh[1] = omap_hwmod_lookup(hw);
+ if (!oh[1]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+ hw = "emu";
+ oh[2] = omap_hwmod_lookup(hw);
+ if (!oh[2]) {
+ pr_err("Could not look up %s hwmod\n", hw);
+ return NULL;
+ }
+
+ pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
+ sizeof(omap4_pmu_data),
+ omap_pmu_latency,
+ ARRAY_SIZE(omap_pmu_latency), 0);
+ WARN(IS_ERR(pd), "Can't build omap_device for %s.\n",
+ dev_name);
+ return pd;
+}
+static void __init omap_init_pmu(void)
+{
+ if (cpu_is_omap24xx()) {
omap_pmu_device.resource = &omap2_pmu_resource;
- else if (cpu_is_omap34xx())
+ } else if (cpu_is_omap34xx()) {
omap_pmu_device.resource = &omap3_pmu_resource;
- else
+ } else if (cpu_is_omap44xx()) {
+ struct platform_device *pd;
+
+ pd = omap4_init_pmu();
+ if (!pd)
+ return;
+ omap_device_enable(pd);
+ return;
+ } else {
return;
+ }
platform_device_register(&omap_pmu_device);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v5 6/7] arm: omap4: support pmu
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei,
Woodruff Richard
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
about "Oprofile on Pandaboard / Omap4" on pandaboard@googlegroups.com.
Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Woodruff Richard <r-woodruff2@ti.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 60 +++++++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap44xx.h | 3 +
2 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 6e16274..bc791e0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -23,6 +23,7 @@
#include <asm/mach-types.h>
#include <asm/mach/map.h>
#include <asm/pmu.h>
+#include <asm/cti.h>
#include <plat/tc.h>
#include <plat/board.h>
@@ -393,6 +394,57 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
},
};
+static struct cti omap4_cti[2];
+
+static void omap4_enable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_enable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_enable(&omap4_cti[1]);
+}
+
+static void omap4_disable_cti(int irq)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_disable(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_disable(&omap4_cti[1]);
+}
+
+static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
+{
+ if (irq == OMAP44XX_IRQ_CTI0)
+ cti_irq_ack(&omap4_cti[0]);
+ else if (irq == OMAP44XX_IRQ_CTI1)
+ cti_irq_ack(&omap4_cti[1]);
+
+ return handler(irq, dev);
+}
+
+static void __init omap4_configure_pmu_irq(void)
+{
+ void __iomem *base0;
+ void __iomem *base1;
+
+ base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K);
+ base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K);
+ if (!base0 && !base1) {
+ pr_err("ioremap for OMAP4 CTI failed\n");
+ return;
+ }
+
+ /*configure CTI0 for pmu irq routing*/
+ cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
+ cti_unlock(&omap4_cti[0]);
+ cti_map_trigger(&omap4_cti[0], 1, 6, 2);
+
+ /*configure CTI1 for pmu irq routing*/
+ cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
+ cti_unlock(&omap4_cti[1]);
+ cti_map_trigger(&omap4_cti[1], 1, 6, 2);
+}
+
static struct platform_device* __init omap4_init_pmu(void)
{
int id = -1;
@@ -420,6 +472,10 @@ static struct platform_device* __init omap4_init_pmu(void)
return NULL;
}
+ omap4_pmu_data.handle_irq = omap4_pmu_handler;
+ omap4_pmu_data.enable_irq = omap4_enable_cti;
+ omap4_pmu_data.disable_irq = omap4_disable_cti;
+
pd = omap_device_build_ss(dev_name, id, oh, 3, &omap4_pmu_data,
sizeof(omap4_pmu_data),
omap_pmu_latency,
@@ -440,7 +496,9 @@ static void __init omap_init_pmu(void)
pd = omap4_init_pmu();
if (!pd)
return;
- omap_device_enable(pd);
+
+ omap_device_enable(&od->pdev);
+ omap4_configure_pmu_irq();
return;
} else {
return;
diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h
index ea2b8a6..4637980 100644
--- a/arch/arm/plat-omap/include/plat/omap44xx.h
+++ b/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -57,5 +57,8 @@
#define OMAP44XX_HSUSB_OHCI_BASE (L4_44XX_BASE + 0x64800)
#define OMAP44XX_HSUSB_EHCI_BASE (L4_44XX_BASE + 0x64C00)
+#define OMAP44XX_CTI0_BASE 0x54148000
+#define OMAP44XX_CTI1_BASE 0x54149000
+
#endif /* __ASM_ARCH_OMAP44XX_H */
--
1.7.5.4
^ permalink raw reply related
* Re: match a few ecn-ip-ect in one rule
From: Jan Engelhardt @ 2011-10-24 14:48 UTC (permalink / raw)
To: Sergey Naumov; +Cc: netfilter
In-Reply-To: <CAH3pVZPTgqtPeHRvjQdaq+2Ekm-ZKBaX1TCz7fVX+uAEHoFXAA@mail.gmail.com>
On Monday 2011-10-24 13:59, Sergey Naumov wrote:
>> Since rules are generally combined in ORed, it only makes sense for
>> matches to be ANDed (and submatch parts to be ORed at times).
>
>Yes, I understand, but because of logic of project that I develop it
>is better to use 1 rule than to search places where I have to add
>workarounds to generate 2 iptables rules from 1 user specified rule.
>When I use multiple -m molude inclusions, are specified parameters
>combined as OR, as AND or overrided?
Like I said, AND. Otherwise, packets would be able to match -m statistic
--mode random --probability 0 [-m something else].
^ permalink raw reply
* [PATCH v5 7/7] arm: omap4: pmu: support runtime pm
From: ming.lei @ 2011-10-24 14:45 UTC (permalink / raw)
To: linux, will.deacon, tony
Cc: linux-arm-kernel, linux-omap, khilman, paul, Ming Lei
In-Reply-To: <1319467559-5518-1-git-send-email-ming.lei@canonical.com>
From: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/mach-omap2/devices.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index bc791e0..ab4de0d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/pm_runtime.h>
#include <mach/hardware.h>
#include <mach/irqs.h>
@@ -395,9 +396,11 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
};
static struct cti omap4_cti[2];
+static struct platform_device *pmu_dev;
static void omap4_enable_cti(int irq)
{
+ pm_runtime_get_sync(&pmu_dev->dev);
if (irq == OMAP44XX_IRQ_CTI0)
cti_enable(&omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
@@ -410,6 +413,7 @@ static void omap4_disable_cti(int irq)
cti_disable(&omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
cti_disable(&omap4_cti[1]);
+ pm_runtime_put(&pmu_dev->dev);
}
static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler)
@@ -497,8 +501,11 @@ static void __init omap_init_pmu(void)
if (!pd)
return;
- omap_device_enable(&od->pdev);
+ pmu_dev= pd;
+ pm_runtime_enable(&pd->dev);
+ pm_runtime_get_sync(&pd->dev);
omap4_configure_pmu_irq();
+ pm_runtime_put(&pd->dev);
return;
} else {
return;
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 2/2] ARM: at91: add at91sam9g20 and Calao USB A9G20 DT support
From: Rob Herring @ 2011-10-24 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d139db89b4e9830e813abf1329ce1ac499653f2c.1319464310.git.nicolas.ferre@atmel.com>
On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
Looks good.
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* Re: [PATCH V3 2/2] ARM: at91: add at91sam9g20 and Calao USB A9G20 DT support
From: Rob Herring @ 2011-10-24 14:49 UTC (permalink / raw)
To: Nicolas Ferre
Cc: grant.likely, linux-kernel, linux-arm-kernel, devicetree-discuss,
plagnioj
In-Reply-To: <d139db89b4e9830e813abf1329ce1ac499653f2c.1319464310.git.nicolas.ferre@atmel.com>
On 10/24/2011 09:05 AM, Nicolas Ferre wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
Looks good.
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* Re: [PATCH] TTY: pty, fix pty counting
From: Ilya Zykov @ 2011-10-24 14:50 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg Kroah-Hartman, Alan Cox, linux-kernel, ilya
In-Reply-To: <4EA563E6.3040205@suse.cz>
Jiri Slaby wrote:
> On 10/23/2011 11:01 PM, Ilya Zykov wrote:
>> New version for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
>
> Although it will work, as ptms are not allowed to be reopen, it doesn't
> look correct. We should decrement the count in ->remove, because we are
> incrementing in install.
>
> Now, when I understand ptm+devpts layer a bit more, instead of the
> current hackish approach introduced by 24d406a6b (TTY: pty, fix pty
> counting), I think we may introduce a ->remove hook specific to ptms. In
> that one we could decrement the count and don't bother with the
> pty_count macros anymore. Right?
>
> BTW you cannot remove ->remove hook of pty layer. It would cause an OOPS
> because driver->ttys is not allocated for ptys.
>
>> diff -uprN a/drivers/tty/pty.c b/drivers/tty/pty.c
>> --- a/drivers/tty/pty.c 2011-05-19 08:06:34.000000000 +0400
>> +++ b/drivers/tty/pty.c 2011-10-23 18:01:20.000000000 +0400
>> @@ -36,13 +36,15 @@
>> static struct tty_driver *ptm_driver;
>> static struct tty_driver *pts_driver;
>> #endif
>> +static int pty_count;
>>
>> static void pty_close(struct tty_struct *tty, struct file *filp)
>> {
>> BUG_ON(!tty);
>> - if (tty->driver->subtype == PTY_TYPE_MASTER)
>> + if (tty->driver->subtype == PTY_TYPE_MASTER) {
>> WARN_ON(tty->count > 1);
>> - else {
>> + pty_count--;
>> + } else {
>> if (tty->count > 2)
>> return;
>> }
>> @@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
>> int pty_limit = NR_UNIX98_PTY_DEFAULT;
>> static int pty_limit_min;
>> static int pty_limit_max = NR_UNIX98_PTY_MAX;
>> -static int pty_count;
>>
>> static struct cdev ptmx_cdev;
>>
>> @@ -599,15 +600,9 @@ free_mem_out:
>> return -ENOMEM;
>> }
>>
>> -static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty)
>> -{
>> - pty_count--;
>> -}
>> -
>> static const struct tty_operations ptm_unix98_ops = {
>> .lookup = ptm_unix98_lookup,
>> .install = pty_unix98_install,
>> - .remove = pty_unix98_remove,
>> .open = pty_open,
>> .close = pty_close,
>> .write = pty_write,
>> @@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
>> static const struct tty_operations pty_unix98_ops = {
>> .lookup = pts_unix98_lookup,
>> .install = pty_unix98_install,
>> - .remove = pty_unix98_remove,
>> .open = pty_open,
>> .close = pty_close,
>> .write = pty_write,
>
> thanks,
Invoke tty_driver_remove_tty() from driver,
not good idea IMHO.
^ permalink raw reply
* Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
From: Thomas Hellstrom @ 2011-10-24 14:48 UTC (permalink / raw)
To: Marek Olšák; +Cc: dri-devel
In-Reply-To: <CAAxE2A6uJzg0Uvvehzd2YVYZtAAE-hBBik2G77QAEfZ9bU5wJg@mail.gmail.com>
On 10/08/2011 12:03 AM, Marek Olšák wrote:
> On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom<thomas@shipmail.org> wrote:
>
>> OK. First I think we need to make a distinction: bo sync objects vs driver
>> fences. The bo sync obj api is there to strictly provide functionality that
>> the ttm bo subsystem is using, and that follows a simple set of rules:
>>
>> 1) the bo subsystem does never assume sync objects are ordered. That means
>> the bo subsystem needs to wait on a sync object before removing it from a
>> buffer. Any other assumption is buggy and must be fixed. BUT, if that
>> assumption takes place in the driver unknowingly from the ttm bo subsystem
>> (which is usually the case), it's OK.
>>
>> 2) When the sync object(s) attached to the bo are signaled the ttm bo
>> subsystem is free to copy the bo contents and to unbind the bo.
>>
>> 3) The ttm bo system allows sync objects to be signaled in different ways
>> opaque to the subsystem using sync_obj_arg. The driver is responsible for
>> setting up that argument.
>>
>> 4) Driver fences may be used for or expose other functionality or adaptions
>> to APIs as long as the sync obj api exported to the bo sybsystem follows the
>> above rules.
>>
>> This means the following w r t the patch.
>>
>> A) it violates 1). This is a bug that must be fixed. Assumptions that if one
>> sync object is singnaled, another sync object is also signaled must be done
>> in the driver and not in the bo subsystem. Hence we need to explicitly wait
>> for a fence to remove it from the bo.
>>
>> B) the sync_obj_arg carries *per-sync-obj* information on how it should be
>> signaled. If we need to attach multiple sync objects to a buffer object, we
>> also need multiple sync_obj_args. This is a bug and needs to be fixed.
>>
>> C) There is really only one reason that the ttm bo subsystem should care
>> about multiple sync objects, and that is because the driver can't order them
>> efficiently. A such example would be hardware with multiple pipes reading
>> simultaneously from the same texture buffer. Currently we don't support this
>> so only the *last* sync object needs to be know by the bo subsystem. Keeping
>> track of multiple fences generates a lot of completely unnecessary code in
>> the ttm_bo_util file, the ttm_bo_vm file, and will be a nightmare if / when
>> we truly support pipelined moves.
>>
>> As I understand it from your patches, you want to keep multiple fences
>> around only to track rendering history. If we want to do that generically, i
>> suggest doing it in the execbuf util code in the following way:
>>
>> struct ttm_eu_rendering_history {
>> void *last_read_sync_obj;
>> void *last_read_sync_obj_arg;
>> void *last_write_sync_obj;
>> void *last_write_sync_obj_arg;
>> }
>>
>> Embed this structure in the radeon_bo, and build a small api around it,
>> including *optionally* passing it to the existing execbuf utilities, and you
>> should be done. The bo_util code and bo_vm code doesn't care about the
>> rendering history. Only that the bo is completely idle.
>>
>> Note also that when an accelerated bo move is scheduled, the driver needs to
>> update this struct
>>
> OK, sounds good. I'll fix what should be fixed and send a patch when
> it's ready. I am now not so sure whether doing this generically is a
> good idea. :)
>
> Marek
>
Marek,
Any progress on this. The merge window is about to open soon I guess and
we need a fix by then.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: NFS4 BAD_STATEID loop (kernel 3.0.4)
From: David Flynn @ 2011-10-24 14:50 UTC (permalink / raw)
To: Trond Myklebust; +Cc: David Flynn, linux-nfs, Chuck Lever
In-Reply-To: <1319463165.2734.1.camel@lade.trondhjem.org>
* Chuck Lever (chuck.lever@oracle.com) wrote:
> Can you tell us a little more about the server? Which release of
> Solaris? What hardware?
SunOS 5.10 Generic_141444-09
(sparc)
* Trond Myklebust (Trond.Myklebust@netapp.com) wrote:
> I'm assuming then that your network trace showed no sign of any OPEN
> calls of that particular file, just retries of the WRITE?
Correct.
However, the good news is that it has just happened again (certainly
not quota related)
The blocked task:
[179068.773206] INFO: task bash:3293 blocked for more than 120 seconds.
[179068.779660] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[179068.787701] bash D 0000000000000004 0 3293 1 0x00000000
[179068.795173] ffff88001f97fca8 0000000000000086 ffff880426876008 0000000000012a40
[179068.802992] ffff88001f97ffd8 0000000000012a40 ffff88001f97e000 0000000000012a40
[179068.810745] 0000000000012a40 0000000000012a40 ffff88001f97ffd8 0000000000012a40
[179068.818810] Call Trace:
[179068.821496] [<ffffffff81110030>] ? __lock_page+0x70/0x70
[179068.827204] [<ffffffff8160007c>] io_schedule+0x8c/0xd0
[179068.832952] [<ffffffff8111003e>] sleep_on_page+0xe/0x20
[179068.838823] [<ffffffff816008ff>] __wait_on_bit+0x5f/0x90
[179068.844734] [<ffffffff81110203>] wait_on_page_bit+0x73/0x80
[179068.850798] [<ffffffff81085bf0>] ? autoremove_wake_function+0x40/0x40
[179068.857879] [<ffffffff8111c5e5>] ? pagevec_lookup_tag+0x25/0x40
[179068.864173] [<ffffffff81110436>] filemap_fdatawait_range+0xf6/0x1a0
[179068.870721] [<ffffffffa02167d0>] ? nfs_destroy_directcache+0x20/0x20 [nfs]
[179068.877963] [<ffffffff8111bae1>] ? do_writepages+0x21/0x40
[179068.883744] [<ffffffff811116bb>] ? __filemap_fdatawrite_range+0x5b/0x60
[179068.890867] [<ffffffff81111730>] filemap_write_and_wait_range+0x70/0x80
[179068.898025] [<ffffffff8119cc6a>] vfs_fsync_range+0x5a/0x90
[179068.904197] [<ffffffff8119cd0c>] vfs_fsync+0x1c/0x20
[179068.909721] [<ffffffffa020ac74>] nfs_file_flush+0x54/0x80 [nfs]
[179068.916069] [<ffffffff8116ee7f>] filp_close+0x3f/0x90
[179068.921611] [<ffffffff8116f8a7>] sys_close+0xb7/0x120
[179068.927328] [<ffffffff8160a702>] system_call_fastpath+0x16/0x1b
$ echo 0 >/proc/sys/sunrpc/rpc_debug
[180179.009328] -pid- flgs status -client- --rqstp- -timeout ---ops--
[180179.015540] 40304 0801 0 ffff8804241ae800 (null) 0 ffffffffa023cd40 nfsv4 WRITE a:call_start q:NFS client
and our pingpong (more details at end):
14:07:07.307191 IP vc-fs1.rd.bbc.co.uk.1837702678 > home.rd.bbc.co.uk.nfs: 300 getattr fh 0,0/22
14:07:07.307471 IP home.rd.bbc.co.uk.nfs > vc-fs1.rd.bbc.co.uk.1837702678: reply ok 52 getattr ERROR: unk 10025
This system is up at the moment, if there is further detail you require
i can provide that.
NB, the system this occurred on is running kernel 3.0.4
Mount options as per earlier.
Kind regards,
..david
No. Time Source Destination Protocol Size Info
39 15:33:59.077143 172.29.190.28 172.29.120.140 NFS 370 V4 COMPOUND Call (Reply In 40) <EMPTY> PUTFH;WRITE;GETATTR
Frame 39: 370 bytes on wire (2960 bits), 370 bytes captured (2960 bits)
Ethernet II, Src: ChelsioC_07:49:6f (00:07:43:07:49:6f), Dst: All-HSRP-routers_be (00:00:0c:07:ac:be)
Internet Protocol, Src: 172.29.190.28 (172.29.190.28), Dst: 172.29.120.140 (172.29.120.140)
Transmission Control Protocol, Src Port: omginitialrefs (900), Dst Port: nfs (2049), Seq: 40433, Ack: 7449, Len: 304
Remote Procedure Call, Type:Call XID:0x43ce4e16
Network File System
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Tag: <EMPTY>
length: 0
contents: <EMPTY>
minorversion: 0
Operations (count: 3)
Opcode: PUTFH (22)
filehandle
length: 36
[hash (CRC-32): 0x6e4b15f3]
decode type as: unknown
filehandle: 7df3a75d5e1cd908000ab44c5b000000efc80200000a0300...
Opcode: WRITE (38)
stateid
offset: 11474
stable: FILE_SYNC4 (2)
Write length: 68
Data: <DATA>
length: 68
contents: <DATA>
Opcode: GETATTR (9)
GETATTR4args
attr_request
bitmap[0] = 0x00000018
[2 attributes requested]
mand_attr: FATTR4_CHANGE (3)
mand_attr: FATTR4_SIZE (4)
bitmap[1] = 0x00300000
[2 attributes requested]
recc_attr: FATTR4_TIME_METADATA (52)
recc_attr: FATTR4_TIME_MODIFY (53)
No. Time Source Destination Protocol Size Info
40 15:33:59.077433 172.29.120.140 172.29.190.28 NFS 122 V4 COMPOUND Reply (Call In 39) <EMPTY> PUTFH;WRITE
Frame 40: 122 bytes on wire (976 bits), 122 bytes captured (976 bits)
Ethernet II, Src: Cisco_1e:f7:80 (00:13:5f:1e:f7:80), Dst: ChelsioC_07:49:6f (00:07:43:07:49:6f)
Internet Protocol, Src: 172.29.120.140 (172.29.120.140), Dst: 172.29.190.28 (172.29.190.28)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: omginitialrefs (900), Seq: 7449, Ack: 40737, Len: 56
Remote Procedure Call, Type:Reply XID:0x43ce4e16
Network File System
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Status: NFS4ERR_BAD_STATEID (10025)
Tag: <EMPTY>
length: 0
contents: <EMPTY>
Operations (count: 2)
Opcode: PUTFH (22)
Status: NFS4_OK (0)
Opcode: WRITE (38)
Status: NFS4ERR_BAD_STATEID (10025)
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:51 UTC (permalink / raw)
To: Grant Likely
Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024135950.GV8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > >
> > > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > > when calling regulator_register(regulator_desc, dev, ...) from
> > > > regulator driver, the regulator core will be able to find all nodes under
> > > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> > >
> > > Please provide concrete examples of the bindings you're talking about,
> > > the really important thing here is how sane the bindings look and I've
> > > really got no idea what any of what you're talking about will look like
> > > or if they make sense.
> > >
> > The only thing different from what I attached last time is the
> > compatible string added to 'regulators' node.
> >
> > ecspi@70010000 { /* ECSPI1 */
> > fsl,spi-num-chipselects = <2>;
> > cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> > <&gpio3 25 0>; /* GPIO4_25 */
> > status = "okay";
> >
> > pmic: mc13892@0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,mc13892";
> > spi-max-frequency = <6000000>;
> > reg = <0>;
> > mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
> >
> > regulators {
> > compatible = "fsl,mc13892-regulator";
> >
> > sw1reg: mc13892_sw1 {
> > regulator-min-uV = <600000>;
> > regulator-max-uV = <1375000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > sw2reg: mc13892_sw2 {
> > regulator-min-uV = <900000>;
> > regulator-max-uV = <1850000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > ......
> > };
> >
> > leds {
> > ......
> > };
> >
> > buttons {
> > ......
> > };
> > };
> >
> > flash: at45db321d@1 {
> > ......
> > };
> > };
> >
> > > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > > "fsl,mc13892-regulators").
> > >
> > > It's not immediately obvious to me that having a binding for the
> > > regulators separately makes sense, it's not a usefully distinct device.
> > >
> > Fair point. Actually, I also hate to have the finding of node
> > 'regulators' plugged into regulator driver. What about following
> > change to address Grant's concern on global device tree search?
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 8fe132d..29dcf90 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
>
> of_find_node_by_name() doesn't work that way. The first argument is a
> starting point, but it doesn't restrict the search to children of a
> node.
>
> for_each_child_of_node() is what you want to use when iterating over
> the children which unfortunately changes the structure of this
> function.
>
The dev->parent->of_node is meant to point to node 'pmic: mc13892@0'.
And the intention here is not to iterate over the children, but to
start a search from a reasonable point rather than the top root node.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024135950.GV8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > >
> > > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > > when calling regulator_register(regulator_desc, dev, ...) from
> > > > regulator driver, the regulator core will be able to find all nodes under
> > > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> > >
> > > Please provide concrete examples of the bindings you're talking about,
> > > the really important thing here is how sane the bindings look and I've
> > > really got no idea what any of what you're talking about will look like
> > > or if they make sense.
> > >
> > The only thing different from what I attached last time is the
> > compatible string added to 'regulators' node.
> >
> > ecspi at 70010000 { /* ECSPI1 */
> > fsl,spi-num-chipselects = <2>;
> > cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> > <&gpio3 25 0>; /* GPIO4_25 */
> > status = "okay";
> >
> > pmic: mc13892 at 0 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > compatible = "fsl,mc13892";
> > spi-max-frequency = <6000000>;
> > reg = <0>;
> > mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
> >
> > regulators {
> > compatible = "fsl,mc13892-regulator";
> >
> > sw1reg: mc13892_sw1 {
> > regulator-min-uV = <600000>;
> > regulator-max-uV = <1375000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > sw2reg: mc13892_sw2 {
> > regulator-min-uV = <900000>;
> > regulator-max-uV = <1850000>;
> > regulator-change-voltage;
> > regulator-boot-on;
> > regulator-always-on;
> > };
> >
> > ......
> > };
> >
> > leds {
> > ......
> > };
> >
> > buttons {
> > ......
> > };
> > };
> >
> > flash: at45db321d at 1 {
> > ......
> > };
> > };
> >
> > > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > > "fsl,mc13892-regulators").
> > >
> > > It's not immediately obvious to me that having a binding for the
> > > regulators separately makes sense, it's not a usefully distinct device.
> > >
> > Fair point. Actually, I also hate to have the finding of node
> > 'regulators' plugged into regulator driver. What about following
> > change to address Grant's concern on global device tree search?
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 8fe132d..29dcf90 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
>
> of_find_node_by_name() doesn't work that way. The first argument is a
> starting point, but it doesn't restrict the search to children of a
> node.
>
> for_each_child_of_node() is what you want to use when iterating over
> the children which unfortunately changes the structure of this
> function.
>
The dev->parent->of_node is meant to point to node 'pmic: mc13892 at 0'.
And the intention here is not to iterate over the children, but to
start a search from a reasonable point rather than the top root node.
--
Regards,
Shawn
^ permalink raw reply
* [refpolicy] Error when using refpolicy with apache httpd service
From: Justin Mattock @ 2011-10-24 14:53 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <1319430331.81049.YahooMailNeo@web114307.mail.gq1.yahoo.com>
----- Original Message -----
From: Justin Mattock <justinmattock@yahoo.com>
To: Guido Trentalancia <guido@trentalancia.com>; Dominick Grift <dominick.grift@gmail.com>
Cc: refpolicy <refpolicy@oss.tresys.com>
Sent: Sunday, October 23, 2011 9:25 PM
Subject: Re: [refpolicy] Error when using refpolicy with apache httpd service
----- Original Message -----
From: Guido Trentalancia <guido@trentalancia.com>
To: Dominick Grift <dominick.grift@gmail.com>
Cc: refpolicy <refpolicy@oss.tresys.com>
Sent: Wednesday, October 12, 2011 8:39 AM
Subject: Re: [refpolicy] Error when using refpolicy with apache httpd service
On Wed, 2011-10-12 at 17:15 +0200, Dominick Grift wrote:
> On Thu, 2011-10-13 at 00:08 +0900, Thu?n ?inh wrote:
> > Hi,
> >
> >
> > I'm very strange that the /sbin/init is labeled bin_t
> >
> >
> > The /sbin/init is point to /bin/systemd
> >
> >
> > I check in the /system/init.fc have defiled:
> >
> >
> > /sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
> > # because nowadays, /sbin/init is often a symlink to /sbin/upstart
> > /sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > So, I changed it to:
> >
> >
> > /bin/systemd? ?? -- gen_context(system_u:object_r:init_exec_t,s0)
> > /sbin/init? ? ? ? --
> >? gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > And then, I make, install, load and relabel it again.
> >
> >
> > But after that, the /sbin/init still have labeled bin_t (instead of
> > the /bin/systemd is now have init_exec_t)
> >
> >
> > I'm very strange. So, I try to relabel it by command:
> >
> >
> > chcon -t init_exec_t /sbin/init
>
> The /sbin/init symbolic link can be bin_t, no problem.
>
> /sbin/systemd though should be type init_exec_t.
>
> The problem is that reference policy currently does not support systemd.
>
> systemd is not stable yet.
>
> refpolicy is waiting until systemd is stable before she will support it,
> because there are too many changes happening to systemd currently.
>
> You could probably, atleast to some extend, work around the issues by
> making init a unconfined domain, but that will probably cause issues as
> well. So if you are not comfortable with selinux you may want to avoid
> that.
>
> ?nstead use the policy provided/supported by your distribution instead.
Consider Justin Mattock has recently submitted an initial patch (derived
from F15, I suppose) for better supporting systemd in the reference
policy:
18th September 2011
[RFC 1/2]selinux-contrib: add systemd support to refpolicy git
[RFC 2/2] refpolicy: add systemd support to tresys main policy
It's probably worth trying that out (along with the init_systemd
boolean), if it's using systemd...
Regards,
Guido
yeah, anybody have the time to go through that patch set feel free..
last I remember I was hitting some sandbox error for some reason, then ran out of?
time due to external obligations. maybe if the weekend is permitting I can have another go at
it.. as for the patch I pretty much just grepped dans git tree for systemd then copied it to refpolicy,
but there is probably more to it than just grepping.
Justin P. Mattock?
doing a google search I am only able to find find the first revision sent for this on the 18th of september.
seems my second revision did not make it through to the list. anyway here is my backup of the two patches..:
http://fpaste.org/FLfg/
http://fpaste.org/5r5t/
I will try and plug this in again over the weekend to see if I can get it running. ?
cheers,
Justin P. Mattock
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
^ permalink raw reply
* [Buildroot] [PATCH 1/2] kernel-headers: bump to version 3.0.7 and add version 3.1
From: Gustavo Zacarias @ 2011-10-24 14:54 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
| 8 ++++++--
| 2 +-
...all-fix-__packed-in-exported-kernel-head.patch} | 0
3 files changed, 7 insertions(+), 3 deletions(-)
rename toolchain/kernel-headers/{linux-3.0.4-headers_install-fix-__packed-in-exported-kernel-head.patch => linux-3.0.7-headers_install-fix-__packed-in-exported-kernel-head.patch} (100%)
--git a/toolchain/kernel-headers/Config.in b/toolchain/kernel-headers/Config.in
index b827ec5..8be9186 100644
--- a/toolchain/kernel-headers/Config.in
+++ b/toolchain/kernel-headers/Config.in
@@ -6,7 +6,7 @@ comment "Kernel Header Options"
choice
prompt "Kernel Headers"
- default BR2_KERNEL_HEADERS_3_0
+ default BR2_KERNEL_HEADERS_3_1
help
Select the version of kernel header files you wish to use.
You must select the correct set of header files to match
@@ -33,6 +33,9 @@ choice
config BR2_KERNEL_HEADERS_3_0
bool "Linux 3.0.x kernel headers"
+ config BR2_KERNEL_HEADERS_3_1
+ bool "Linux 3.1.x kernel headers"
+
config BR2_KERNEL_HEADERS_VERSION
bool "Linux 2.6 (manually specified version)"
@@ -54,6 +57,7 @@ config BR2_DEFAULT_KERNEL_HEADERS
default "2.6.37.6" if BR2_KERNEL_HEADERS_2_6_37
default "2.6.38.8" if BR2_KERNEL_HEADERS_2_6_38
default "2.6.39.4" if BR2_KERNEL_HEADERS_2_6_39
- default "3.0.4" if BR2_KERNEL_HEADERS_3_0
+ default "3.0.7" if BR2_KERNEL_HEADERS_3_0
+ default "3.1" if BR2_KERNEL_HEADERS_3_1
default "2.6" if BR2_KERNEL_HEADERS_SNAP
default $BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
--git a/toolchain/kernel-headers/kernel-headers.mk b/toolchain/kernel-headers/kernel-headers.mk
index 044fcf9..72c6007 100644
--- a/toolchain/kernel-headers/kernel-headers.mk
+++ b/toolchain/kernel-headers/kernel-headers.mk
@@ -29,7 +29,7 @@ LINUX_HEADERS_VERSION:=$(VERSION).$(PATCHLEVEL)$(SUBLEVEL)$(EXTRAVERSION)
ifeq ($(findstring x2.6.,x$(DEFAULT_KERNEL_HEADERS)),x2.6.)
LINUX_HEADERS_SITE:=$(BR2_KERNEL_MIRROR)/linux/kernel/v2.6/
else
-LINUX_HEADERS_SITE:=$(BR2_KERNEL_MIRROR)/linux/kernel/v3.0/
+LINUX_HEADERS_SITE:=$(BR2_KERNEL_MIRROR)/linux/kernel/v3.x/
endif
LINUX_HEADERS_SOURCE:=linux-$(LINUX_HEADERS_VERSION).tar.bz2
LINUX_HEADERS_CAT:=$(BZCAT)
diff --git a/toolchain/kernel-headers/linux-3.0.4-headers_install-fix-__packed-in-exported-kernel-head.patch b/toolchain/kernel-headers/linux-3.0.7-headers_install-fix-__packed-in-exported-kernel-head.patch
similarity index 100%
rename from toolchain/kernel-headers/linux-3.0.4-headers_install-fix-__packed-in-exported-kernel-head.patch
rename to toolchain/kernel-headers/linux-3.0.7-headers_install-fix-__packed-in-exported-kernel-head.patch
--
1.7.3.4
^ permalink raw reply related
* [Buildroot] [PATCH 2/2] linux: bump default kernel to version 3.1
From: Gustavo Zacarias @ 2011-10-24 14:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1319468043-22999-1-git-send-email-gustavo@zacarias.com.ar>
Bump default kernel vesion to 3.1 to match headers.
Also implement downloads for 3.x series kernels.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
linux/Config.in | 10 +++++-----
linux/linux.mk | 8 +++++---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/linux/Config.in b/linux/Config.in
index 5655286..774aaf8 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -19,10 +19,10 @@ if BR2_LINUX_KERNEL
#
choice
prompt "Kernel version"
- default BR2_LINUX_KERNEL_2_6_39
+ default BR2_LINUX_KERNEL_3_1
-config BR2_LINUX_KERNEL_2_6_39
- bool "2.6.39.4"
+config BR2_LINUX_KERNEL_3_1
+ bool "3.1"
config BR2_LINUX_KERNEL_SAME_AS_HEADERS
bool "Same as toolchain kernel headers"
@@ -58,7 +58,7 @@ endchoice
config BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE
string "Kernel version"
depends on BR2_LINUX_KERNEL_CUSTOM_VERSION
- default "2.6.39.4"
+ default "3.1"
config BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION
string "URL of custom kernel tarball"
@@ -74,7 +74,7 @@ config BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION
config BR2_LINUX_KERNEL_VERSION
string
- default "2.6.39.4" if BR2_LINUX_KERNEL_2_6_39
+ default "3.1" if BR2_LINUX_KERNEL_3_1
default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE if BR2_LINUX_KERNEL_CUSTOM_VERSION
default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
diff --git a/linux/linux.mk b/linux/linux.mk
index 99f4649..6b6fd5c 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -18,9 +18,11 @@ LINUX_SOURCE = linux-$(LINUX_VERSION).tar.bz2
# In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order
# to use the $(word) function. We support versions such as 3.1,
# 2.6.32, 2.6.32-rc1, 3.0-rc6, etc.
-LINUX_VERSION_MAJOR = $(word 1,$(subst ., ,$(subst -, ,$(LINUX_VERSION))))
-LINUX_VERSION_MINOR = $(word 2,$(subst ., ,$(subst -, ,$(LINUX_VERSION))))
-LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v$(LINUX_VERSION_MAJOR).$(LINUX_VERSION_MINOR)/
+ifeq ($(findstring x2.6.,x$(LINUX_VERSION)),x2.6.)
+LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v2.6/
+else
+LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v3.x/
+endif
# release candidates are in testing/ subdir
ifneq ($(findstring -rc,$(LINUX_VERSION)),)
LINUX_SITE := $(LINUX_SITE)testing/
--
1.7.3.4
^ permalink raw reply related
* kdump: crash_kexec()-smp_send_stop() race in panic
From: Michael Holzheu @ 2011-10-24 14:55 UTC (permalink / raw)
To: Vivek Goyal
Cc: ebiederm, akpm, schwidefsky, heiko.carstens, kexec, linux-kernel
Hello Vivek,
In our tests we ran into the following scenario:
Two CPUs have called panic at the same time. The first CPU called
crash_kexec() and the second CPU called smp_send_stop() in panic()
before crash_kexec() finished on the first CPU. So the second CPU
stopped the first CPU and therefore kdump failed.
1st CPU:
panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
2nd CPU:
panic()->crash_kexec()->kexec_mutex already held by 1st CPU
->smp_send_stop()-> stop CPU 1 (stop kdump)
How should we fix this problem? One possibility could be to do
smp_send_stop() before we call crash_kexec().
What do you think?
Michael
^ permalink raw reply
* kdump: crash_kexec()-smp_send_stop() race in panic
From: Michael Holzheu @ 2011-10-24 14:55 UTC (permalink / raw)
To: Vivek Goyal
Cc: heiko.carstens, kexec, linux-kernel, ebiederm, schwidefsky, akpm
Hello Vivek,
In our tests we ran into the following scenario:
Two CPUs have called panic at the same time. The first CPU called
crash_kexec() and the second CPU called smp_send_stop() in panic()
before crash_kexec() finished on the first CPU. So the second CPU
stopped the first CPU and therefore kdump failed.
1st CPU:
panic()->crash_kexec()->mutex_trylock(&kexec_mutex)-> do kdump
2nd CPU:
panic()->crash_kexec()->kexec_mutex already held by 1st CPU
->smp_send_stop()-> stop CPU 1 (stop kdump)
How should we fix this problem? One possibility could be to do
smp_send_stop() before we call crash_kexec().
What do you think?
Michael
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH 0/2] mmc: mmci: Improvements for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel; +Cc: Russell King, Ulf Hansson, Lee Jones
For the ux500v2 variant of the PL18x block, non power of two block
sizes are now supported.
In addition constraints on buffer alignments is needed since access to the
PL18x FIFO must be done on a 4-byte aligned manner. Moreover to be able to
use DMA for buffers with not 32 bytes aligned sg element lengths, DMAREQCTL
must enabled.
Per Forlin (1):
mmc: mmci: add constraints on alignment for SDIO
Stefan Nilsson XK (1):
mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
drivers/mmc/host/mmci.c | 56 +++++++++++++++++++++++++++++++++++++++++------
drivers/mmc/host/mmci.h | 7 ++++++
2 files changed, 56 insertions(+), 7 deletions(-)
--
1.7.5.4
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 14:56 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024145139.GH1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> > On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > > index 8fe132d..29dcf90 100644
> > > --- a/drivers/regulator/core.c
> > > +++ b/drivers/regulator/core.c
> > > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > >
> > > /* find device_node and attach it */
> > > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > > + regulator_desc->name);
> >
> > of_find_node_by_name() doesn't work that way. The first argument is a
> > starting point, but it doesn't restrict the search to children of a
> > node.
> >
> > for_each_child_of_node() is what you want to use when iterating over
> > the children which unfortunately changes the structure of this
> > function.
> >
> The dev->parent->of_node is meant to point to node 'pmic: mc13892@0'.
> And the intention here is not to iterate over the children, but to
> start a search from a reasonable point rather than the top root node.
It is always better to attach the of_node at struct device
registration time instead of searching the tree in common code. The
of_node should already be assigned by the time regulator_register() is
called. The caller should already have access to all that information
before the call anyway, especially since it is not strictly manditory
for all regulators to use the common binding. It is entirely
conceivable that the proposed binding won't work for some regulators.
g.
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024145139.GH1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 10:51:40PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> > On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > > index 8fe132d..29dcf90 100644
> > > --- a/drivers/regulator/core.c
> > > +++ b/drivers/regulator/core.c
> > > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > >
> > > /* find device_node and attach it */
> > > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > > + regulator_desc->name);
> >
> > of_find_node_by_name() doesn't work that way. The first argument is a
> > starting point, but it doesn't restrict the search to children of a
> > node.
> >
> > for_each_child_of_node() is what you want to use when iterating over
> > the children which unfortunately changes the structure of this
> > function.
> >
> The dev->parent->of_node is meant to point to node 'pmic: mc13892 at 0'.
> And the intention here is not to iterate over the children, but to
> start a search from a reasonable point rather than the top root node.
It is always better to attach the of_node at struct device
registration time instead of searching the tree in common code. The
of_node should already be assigned by the time regulator_register() is
called. The caller should already have access to all that information
before the call anyway, especially since it is not strictly manditory
for all regulators to use the common binding. It is entirely
conceivable that the proposed binding won't work for some regulators.
g.
^ permalink raw reply
* Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
From: Randy Dunlap @ 2011-10-24 14:57 UTC (permalink / raw)
To: Ben Hutchings
Cc: LKML, Dave Jones, Greg KH, Debian kernel maintainers,
Rusty Russell
In-Reply-To: <1319461948.31243.31.camel@deadeye>
On 10/24/11 06:12, Ben Hutchings wrote:
> Use of the GPL or a compatible licence doesn't necessarily make the code
> any good. We already consider staging modules to be suspect, and this
> should also be true for out-of-tree modules which may receive very
> little review.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> Debian has been carrying this for the last few kernel versions. The
> recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest
> that this might be more generally useful.
>
> Ben.
>
> include/linux/kernel.h | 1 +
> kernel/module.c | 5 +++++
> kernel/panic.c | 2 ++
> scripts/mod/modpost.c | 7 +++++++
> 4 files changed, 15 insertions(+), 0 deletions(-)
Hi,
Please add 'O' to Documentation/oops-tracing.txt.
Thanks.
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 46ac9a5..2c05967 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -369,6 +369,7 @@ extern enum system_states {
> #define TAINT_WARN 9
> #define TAINT_CRAP 10
> #define TAINT_FIRMWARE_WORKAROUND 11
> +#define TAINT_OOT_MODULE 12
>
> extern const char hex_asc[];
> #define hex_asc_lo(x) hex_asc[((x) & 0x0f)]
> diff --git a/kernel/module.c b/kernel/module.c
> index 04379f92..c0872f1 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2487,6 +2487,9 @@ static int check_modinfo(struct module *mod, struct load_info *info)
> return -ENOEXEC;
> }
>
> + if (!get_modinfo(info, "intree"))
> + add_taint_module(mod, TAINT_OOT_MODULE);
> +
> if (get_modinfo(info, "staging")) {
> add_taint_module(mod, TAINT_CRAP);
> printk(KERN_WARNING "%s: module is from the staging directory,"
> @@ -3257,6 +3260,8 @@ static char *module_flags(struct module *mod, char *buf)
> buf[bx++] = '(';
> if (mod->taints & (1 << TAINT_PROPRIETARY_MODULE))
> buf[bx++] = 'P';
> + else if (mod->taints & (1 << TAINT_OOT_MODULE))
> + buf[bx++] = 'O';
> if (mod->taints & (1 << TAINT_FORCED_MODULE))
> buf[bx++] = 'F';
> if (mod->taints & (1 << TAINT_CRAP))
> diff --git a/kernel/panic.c b/kernel/panic.c
> index d7bb697..b2659360 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -177,6 +177,7 @@ static const struct tnt tnts[] = {
> { TAINT_WARN, 'W', ' ' },
> { TAINT_CRAP, 'C', ' ' },
> { TAINT_FIRMWARE_WORKAROUND, 'I', ' ' },
> + { TAINT_OOT_MODULE, 'O', ' ' },
> };
>
> /**
> @@ -194,6 +195,7 @@ static const struct tnt tnts[] = {
> * 'W' - Taint on warning.
> * 'C' - modules from drivers/staging are loaded.
> * 'I' - Working around severe firmware bug.
> + * 'O' - Out-of-tree module has been loaded.
> *
> * The string is overwritten by the next call to print_tainted().
> */
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index a509ff8..2bd594e 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1849,6 +1849,12 @@ static void add_header(struct buffer *b, struct module *mod)
> buf_printf(b, "};\n");
> }
>
> +static void add_intree_flag(struct buffer *b, int is_intree)
> +{
> + if (is_intree)
> + buf_printf(b, "\nMODULE_INFO(intree, \"Y\");\n");
> +}
> +
> static void add_staging_flag(struct buffer *b, const char *name)
> {
> static const char *staging_dir = "drivers/staging";
> @@ -2169,6 +2175,7 @@ int main(int argc, char **argv)
> buf.pos = 0;
>
> add_header(&buf, mod);
> + add_intree_flag(&buf, !external_module);
> add_staging_flag(&buf, mod->name);
> err |= add_versions(&buf, mod);
> add_depends(&buf, mod, modules);
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] spi/pl022: Enable clock in probe an use runtime_idle
From: Linus Walleij @ 2011-10-24 14:58 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Grant Likely, spi-devel-general, Lee Jones, Ulf Hansson,
linux-arm-kernel
In-Reply-To: <20111024125030.GB17693@n2100.arm.linux.org.uk>
2011/10/24 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Oct 24, 2011 at 02:03:42PM +0200, Grant Likely wrote:
>> On Fri, Oct 21, 2011 at 04:08:44PM +0200, Ulf Hansson wrote:
>> > Since we are always runtime resumed when leaving probe
>> > the clock must be enabled. To accomplish that we are able
>> > to be runtime suspended after probe in the case when no
>> > request is going to be recieved, a runtime_idle function
>> > has been implemented.
>> >
>> > Change-Id: I6cb86f2cad30ecaab16f512daf4674b039b18213
>> > Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
>> > Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34447
>>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>>
>> Since it depends on Russell's tree, I'm okay with it going in that way.
>
> I've received this patch in the patch system, but I'm not planning to
> apply it yet because it depends on two branches in my tree (amba and clk).
We can fixup that in the aftermath of the merge window, no
hurries.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] spi/pl022: Enable clock in probe an use runtime_idle
From: Linus Walleij @ 2011-10-24 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024125030.GB17693@n2100.arm.linux.org.uk>
2011/10/24 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Oct 24, 2011 at 02:03:42PM +0200, Grant Likely wrote:
>> On Fri, Oct 21, 2011 at 04:08:44PM +0200, Ulf Hansson wrote:
>> > Since we are always runtime resumed when leaving probe
>> > the clock must be enabled. To accomplish that we are able
>> > to be runtime suspended after probe in the case when no
>> > request is going to be recieved, a runtime_idle function
>> > has been implemented.
>> >
>> > Change-Id: I6cb86f2cad30ecaab16f512daf4674b039b18213
>> > Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
>> > Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34447
>>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>>
>> Since it depends on Russell's tree, I'm okay with it going in that way.
>
> I've received this patch in the patch system, but I'm not planning to
> apply it yet because it depends on two branches in my tree (amba and clk).
We can fixup that in the aftermath of the merge window, no
hurries.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] Reduce vm_stat cacheline contention in __vm_enough_memory
From: Dimitri Sivanich @ 2011-10-24 14:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: David Rientjes, Andi Kleen, linux-kernel, linux-mm, Andrew Morton,
Mel Gorman
In-Reply-To: <alpine.DEB.2.00.1110191029570.24001@router.home>
On Wed, Oct 19, 2011 at 10:31:54AM -0500, Christoph Lameter wrote:
> On Wed, 19 Oct 2011, Dimitri Sivanich wrote:
>
> > For 120 threads writing in parallel (each to it's own mountpoint), the
> > threshold needs to be on the order of 1000. At a threshold of 750, I
> > start to see a slowdown of 50-60 MB/sec.
> >
> > For 400 threads writing in parallel, the threshold needs to be on the order
> > of 2000 (although we're off by about 40 MB/sec at that point).
> >
> > The necessary deltas in these cases are quite a bit higher than the current
> > 125 maximum (see calculate*threshold in mm/vmstat.c).
> >
> > I like the idea of having certain areas triggering vm_stat sync, as long
> > as we know what those key areas are and how often they might be called.
>
> You could potentially reduce the maximum necessary by applying my earlier
> patch (but please reduce the counters touched to the current cacheline).
> That should reduce the number of updates in the global cacheline and allow
> you to reduce the very high deltas that you have to deal with now.
I tried updating whole, single vm_stat cachelines as you suggest, but that
made little if any difference in tmpfs writeback performance. The same higher
threshold values were still necessary to significantly reduce the contention
seen in __vm_enough_memory.
^ permalink raw reply
* Re: [Xen-users] Re: Xen document day (Oct 12 or 26)
From: Joseph Glanville @ 2011-10-24 14:59 UTC (permalink / raw)
To: Lars Kurth
Cc: Andrew Bobulsky, xen-users@lists.xensource.com,
xen-devel@lists.xensource.com, Ian Campbell,
Konrad Rzeszutek Wilk
In-Reply-To: <4EA54D72.7040205@xen.org>
[-- Attachment #1.1: Type: text/plain, Size: 4478 bytes --]
Agreed on all counts.
I think you have a very good point in the "trails" concept... the idea of
having an information graph resounds with the goal to make advanced
documentation accessible but not overwhelm newcomers.
The DocTools macros look good.
Joseph.
On 24 October 2011 22:35, Lars Kurth <lars.kurth@xen.org> wrote:
> On 22/10/2011 00:33, Joseph Glanville wrote:
>
> As I noted, this is just my opinion, its not my place to decide how
> people want to use it but if we could have to idea of what should and
> shouldn't be in there it makes it easy to then structure the information.
>
> I think we need to setup a guided rewrite/refactor of the core
>>> documentation so it resembles something close to this:
>>>
>>> Overview (brief introduction, architecture, why xen is different and
>>> maybe abit of xen philosophy)
>>> Getting started guide ( Installation of Xen on Debian - probably the
>>> simplest and easiest way to get started with Xen at the moment, start a
>>> Debian PV guest, start at Windows HVM guest)
>>> Installation guide ( More indepth covering all the core distros and some
>>> more advanced installations including compilation from source and using the
>>> Linux 3.1 kernel, networking options etc)
>>> Administration guide ( This bit requires atlot of discussion, do we
>>> recommend xm still? should we only support xl? If that is the case how to we
>>> recommend stuff like managed domains etc..)
>>> Advanced topics.. stuff like Networking, PCI passthrough etc deserve
>>> their own pages
>>>
>> Are you suggesting we restructure the wiki front-page around this?
>
>
> Yes, maybe not -exactly- this format but something resembling it would be
> of value I think. Guiding people towards the beginners documentation and
> making it quite clear there is a reading progression will show much stronger
> cohesion.
>
>
> I think we have two choices:
> a) We re-write large sections of the wiki with the purpose of making it
> more accessible
> b) We use create methods to highlight existing stuff and focus on filling
> gaps, etc.
>
> I think that b) is more valuable. Here are a few ideas:
>
> Trails: I have come across the idea of wiki trails before. These are
> pages/indexes which lead the reader through a series of articles. The key is
> that these are easily identified and highlighted from the main page. E.g. we
> could use Trails (listing all trails and a page template),
> Trails/XenOverview, Trails/XenGettingStarted, etc. By doing this, we group
> the existing documents, rather than re-writing a lot of stuff and just
> refactoring it. This would make an easier start, and if somebody wishes they
> can always clean up and refactor the documentation which makes up a trail.
>
> I had a look around for MoinMoin plug-ins for something which may help with
> trails: not much, but there are a couple of plugins that may help
>
> Being able to create TOCs across sevaleraL wiki pages (
> http://moinmo.in/SteveTindle/DocTools from
> http://moinmo.in/MacroMarket#Release_1.5 using /EnhancedTableOfContents<http://moinmo.in/MacroMarket/EnhancedTableOfContents>
> /SetSection <http://moinmo.in/MacroMarket/SetSection> /TocOf<http://moinmo.in/MacroMarket/TocOf>)
>
>
> The current wiki is poluted with alot of architecture and design info
>> that isn't of interest to a general user but is still key to understanding
>> Xen from a developers point of view.
>>
> Part of the issue is that it is hard for me to identify what is what. If I
>> had a good approximation of what is what, I (or others) could just go
>> through the motions and re-encode stuff accordingly.
>
>
> I have exactly the same problem, I just need to undertand what needs to be
> done and where.
>
> I hope I will get some of this out of Wed.
>
>
> I think what you seem to be saying is that there would be extremely high
>> value in having a "Getting started" guide and some other entry level
>> documentation (even if just an index page) accessible from the wiki front
>> page.
>>
>
> Precisely, documenting the more advanced features of Xen seems to be
> something that we can approach over time. Beginner documentation is
> immeadiately lacking and seems to be an easier target that would benefit
> more people.
>
> Let's see whether we can get enough structure in place on Wed and make a
> good start
>
> Lars
>
>
--
*
Founder | Director | VP Research
Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52
| Mobile: 0428 754 846
[-- Attachment #1.2: Type: text/html, Size: 7571 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
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.