On 2014/10/16 17:13, Greg KH wrote:
> On Thu, Oct 16, 2014 at 03:23:53PM +0800, Weng Meiling wrote:
>> On 2014/10/16 15:07, Frans Klaver wrote:
>>> On Thu, Oct 16, 2014 at 3:56 AM, Weng Meiling
>>> wrote:
>>>>
>>>> Would you please give
On 2014/10/16 17:13, Greg KH wrote:
On Thu, Oct 16, 2014 at 03:23:53PM +0800, Weng Meiling wrote:
On 2014/10/16 15:07, Frans Klaver wrote:
On Thu, Oct 16, 2014 at 3:56 AM, Weng Meiling
wengmeiling.w...@huawei.com wrote:
Would you please give me some of your views on this issue? Any
On 2014/10/16 15:07, Frans Klaver wrote:
> On Thu, Oct 16, 2014 at 3:56 AM, Weng Meiling
> wrote:
>>
>> Would you please give me some of your views on this issue? Any suggestion is
>> appreciative.
>
> It'll come. Be patient.
>
> .
>
yeah, maybe I'm
On 2014/10/16 15:07, Frans Klaver wrote:
On Thu, Oct 16, 2014 at 3:56 AM, Weng Meiling
wengmeiling.w...@huawei.com wrote:
Would you please give me some of your views on this issue? Any suggestion is
appreciative.
It'll come. Be patient.
.
yeah, maybe I'm too impatient
Hi,
Would you please give me some of your views on this issue? Any suggestion is
appreciative.
Thanks!
Weng Meiling
On 2014/10/15 14:42, Weng Meiling wrote:
> When the last child kobject was deleted, it's parent kobject will be deleted,
> when removing the parent kobject if the
eave(kobj); //remove kobj from kset list...
} }
We had triggered the bug, the detail message link:
https://lkml.org/lkml/2014/10/13/40
Signed-off-by: Weng Meiling
---
lib/kobject.c | 3 ++-
1 file changed, 2 insertions(+), 1 de
from kset list...
} }
We had triggered the bug, the detail message link:
https://lkml.org/lkml/2014/10/13/40
Signed-off-by: Weng Meiling wengmeiling.w...@huawei.com
---
lib/kobject.c | 3 ++-
1 file changed, 2 insertions(+), 1
Hi,
Would you please give me some of your views on this issue? Any suggestion is
appreciative.
Thanks!
Weng Meiling
On 2014/10/15 14:42, Weng Meiling wrote:
When the last child kobject was deleted, it's parent kobject will be deleted,
when removing the parent kobject if the parent kobject's
On 2014/10/11 11:00, Weng Meiling wrote:
> ping ...
>
> On 2014/10/9 20:47, Weng Meiling wrote:
>> On 2014/10/9 20:43, Weng Meiling wrote:
>>> Hi guys,
>>>
>>> I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
>>
On 2014/10/11 11:00, Weng Meiling wrote:
ping ...
On 2014/10/9 20:47, Weng Meiling wrote:
On 2014/10/9 20:43, Weng Meiling wrote:
Hi guys,
I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
duplicated sysfs link.
the detail mail:
https://lkml.org/lkml/2013/3/8
ping ...
On 2014/10/9 20:47, Weng Meiling wrote:
> On 2014/10/9 20:43, Weng Meiling wrote:
>> Hi guys,
>>
>> I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
>> duplicated sysfs link.
>>
>> the detail mail:
>>
>> ht
ping ...
On 2014/10/9 20:47, Weng Meiling wrote:
On 2014/10/9 20:43, Weng Meiling wrote:
Hi guys,
I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
duplicated sysfs link.
the detail mail:
https://lkml.org/lkml/2013/3/8/370
but it seems the problems has
On 2014/10/9 20:43, Weng Meiling wrote:
> Hi guys,
>
> I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
> duplicated sysfs link.
>
> the detail mail:
>
> https://lkml.org/lkml/2013/3/8/370
>
> but it seems the problems has no conc
Hi guys,
I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
duplicated sysfs link.
the detail mail:
https://lkml.org/lkml/2013/3/8/370
but it seems the problems has no conclusion. In our environment, we triggered
the bug too, but for error ENOENT:
we use 3.4 kernel,
Hi guys,
I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
duplicated sysfs link.
the detail mail:
https://lkml.org/lkml/2013/3/8/370
but it seems the problems has no conclusion. In our environment, we triggered
the bug too, but for error ENOENT:
we use 3.4 kernel,
On 2014/10/9 20:43, Weng Meiling wrote:
Hi guys,
I see the mails you discussed the BUG at fs/sysfs/group.c:65! triggered by
duplicated sysfs link.
the detail mail:
https://lkml.org/lkml/2013/3/8/370
but it seems the problems has no conclusion. In our environment, we triggered
On 2014/6/11 20:12, Jan Kara wrote:
> Hello,
>
> On Wed 11-06-14 16:19:12, Weng Meiling wrote:
>> We run vdbench test in our suse system with kernel 3.4, the vdbench test
>> is about different block size seq and rand read/write. Before the vdbench
> Hum, this looks
On 2014/6/11 20:12, Jan Kara wrote:
Hello,
On Wed 11-06-14 16:19:12, Weng Meiling wrote:
We run vdbench test in our suse system with kernel 3.4, the vdbench test
is about different block size seq and rand read/write. Before the vdbench
Hum, this looks like some relatively old
After patch commit 807592a4fafb("block: Let blk_drain_queue() caller
obtain the queue lock") the function blk_drain_queue() had been renamed
to __blk_drain_queue(), so correct the related comments.
Signed-off-by: Weng Meiling
---
block/blk-cgroup.c | 2 +-
block/blk-core.c
Please ignore the message, I forget to modify the SOB message.
Sorry for this.
Thanks!
Weng Meiling
On 2014/5/12 17:39, Weng Meiling wrote:
> After patch commit 807592a4fafb("block: Let blk_drain_queue() caller
> obtain the queue lock") the function blk_drain_queue()
After patch commit 807592a4fafb("block: Let blk_drain_queue() caller
obtain the queue lock") the function blk_drain_queue() had been renamed
to __blk_drain_queue(), so correct the related comments.
Signed-off-by: Qiang Huang
---
block/blk-cgroup.c | 2 +-
block/blk-core.c | 2 +-
After patch commit 807592a4fafb(block: Let blk_drain_queue() caller
obtain the queue lock) the function blk_drain_queue() had been renamed
to __blk_drain_queue(), so correct the related comments.
Signed-off-by: Qiang Huang h.huangqi...@huawei.com
---
block/blk-cgroup.c | 2 +-
Please ignore the message, I forget to modify the SOB message.
Sorry for this.
Thanks!
Weng Meiling
On 2014/5/12 17:39, Weng Meiling wrote:
After patch commit 807592a4fafb(block: Let blk_drain_queue() caller
obtain the queue lock) the function blk_drain_queue() had been renamed
After patch commit 807592a4fafb(block: Let blk_drain_queue() caller
obtain the queue lock) the function blk_drain_queue() had been renamed
to __blk_drain_queue(), so correct the related comments.
Signed-off-by: Weng Meiling wengmeiling.w...@huawei.com
---
block/blk-cgroup.c | 2 +-
block/blk
Hi Bruce , Stanislav
On 2014/2/18 6:19, J. Bruce Fields wrote:
> On Sat, Feb 15, 2014 at 09:51:20AM +0800, Weng Meiling wrote:
>> Hi Bruce,
>>
>> The upstream has merged your git tree for-3.14, but there is no this patch?
>> Do you forget this patch?
>
> Apol
Hi Bruce , Stanislav
On 2014/2/18 6:19, J. Bruce Fields wrote:
On Sat, Feb 15, 2014 at 09:51:20AM +0800, Weng Meiling wrote:
Hi Bruce,
The upstream has merged your git tree for-3.14, but there is no this patch?
Do you forget this patch?
Apologies, I'm not sure what happened.
Looking
On 2014/2/17 18:08, Will Deacon wrote:
> On Sat, Feb 15, 2014 at 02:41:09AM +0000, Weng Meiling wrote:
>> Hi Will,
>>
>> I test kernel with this patch, the problem has be fixed. When the
>> event's sample_period is small, the cpu will not stall except printing
>
On 2014/2/17 18:08, Will Deacon wrote:
On Sat, Feb 15, 2014 at 02:41:09AM +, Weng Meiling wrote:
Hi Will,
I test kernel with this patch, the problem has be fixed. When the
event's sample_period is small, the cpu will not stall except printing
warning oprofile: ignoring spurious
lease send a formal one? :) Thanks very much!
On 2014/2/11 23:52, Will Deacon wrote:
> On Tue, Feb 11, 2014 at 04:33:51AM +, Weng Meiling wrote:
>> Hi Will,
>
> Hello,
>
>>>>> how userland can be notified about throttling. Throttling could be
>>>>> wo
Hi Bruce,
The upstream has merged your git tree for-3.14, but there is no this patch?
Do you forget this patch?
Thanks!
Weng Meiling
On 2014/1/4 6:22, J. Bruce Fields wrote:
> On Mon, Dec 30, 2013 at 05:23:59PM +0300, Stanislav Kinsbursky wrote:
>> There could be a case, when NFSd fi
Hi Bruce,
The upstream has merged your git tree for-3.14, but there is no this patch?
Do you forget this patch?
Thanks!
Weng Meiling
On 2014/1/4 6:22, J. Bruce Fields wrote:
On Mon, Dec 30, 2013 at 05:23:59PM +0300, Stanislav Kinsbursky wrote:
There could be a case, when NFSd file system
one? :) Thanks very much!
On 2014/2/11 23:52, Will Deacon wrote:
On Tue, Feb 11, 2014 at 04:33:51AM +, Weng Meiling wrote:
Hi Will,
Hello,
how userland can be notified about throttling. Throttling could be
worth for operf too, not only for the oprofile kernel driver.
From a quick
rate which might be worth being implemented for ARM too.
>>
>> Are you referring to the perf_sample_event_took callback? If so, that
>> certainly looks worth persuing. I'll stick it on my list, thanks!
>>
Is there any progress on this work? Because this is important fo
referring to the perf_sample_event_took callback? If so, that
certainly looks worth persuing. I'll stick it on my list, thanks!
Is there any progress on this work? Because this is important for me.
Sorry for trouble you.
Thanks!
Weng Meiling
--
To unsubscribe from this list: send the line
mically
>> adjusts the rate which might be worth being implemented for ARM too.
>
> Are you referring to the perf_sample_event_took callback? If so, that
> certainly looks worth persuing. I'll stick it on my list, thanks!
>
Thanks Will for doing this.
Thanks
Weng Meiling
> Will
/1/16 9:09, Weng Meiling wrote:
>
> On 2014/1/15 18:24, Robert Richter wrote:
>> On 15.01.14 10:02:44, Weng Meiling wrote:
>>> On 2014/1/14 23:05, Robert Richter wrote:
>>>> @@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
>>>&
it?
On 2014/1/16 9:09, Weng Meiling wrote:
On 2014/1/15 18:24, Robert Richter wrote:
On 15.01.14 10:02:44, Weng Meiling wrote:
On 2014/1/14 23:05, Robert Richter wrote:
@@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
per_cpu(perf_events, cpu)[event] = pevent;
+ /* sync
to the perf_sample_event_took callback? If so, that
certainly looks worth persuing. I'll stick it on my list, thanks!
Thanks Will for doing this.
Thanks
Weng Meiling
Will
.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 2014/1/15 18:24, Robert Richter wrote:
> On 15.01.14 10:02:44, Weng Meiling wrote:
>> On 2014/1/14 23:05, Robert Richter wrote:
>>> @@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
>>>
>>> per_cpu(perf_events, cpu)[event] = peven
On 2014/1/15 18:24, Robert Richter wrote:
On 15.01.14 10:02:44, Weng Meiling wrote:
On 2014/1/14 23:05, Robert Richter wrote:
@@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
per_cpu(perf_events, cpu)[event] = pevent;
+ /* sync perf_events with overflow handler
On 2014/1/14 23:05, Robert Richter wrote:
> On 14.01.14 09:52:11, Weng Meiling wrote:
>> On 2014/1/13 16:45, Robert Richter wrote:
>>> On 20.12.13 15:49:01, Weng Meiling wrote:
>
>>>> The problem was once triggered on kernel 2.6.34, the main information:
>&
On 2014/1/14 23:05, Robert Richter wrote:
On 14.01.14 09:52:11, Weng Meiling wrote:
On 2014/1/13 16:45, Robert Richter wrote:
On 20.12.13 15:49:01, Weng Meiling wrote:
The problem was once triggered on kernel 2.6.34, the main information:
3BUG: soft lockup - CPU#0 stuck for 60005ms
On 2014/1/13 16:45, Robert Richter wrote:
> Weng,
>
> sorry for answering late, your mail hit the holiday season.
>
> On 20.12.13 15:49:01, Weng Meiling wrote:
>>
>> From: Weng Meiling
>>
>> There is a situation event is triggered before oprofile_pe
On 2014/1/13 16:45, Robert Richter wrote:
Weng,
sorry for answering late, your mail hit the holiday season.
On 20.12.13 15:49:01, Weng Meiling wrote:
From: Weng Meiling wengmeiling.w...@huawei.com
There is a situation event is triggered before oprofile_perf_start() finish.
Because
Hi Robert,
What do you think about this patch?
On 2013/12/20 15:49, Weng Meiling wrote:
>
> From: Weng Meiling
>
> There is a situation event is triggered before oprofile_perf_start() finish.
> Because the event is still not stored in per_cpu(perf_events, cpu)[event],
> o
Hi Robert,
What do you think about this patch?
On 2013/12/20 15:49, Weng Meiling wrote:
From: Weng Meiling wengmeiling.w...@huawei.com
There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in per_cpu(perf_events, cpu)[event
From: Weng Meiling
There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in per_cpu(perf_events, cpu)[event],
op_overflow_handler() will print the warning. During the time, if unregistered
event is triggered again, the cpu will print
From: Weng Meiling wengmeiling.w...@huawei.com
There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in per_cpu(perf_events, cpu)[event],
op_overflow_handler() will print the warning. During the time, if unregistered
event is triggered
From: Weng Meiling
Signed-off-by: Weng Meiling
---
include/linux/sunrpc/svc.h | 2 +-
net/sunrpc/xprtsock.c | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
index 6eecfc2..b6316423 100644
--- a/include
From: Weng Meiling wengmeiling.w...@huawei.com
Signed-off-by: Weng Meiling wengmeiling.w...@huawei.com
---
include/linux/sunrpc/svc.h | 2 +-
net/sunrpc/xprtsock.c | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc
On 2013/11/14 21:25, J. Bruce Fields wrote:
> On Thu, Nov 14, 2013 at 08:38:55PM +0800, Weng Meiling wrote:
>> On 2013/11/14 0:09, J. Bruce Fields wrote:
>>> On Fri, Nov 08, 2013 at 03:23:28PM +0800, Weng Meiling wrote:
>>>>
>>>> From: Weng Meiling
>&
On 2013/11/14 0:09, J. Bruce Fields wrote:
> On Fri, Nov 08, 2013 at 03:23:28PM +0800, Weng Meiling wrote:
>>
>> From: Weng Meiling
>
> I agree completely that a \n at the end would make more sense.
>
> Have you tested that this nfs-utils is OK with this change?
&
On 2013/11/14 0:09, J. Bruce Fields wrote:
On Fri, Nov 08, 2013 at 03:23:28PM +0800, Weng Meiling wrote:
From: Weng Meiling wengmeiling.w...@huawei.com
I agree completely that a \n at the end would make more sense.
Have you tested that this nfs-utils is OK with this change?
I suspect
On 2013/11/14 21:25, J. Bruce Fields wrote:
On Thu, Nov 14, 2013 at 08:38:55PM +0800, Weng Meiling wrote:
On 2013/11/14 0:09, J. Bruce Fields wrote:
On Fri, Nov 08, 2013 at 03:23:28PM +0800, Weng Meiling wrote:
From: Weng Meiling wengmeiling.w...@huawei.com
I agree completely that a \n
From: Weng Meiling
Signed-off-by: Weng Meiling
---
fs/nfsd/nfsctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index 7f55517..31db42c 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -188,7 +188,7 @@ static const struct
From: Weng Meiling
Signed-off-by: Weng Meiling
---
net/sunrpc/svc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index b974571..e7fbe36 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -1104,8 +1104,6 @@ svc_process_common(struct svc_rqst
From: Weng Meiling wengmeiling.w...@huawei.com
Signed-off-by: Weng Meiling wengmeiling.w...@huawei.com
---
fs/nfsd/nfsctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index 7f55517..31db42c 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd
From: Weng Meiling wengmeiling.w...@huawei.com
Signed-off-by: Weng Meiling wengmeiling.w...@huawei.com
---
net/sunrpc/svc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index b974571..e7fbe36 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
58 matches
Mail list logo