From: "xiaofeng.yan"
function xa_store_irq() has three parameters because of removing
patameter "gfp_t gfp"
Signed-off-by: xiaofeng.yan
---
drivers/infiniband/core/cm.c| 2 +-
drivers/infiniband/hw/hns/hns_roce_qp.c | 2 +-
drivers/infiniband/hw/mlx5/srq_cmd.
From: "xiaofeng.yan"
function xa_store_irq() has a spinlock as follows:
xa_lock_irq()
-->spin_lock_irq(&(xa)->xa_lock)
GFP_KERNEL flag could cause sleep.
So change GFP_KERNEL to GFP_ATOMIC and Romve "gfp_t gfp" in function
static inline void *xa_store_irq(st
Commit-ID: 5a4fd0368517bc5b5399ef958f6d30cbff492918
Gitweb: http://git.kernel.org/tip/5a4fd0368517bc5b5399ef958f6d30cbff492918
Author: xiaofeng.yan
AuthorDate: Wed, 23 Sep 2015 14:55:59 +0800
Committer: Ingo Molnar
CommitDate: Tue, 6 Oct 2015 17:08:23 +0200
sched/core: Remove
Commit-ID: 5a4fd0368517bc5b5399ef958f6d30cbff492918
Gitweb: http://git.kernel.org/tip/5a4fd0368517bc5b5399ef958f6d30cbff492918
Author: xiaofeng.yan <yanxiaof...@inspur.com>
AuthorDate: Wed, 23 Sep 2015 14:55:59 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Tue
variable "value" in struct acpi_pnp_device_id has been changed
to "string".
Signed-off-by: xiaofeng.yan
---
drivers/acpi/acpica/nsdumpdv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/nsdumpdv.c b/drivers/acpi/acpica/nsdumpdv.c
in
variable value in struct acpi_pnp_device_id has been changed
to string.
Signed-off-by: xiaofeng.yan yanxiaof...@inspur.com
---
drivers/acpi/acpica/nsdumpdv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/nsdumpdv.c b/drivers/acpi/acpica/nsdumpdv.c
index
TEST
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
TEST
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
change tabke to take.
Signed-off-by: xiaofeng.yan
Reviewed-by: Jiang Liu
---
drivers/iommu/intel_irq_remapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 5709ae9..85676d0 100644
change tabke to take.
Signed-off-by: xiaofeng.yan
---
drivers/iommu/intel_irq_remapping.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 5709ae9..d59f82d 100644
--- a/drivers/iommu
change tabke to take.
Signed-off-by: xiaofeng.yan yanxiaof...@inspur.com
---
drivers/iommu/intel_irq_remapping.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 5709ae9..d59f82d 100644
change tabke to take.
Signed-off-by: xiaofeng.yan yanxiaof...@inspur.com
Reviewed-by: Jiang Liu jiang@linux.intel.com
---
drivers/iommu/intel_irq_remapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu
change tabke to take.
Signed-off-by: xiaofeng.yan yanxiaof...@inspur.com
Reviewed-by: Jiang Liu jiang@linux.intel.com
---
drivers/iommu/intel_irq_remapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu
change tabke to take.
Signed-off-by: xiaofeng.yan yanxiaof...@inspur.com
---
drivers/iommu/intel_irq_remapping.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 5709ae9..d59f82d 100644
, sched_clock_mask);
}
xiaofeng.yan (1):
ARM: sched_clock: Load cycle count after epoch stabilizes
arch/arm/kernel/sched_clock.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message
...@arm.linux.org.uk
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Signed-off-by: John Stultz john.stu...@linaro.org
Tested-by: xiaofeng.yan xiaofeng@huawei.com
---
Found this while reading through the code. I haven't actually
seen it in practice but I think it's real.
---
arch/arm
On 2014/12/6 17:57, Russell King - ARM Linux wrote:
On Fri, Dec 05, 2014 at 02:17:19PM -0800, Greg KH wrote:
On Fri, Nov 28, 2014 at 02:18:58AM +, xiaofeng.yan wrote:
From: Stephen Boyd sb...@codeaurora.org
There is a small race between when the cycle count is read from
the hardware
...@arm.linux.org.uk
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Signed-off-by: John Stultz john.stu...@linaro.org
Tested-by: xiaofeng.yan xiaofeng@huawei.com
---
Found this while reading through the code. I haven't actually
seen it in practice but I think it's real.
---
arch/arm
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
The function was moved from arch/arm/kernel/sched_clock.c to
kernel/time/sched_clock.c because of
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
The function was moved from arch/arm/kernel/sched_clock.c to
kernel/time/sched_clock.c because of
the hardware after the epoch has
stabilized.
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Signed-off-by: John Stultz john.stu...@linaro.org
[xiaofeng.yan: Backported to 3.10: reomve duplicated code after cherry-pick]
Signed-off-by: xiaofeng.yan xiaofeng
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
It was built successful for me. What do you think?
Stephen Boyd (1):
ARM: sched_clock: Load cycle
From: Stephen Boyd sb...@codeaurora.org
There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:
CPU0 CPU1
cyc = read_sched_clock()
cyc_to_sched_clock()
On 2014/11/28 0:15, Greg KH wrote:
On Thu, Nov 27, 2014 at 11:15:36AM +, xiaofeng.yan wrote:
From: Stephen Boyd sb...@codeaurora.org
There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:
CPU0
commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes
This looks applicable to stable-3.10, which load cycle count after epoch
stabilizes,
It was built successful for me. What do you think?
Stephen Boyd (1):
ARM: sched_clock: Load cycle
From: Stephen Boyd sb...@codeaurora.org
There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:
CPU0 CPU1
cyc = read_sched_clock()
cyc_to_sched_clock()
Hi all,
I debug program with gdb on arm platform. The environment is as follow:
platform: vexpress(virtual app:ds:virtual machine app:ds:machine for
arm on qemu)
libc: uclibc
A error information happen when debug the next codes.
0xb6fa0440 in ?? () from /lib/libc.so.0
The call stack can't
test
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
test
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Commit-ID: 177ef2a6315ea7bf173653182324e1dcd08ffeaa
Gitweb: http://git.kernel.org/tip/177ef2a6315ea7bf173653182324e1dcd08ffeaa
Author: xiaofeng.yan
AuthorDate: Tue, 26 Aug 2014 03:15:41 +
Committer: Ingo Molnar
CommitDate: Sun, 7 Sep 2014 11:09:59 +0200
sched/deadline: Fix
Commit-ID: 177ef2a6315ea7bf173653182324e1dcd08ffeaa
Gitweb: http://git.kernel.org/tip/177ef2a6315ea7bf173653182324e1dcd08ffeaa
Author: xiaofeng.yan xiaofeng@huawei.com
AuthorDate: Tue, 26 Aug 2014 03:15:41 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Sun, 7 Sep 2014 11
The overrun could happen in function start_hrtick_dl()
when a task with SCHED_DEADLINE runs in the microsecond range.
For example, a task with SCHED_DEADLINE has the following parameters
Task runtime deadline period
P1 200us 500us500us
The deadline and period from task P1 are less
The overrun could happen in function start_hrtick_dl()
when a task with SCHED_DEADLINE runs in the microsecond range.
For example, a task with SCHED_DEADLINE has the following parameters
Task runtime deadline period
P1 200us 500us500us
The deadline and period from task P1 are less
On 2014/8/12 22:52, Ingo Molnar wrote:
* xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next
On 2014/8/12 22:52, Ingo Molnar wrote:
* xiaofeng.yan xiaofeng@huawei.com wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo HRTICK /sys/kernel/debug/sched_features
PC#trace-cmd
Commit-ID: 1b09d29bc00964d9032d80516f958044ac6b3805
Gitweb: http://git.kernel.org/tip/1b09d29bc00964d9032d80516f958044ac6b3805
Author: xiaofeng.yan
AuthorDate: Mon, 7 Jul 2014 05:59:04 +
Committer: Ingo Molnar
CommitDate: Wed, 16 Jul 2014 13:38:20 +0200
sched/rt: Fix
Commit-ID: 1b09d29bc00964d9032d80516f958044ac6b3805
Gitweb: http://git.kernel.org/tip/1b09d29bc00964d9032d80516f958044ac6b3805
Author: xiaofeng.yan xiaofeng@huawei.com
AuthorDate: Mon, 7 Jul 2014 05:59:04 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 16 Jul 2014 13
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo HRTICK /sys/kernel/debug/sched_features
PC#trace-cmd
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
Move this piece of code with the limit of the least time slice
from hrtick_start_fair() to hrtick_start() because
EDF schedule class also need this function in start_hrtick_dl().
EDF tasks with the runtime of microsecond level will lead to the wrong
precision because system can't control the end
Move this piece of code with the limit of the least time slice
from hrtick_start_fair() to hrtick_start() because
EDF schedule class also need this function in start_hrtick_dl().
EDF tasks with the runtime of microsecond level will lead to the wrong
precision because system can't control the end
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo HRTICK /sys/kernel/debug/sched_features
PC#trace-cmd
On 2014/7/8 20:52, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 07:50:22PM +0800, xiaofeng.yan wrote:
I have tested this solution, It can work very well with deadline schedule
class.
Great, please send it as a proper patch and I might just press 'A' ;-)
Ok, I will send it later
On 2014/7/8 19:23, xiaofeng.yan wrote:
On 2014/7/8 17:33, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 08:53:27AM +, xiaofeng.yan wrote:
static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
{
-s64 delta = p->dl.dl_runtime - p->dl.runtime;
-
-if (delta &
On 2014/7/8 17:33, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 08:53:27AM +, xiaofeng.yan wrote:
static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
{
- s64 delta = p->dl.dl_runtime - p->dl.runtime;
-
- if (delta > 1)
- hrtick_st
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
On 2014/7/8 16:53, xiaofeng.yan wrote:
Sorry, I send a old patch and send a new one later.
Thanks
Yan
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
On 2014/7/8 15:49, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 10:51:02AM +0800, xiaofeng.yan wrote:
On 2014/7/8 10:40, Li Zefan wrote:
On 2014/7/8 9:10, xiaofeng.yan wrote:
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could
On 2014/7/8 15:49, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 10:51:02AM +0800, xiaofeng.yan wrote:
On 2014/7/8 10:40, Li Zefan wrote:
On 2014/7/8 9:10, xiaofeng.yan wrote:
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo HRTICK /sys/kernel/debug/sched_features
PC#trace-cmd
On 2014/7/8 16:53, xiaofeng.yan wrote:
Sorry, I send a old patch and send a new one later.
Thanks
Yan
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo HRTICK /sys/kernel/debug/sched_features
PC#trace-cmd
On 2014/7/8 17:33, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 08:53:27AM +, xiaofeng.yan wrote:
static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
{
- s64 delta = p-dl.dl_runtime - p-dl.runtime;
-
- if (delta 1)
- hrtick_start(rq, p
On 2014/7/8 19:23, xiaofeng.yan wrote:
On 2014/7/8 17:33, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 08:53:27AM +, xiaofeng.yan wrote:
static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
{
-s64 delta = p-dl.dl_runtime - p-dl.runtime;
-
-if (delta 1
On 2014/7/8 20:52, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 07:50:22PM +0800, xiaofeng.yan wrote:
I have tested this solution, It can work very well with deadline schedule
class.
Great, please send it as a proper patch and I might just press 'A' ;-)
Ok, I will send it later
On 2014/7/8 10:40, Li Zefan wrote:
On 2014/7/8 9:10, xiaofeng.yan wrote:
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case
Signed-off-by: xiaofeng.yan
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..6541565 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -306,7 +306,7 @@ static
Signed-off-by: xiaofeng.yan xiaofeng@huawei.com
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..6541565 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case
On 2014/7/8 10:40, Li Zefan wrote:
On 2014/7/8 9:10, xiaofeng.yan wrote:
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level
hen runtime is less than
10us.
So the process will continue to run until tick-period coming.
For fixing this problem, Let delta is equal to 10us when it is less than 10us.
So the hrtimer will start up to control the end of process.
Signed-off-by: xiaofeng.yan
---
kernel/sched/deadline.c |
the process will continue to run until tick-period coming.
For fixing this problem, Let delta is equal to 10us when it is less than 10us.
So the hrtimer will start up to control the end of process.
Signed-off-by: xiaofeng.yan xiaofeng@huawei.com
---
kernel/sched/deadline.c |6 ++
1 file
On 2014/6/19 17:13, Luca Abeni wrote:
On 06/18/2014 09:01 AM, xiaofeng.yan wrote:
[...]
I also had an implementation of the GRUB algorithm (based on a
modification
of my old CBS scheduler for Linux), but the computational
complexity of the
algorithm was too high. That's why I never proposed
On 2014/6/19 17:13, Luca Abeni wrote:
On 06/18/2014 09:01 AM, xiaofeng.yan wrote:
[...]
I also had an implementation of the GRUB algorithm (based on a
modification
of my old CBS scheduler for Linux), but the computational
complexity of the
algorithm was too high. That's why I never proposed
On 2014/6/17 16:01, Luca Abeni wrote:
Hi,
On 06/17/2014 04:43 AM, xiaofeng.yan wrote:
[...]
The basic ideas are (warning! This is an over-simplification of the
algorithm! :)
- You assign runtime and period to each SCHED_DEADLINE task as usual
- Each task is guaranteed to receive its runtime
On 2014/6/17 16:01, Luca Abeni wrote:
Hi,
On 06/17/2014 04:43 AM, xiaofeng.yan wrote:
[...]
The basic ideas are (warning! This is an over-simplification of the
algorithm! :)
- You assign runtime and period to each SCHED_DEADLINE task as usual
- Each task is guaranteed to receive its runtime
On 2014/5/21 20:45, Luca Abeni wrote:
Hi,
first of all, sorry for the ultra-delayed reply: I've been busy,
and I did not notice this email... Anyway, some comments are below
On 05/16/2014 09:11 AM, Henrik Austad wrote:
[...]
This can also be implemented in user-space (without modifying the
On 2014/5/21 20:45, Luca Abeni wrote:
Hi,
first of all, sorry for the ultra-delayed reply: I've been busy,
and I did not notice this email... Anyway, some comments are below
On 05/16/2014 09:11 AM, Henrik Austad wrote:
[...]
This can also be implemented in user-space (without modifying the
Commit-ID: 4027d080854d1be96ef134a1c3024d5276114db6
Gitweb: http://git.kernel.org/tip/4027d080854d1be96ef134a1c3024d5276114db6
Author: xiaofeng.yan
AuthorDate: Fri, 9 May 2014 03:21:27 +
Committer: Ingo Molnar
CommitDate: Thu, 22 May 2014 11:16:37 +0200
sched/rt: Fix 'struct
Commit-ID: 4027d080854d1be96ef134a1c3024d5276114db6
Gitweb: http://git.kernel.org/tip/4027d080854d1be96ef134a1c3024d5276114db6
Author: xiaofeng.yan xiaofeng@huawei.com
AuthorDate: Fri, 9 May 2014 03:21:27 +
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 22 May 2014 11
Commit-ID: 6e9a8b9d6a9257bc124a1609f25597064ef9c167
Gitweb: http://git.kernel.org/tip/6e9a8b9d6a9257bc124a1609f25597064ef9c167
Author: xiaofeng.yan
AuthorDate: Mon, 12 May 2014 07:41:17 +
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 22:02:42 +0900
sched/rt: Fix
Commit-ID: c07a16f784dfb8083c3b0157fbef18cb1292b9fc
Gitweb: http://git.kernel.org/tip/c07a16f784dfb8083c3b0157fbef18cb1292b9fc
Author: xiaofeng.yan
AuthorDate: Fri, 9 May 2014 03:21:27 +
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 22:02:42 +0900
sched/rt: Fix a comment
Commit-ID: c07a16f784dfb8083c3b0157fbef18cb1292b9fc
Gitweb: http://git.kernel.org/tip/c07a16f784dfb8083c3b0157fbef18cb1292b9fc
Author: xiaofeng.yan xiaofeng@huawei.com
AuthorDate: Fri, 9 May 2014 03:21:27 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Mon, 19 May
Commit-ID: 6e9a8b9d6a9257bc124a1609f25597064ef9c167
Gitweb: http://git.kernel.org/tip/6e9a8b9d6a9257bc124a1609f25597064ef9c167
Author: xiaofeng.yan xiaofeng@huawei.com
AuthorDate: Mon, 12 May 2014 07:41:17 +
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Mon, 19 May
EDF use sched_setattr() instead of sched_setscheduler().
Signed-off-by: xiaofeng.yan
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index b080957..558e41a 100644
--- a/kernel/sched/deadline.c
EDF use sched_setattr() instead of sched_setscheduler().
Signed-off-by: xiaofeng.yan xiaofeng@huawei.com
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index b080957..558e41a 100644
-by: xiaofeng.yan
---
include/linux/sched.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..ed64468 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1123,8 +1123,8 @@ struct sched_dl_entity
On 2014/5/8 19:04, Peter Zijlstra wrote:
On Thu, May 08, 2014 at 10:31:20AM +, xiaofeng.yan wrote:
Change sched_setscheduler2() to sched_setscheduler() in the comments.
There isn't function sched_setscheduler2() in the main line.
The previous EDF version defines this function
before being
.
Signed-off-by: xiaofeng.yan
---
include/linux/sched.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..fe263e7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1123,8 +1123,8 @@ struct
.
Signed-off-by: xiaofeng.yan xiaofeng@huawei.com
---
include/linux/sched.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..fe263e7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1123,8 +1123,8
On 2014/5/8 19:04, Peter Zijlstra wrote:
On Thu, May 08, 2014 at 10:31:20AM +, xiaofeng.yan wrote:
Change sched_setscheduler2() to sched_setscheduler() in the comments.
There isn't function sched_setscheduler2() in the main line.
The previous EDF version defines this function
before being
-by: xiaofeng.yan xiaofeng@huawei.com
---
include/linux/sched.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..ed64468 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1123,8 +1123,8 @@ struct
From: Xiaofeng Yan xiaofeng@windriver.com
Add upstream-status and signed-off-by to functions.patch
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
.../lsb/lsbinitscripts/functions.patch |3 +++
1 file changed, 3 insertions(+)
diff --git
From: Xiaofeng Yan xiaofeng@windriver.com
Add the multilib support for this package and remove the original
/etc/init.d/functions and link functions to functions.lsbinitscripts.
Add the header for patch.
The following changes since commit 3f292735407e50eebb23044fa9f579906a94e800:
From: Xiaofeng Yan xiaofeng@windriver.com
The linking will fail when an original functions exist. So remove the
original functions when building an lsb image and make functions linking to
functions.lsbinitscripts successfully.
[YOCTO #2133]
Signed-off-by: Xiaofeng Yan
From: Xiaofeng Yan xiaofeng@windriver.com
Add the multilib support for this package to multilib.conf because error will
appear when building an lib32-core-image-lsb without this patch.
[YOCTO #2571]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
meta/conf/multilib.conf |1 +
From: Xiaofeng Yan xiaofeng@windriver.com
The content to modify this bbclass is as follow:
- Use the existing functions to get license as a directory instead of
rewriting it for avoiding code duplication.
- Use SPDXLICENSEMAP to map licenses
[YOCTO #2473]
Signed-off-by: Xiaofeng Yan
From: Xiaofeng Yan xiaofeng@windriver.com
The content to modify this bbclass is as follow:
- Use the existing functions to get license as a directory instead of
rewriting it for avoiding code duplication.
- Use SPDXLICENSEMAP to map licenses
The following changes since commit
From: Xiaofeng Yan xiaofeng@windriver.com
The version of initscripts has more functions than the simple.
There could be some errors for current initscripts when running
some programe because of absent some functions provided by initscripts.
[YOCTO #2133]
Signed-off-by: Xiaofeng Yan
From: Xiaofeng Yan xiaofeng@windriver.com
This is V2. The modification is as follows by comparison with V1:
- Add extra description in section DESCRIPTION
- Use bbclass update-alternatives instead of command method.
The following changes since commit de4cdfd6bc1280ac7ac0559b87734d26294ef773:
From: Xiaofeng Yan xiaofeng@windriver.com
Add the condition judgment to functions for avoiding to print error
information when system start up at first.
[YOCTO #2133]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
.../lsb/lsbinitscripts/functions.patch | 11
From: Xiaofeng Yan xiaofeng@windriver.com
Initscripts with stronger functions will replace the simple one,
which will avoid error when some packages need functions which could
be absent in the simple initscripts.
[YOCTO #2133]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
From: Xiaofeng Yan xiaofeng@windriver.com
The usability of the archiver classes can be improved, beyond the
simple addition of default values for the variables.
A user could well inherit just archiver rather than the individual
useful classes, and not realize it will do nothing.
The
From: Xiaofeng Yan xiaofeng@windriver.com
The usability of the archiver classes can be improved, beyond the
simple addition of default values for the variables. A user could
well inherit just archiver rather than the individual useful classes,
and not realize it will do nothing.
[YOCTO
From: Xiaofeng Yan xiaofeng@windriver.com
Change the usage about arhiver.bbclass due to the improvement for
usability of archiver.bbclass
[YOCTO #2472]
Signed-off-by: Xiaofeng Yan xiaofeng@windriver.com
---
meta-yocto/conf/local.conf.sample.extended | 31 ---
1 - 100 of 111 matches
Mail list logo
