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 me some o
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&#
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
k, &dev->class->p->glue_dirs.list, entry)
kobj_kset_leave(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
---
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
>>
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:
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, a
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
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() had b
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 +-
inclu
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
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
u please 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
>>>>&g
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
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
that dynamically
>> 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
t do you
think about 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_counte
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/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/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_perf_
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
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
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
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?
&
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
29 matches
Mail list logo
