-Original Message-
From: Siddha, Suresh B
Sent: Tuesday, October 30, 2012 4:24 AM
To: Liu, Chuansheng
Cc: mi...@redhat.com; h...@zytor.com; t...@linutronix.de;
ying...@kernel.org; x...@kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/ioapic: Fix the vector_irq
-Original Message-
From: Peter Zijlstra [mailto:a.p.zijls...@chello.nl]
Sent: Monday, October 29, 2012 5:06 PM
To: Liu, Chuansheng
Cc: t...@linutronix.de; mi...@kernel.org; linux-kernel@vger.kernel.org; Li,
Fei;
yanmin_zh...@linux.intel.com
Subject: Re: [PATCH] hrtimer: Printing
-Original Message-
From: Oliver Neukum [mailto:oneu...@suse.de]
Sent: Wednesday, October 31, 2012 5:03 PM
To: Liu, Chuansheng
Cc: john.stu...@linaro.org; t...@linutronix.de; gre...@linuxfoundation.org;
linux-kernel@vger.kernel.org; Liu, Chuansheng
Subject: Re: [PATCH 1/3
completely pointless to have a lock in alarmtimer_get_rtcdev() at all.
So this patch remove the lock/unlock actions in alarmtimer_get_rtcdev().
Signed-off-by: liu chuansheng chuansheng@intel.com
---
kernel/time/alarmtimer.c | 21 +++--
1 files changed, 7 insertions(+), 14
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Friday, November 02, 2012 6:56 AM
To: Liu, Chuansheng
Cc: john.stu...@linaro.org; gre...@linuxfoundation.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] alarmtimer: Using
(parent-p-mutex);
But also the mutex parent-p-mutex has protected the add_dev()
callback.
So here removing the lock of rtcdev_lock.
Signed-off-by: liu chuansheng chuansheng@intel.com
---
kernel/time/alarmtimer.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git
+ } else if (cpumask_test_cpu(cpu, data-affinity))
+ cpumask_clear_cpu(cpu, data-affinity);
You meant to use 'affinity' (instead of data-affinity) in the above 2
statements
right? Note that we do chip-irq_set_affinity(data, affinity, true); further
down.
Btw, on a slightly different note, I'm also rather surprised that the above
code doesn't care about the return value of chip-irq_set_affinity() ..
Shouldn't we warn if that fails?
It seems another case when irq_set_affinity is NULL whenever affinity is
changed or not before that,
For this
Shouldn't we warn if that fails?
printk(Cannot set affinity for irq %i\n, irq);
This is the warning when set affinity failed.
In that case, we would end up with an incorrect data-affinity right?
Moving the clean cpu mask code into if (chip-irq_set_affinity)?
Will resend the patch and will judge the chip-irq_set_affinity(data, affinity,
true)
return value.
I know.. What I meant is, the code warns only if chip-irq_set_affinity
is NULL and doesn't care if chip-irq_set_affinity was not NULL and
the function failed to set the affinity (ie., when chip-irq_set_affinity()
returns error). In other words, I meant to say that this is one more
case where
Please hold on.. I'm not yet done reviewing, I might have more comments :-)
Sure, welcome, thanks again.
A return value of 0 and 1 are acceptable. So this check isn't correct.
Regards,
Srivatsa S. Bhat
Which case value 1 is acceptable, could you share? Thanks.
OMG, why did you drop the other hunk which cleared the cpu *before*
invoking -irq_set_affinity()? IMO, altering irq affinity
-Original Message-
From: Ming Lei [mailto:ming@canonical.com]
Sent: Wednesday, November 07, 2012 6:40 PM
To: Liu, Chuansheng
Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] firmware loader: Fix the race FW_STATUS_DONE is
followed
-Original Message-
From: Ming Lei [mailto:ming@canonical.com]
Sent: Thursday, November 08, 2012 10:02 AM
To: Liu, Chuansheng
Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] firmware loader: Fix the race FW_STATUS_DONE is
followed
-Original Message-
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
Sent: Friday, October 19, 2012 2:11 PM
To: Liu, Chuansheng
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; Siddha, Suresh B;
mathias.ny...@linux.intel.com; linux-kernel
-Original Message-
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
impossible !
where is the irq_desc coming from. ?
Any other chip can call function irq_alloc_descs/irq_alloc_desc() to get
irq_desc,
and other chip can has their own chip data.
One suggestion below, thanks.
-Original Message-
From: Siddha, Suresh B
Sent: Thursday, September 27, 2012 6:46 AM
To: Srivatsa S. Bhat
Cc: Liu, Chuansheng; t...@linutronix.de; mi...@redhat.com; x...@kernel.org;
linux-kernel@vger.kernel.org; yanmin_zh...@linux.intel.com; Paul E
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Friday, October 12, 2012 8:32 PM
To: Liu, Chuansheng
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
thread
On Fri, 12 Oct 2012, Chuansheng
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Friday, October 12, 2012 8:46 PM
To: Liu, Chuansheng
Cc: linux-kernel@vger.kernel.org
Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
thread
On Fri, 12 Oct 2012, Liu
FLAG IRQS_ONESHOT does not work well for edge interrupt.
* IRQS_ONESHOT - irq is not unmasked in primary handler
Is it possible give some notification or remind? Thanks. I took some time
to know it:)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
, Chuansheng
Cc: linux-kernel@vger.kernel.org
Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
thread
On Fri, 12 Oct 2012, Liu, Chuansheng wrote:
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Friday, October 12, 2012 8:46 PM
On SMP an interrupt which is raised after the ack() again before the
handler finishes, can invoke another delivery on a different CPU,
which then sees the IRQ_INPROGESS flag, masks it and flags it
PENDING. When the primary handler on the first CPU returns, it sees
the PENDING flag, unmasks
-Original Message-
From: anish kumar [mailto:anish198519851...@gmail.com]
Sent: Friday, October 12, 2012 11:25 PM
To: Liu, Chuansheng
Cc: Thomas Gleixner; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
thread
On Fri
$./scripts/checkpatch.pl
ERROR: space required before the open parenthesis '('
#97: FILE: drivers/base/firmware_class.c:267:
+ if(!kref_put(buf-ref, __fw_free_buf))
+ spin_unlock(fwc-lock);
}
/* direct firmware loading support */
After fixing the patch style
The first bad commit is:
commit 73d4066055e0e2830533041f4b91df8e6e5976ff
Author: Chuansheng Liu chuansheng@intel.com
Date: Tue Sep 11 16:00:30 2012 +0800
USB/host: Cleanup unneccessary irq disable code
Because the IRQF_DISABLED as the flag is now a NOOP and has been
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Tuesday, November 13, 2012 3:32 AM
To: Martin Steigerwald
Cc: Liu, Chuansheng; linux-kernel@vger.kernel.org; Ingo Molnar; Greg
Kroah-Hartman
Subject: Re: [REGRESSION] 3.7-rc3+git hard lockup on CPU after
-Original Message-
From: Wolfram Sang [mailto:w.s...@pengutronix.de]
Sent: Tuesday, November 13, 2012 1:27 AM
To: Liu, Chuansheng
Cc: linus.wall...@linaro.org; linux-arm-ker...@lists.infradead.org;
linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
Subject: Re: [PATCH 1/7
-Original Message-
From: Wolfram Sang [mailto:w.s...@pengutronix.de]
Sent: Tuesday, November 13, 2012 3:58 PM
To: Liu, Chuansheng
Cc: linus.wall...@linaro.org; linux-arm-ker...@lists.infradead.org;
linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
Subject: Re: [PATCH 1/7
-Original Message-
From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
Yinghai Lu
Sent: Wednesday, October 17, 2012 10:03 AM
To: Liu, Chuansheng
Cc: t...@linutronix.de; mi...@redhat.com; Siddha, Suresh B;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86
Hi Sasha,
-Original Message-
From: Sasha Levin [mailto:sasha.le...@oracle.com]
Sent: Friday, April 19, 2013 5:06 AM
To: Liu, Chuansheng; Andrew Morton
Cc: Ingo Molnar; Thomas Gleixner; Peter Zijlstra; Wu, Fengguang;
eag0...@gmail.com; Dave Jones; linux-kernel@vger.kernel.org
Hi Mark,
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: Wednesday, April 10, 2013 8:30 PM
To: Liu, Chuansheng
Cc: sa...@linux.intel.com; linux-kernel@vger.kernel.org;
patc...@opensource.wolfsonmicro.com
Subject: Re: mfd, arizona: Fix
Hello Thomas,
Sorry to miss the V2 in the subject.
I have updated the comments in this new patch, could you consider to take it
into upstream?
Thanks.
Best Regards
Liu chuansheng
-Original Message-
From: Liu, Chuansheng
Sent: Tuesday, March 12, 2013 5:58 PM
To: t...@linutronix.de
, 2013 3:20 AM
To: Liu, Chuansheng
Cc: Li, Fei; r...@sisk.pl; a...@linux-foundation.org;
linux-kernel@vger.kernel.org; ldewan...@nvidia.com
Subject: Re: [PATCH] pm: print the name of failed suspend function for
platform
device
On Mon, Mar 11, 2013 at 01:41:28AM +, Liu, Chuansheng wrote
-Original Message-
From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
Sent: Saturday, March 09, 2013 11:00 AM
To: Liu, Chuansheng
Cc: l...@kernel.org; Brown, Len; linux...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] intel_idle: Removing
Hi Greg,
I just noticed some other cases need the more log also.
https://lkml.org/lkml/2013/3/8/71
Could you consider the below patch, thanks?
Best Regards
Liu chuansheng
-Original Message-
From: Li, Fei
Sent: Tuesday, February 05, 2013 1:13 PM
To: gre...@linuxfoundation.org; r
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Tuesday, March 12, 2013 5:24 AM
To: Liu, Chuansheng
Cc: mi...@redhat.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] genirq: Do not consider the irqs with disabling and
IRQF_NO_SUSPEND
On Tue
-Original Message-
From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
Sent: Thursday, March 07, 2013 5:49 PM
To: Liu, Chuansheng
Cc: l...@kernel.org; Brown, Len; linux...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] intel_idle: set the state_tables array
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Monday, February 04, 2013 11:16 AM
To: Li, Fei
Cc: Rafael J. Wysocki; a...@linux-foundation.org;
linux-kernel@vger.kernel.org; linux...@vger.kernel.org; Liu, Chuansheng
Subject: RE: [PATCH V4] suspend
-#define TIMEOUT(20 * HZ)
+unsigned int __read_mostly sys_freeze_process_timeout_msecs =
2;
2 does not mean 20 seconds since we can select HZ other than
1000.
So (20 * HZ) is better than 2.
[Li, Fei]
Are you sure about this, (20*HZ) better than 2, or you mean
Hi,
Just found some comments as below:
In commit 0beefa208bb3a9e581a60125703
+ /*
+* The switch back from broadcast mode needs to be
+* called with interrupts disabled.
+*/
+local_irq_disable();
+
management to behave correctly, call
pm_runtime_put(_sync) in such case.
Signed-off-by Liu Chuansheng chuansheng@intel.com
Signed-off-by: Li Fei fei...@intel.com
---
drivers/usb/core/hub.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core
-Original Message-
From: Rafael J. Wysocki [mailto:r...@sisk.pl]
Sent: Friday, March 01, 2013 8:51 AM
To: Liu, Chuansheng
Cc: Alan Stern; Li, Fei; gre...@linuxfoundation.org; Lan, Tianyu;
sarah.a.sh...@linux.intel.com; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org
-Original Message-
From: Li, Fei
Sent: Thursday, February 28, 2013 5:06 PM
To: gre...@linuxfoundation.org; Lan, Tianyu; st...@rowland.harvard.edu;
sarah.a.sh...@linux.intel.com
Cc: r...@sisk.pl; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
Liu,
Chuansheng; Li, Fei
-Original Message-
From: Rafael J. Wysocki [mailto:r...@sisk.pl]
Sent: Friday, March 01, 2013 10:22 AM
To: Liu, Chuansheng
Cc: Li, Fei; gre...@linuxfoundation.org; Lan, Tianyu;
st...@rowland.harvard.edu; sarah.a.sh...@linux.intel.com;
linux-...@vger.kernel.org; linux-kernel
-Original Message-
From: Lai Jiangshan [mailto:eag0...@gmail.com]
Sent: Wednesday, February 27, 2013 10:51 PM
To: Liu, Chuansheng
Cc: mi...@kernel.org; pet...@infradead.org; jbeul...@suse.com;
paul...@linux.vnet.ibm.com; a...@linux-foundation.org;
min...@mina86.org; srivatsa.b
Thanks Samuel and Linus' help.
-Original Message-
From: Samuel Ortiz [mailto:sa...@linux.intel.com]
Sent: Tuesday, January 22, 2013 8:37 AM
To: Liu, Chuansheng
Cc: Peter Ujfalusi; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
torva...@linux-foundation.org; Omar Ramirez
...@linux-foundation.org;
a...@linux-foundation.org; t...@linutronix.de; Wu, Fengguang; Liu,
Chuansheng
Subject: [tip:core/locking] Revert smp: Give WARN()ing if in_interrupt() when
calling smp_call_function_many()/single()
Commit-ID: 56624143151fdb84c32a43463864e6c12a5ebcfc
Gitweb:
http
-Original Message-
From: Wu, Fengguang
Sent: Wednesday, February 20, 2013 9:07 AM
To: Andrew Morton
Cc: Liu, Chuansheng; mi...@kernel.org; pet...@infradead.org;
jbeul...@suse.com; paul...@linux.vnet.ibm.com; min...@mina86.org;
srivatsa.b...@linux.vnet.ibm.com; linux-kernel
This patch is corrupted and can not be applied at all. Please fix your email
client and try again.
greg k-h
I am very sorry to waste your time, resend it again.
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
Because
This possibly ought to be submitted in parallel with the code that uses it so
that
the whole proposal can be evaluated as one thing ?
Alan
Patch is here, thanks.
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs
For a kms drm driver (and tbh, doing a non-kms driver today is not a great
idea),
there's no reason to use the drm_irq_install/_unistall helpers.
Can not understand well, I found many GPU drivers are using drm_irq helpers'
function, including ours:)
--
To unsubscribe from this list: send
Well, you cant use the pre_install/post_install hooks the drm_irq code
provides,
but yes, just do the request_irq in your driver code at the right time, with
the
right parameters. Much easier than adding code to a part of the drm core
fraught with backwards-compat stuff no one really wants
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
Why is this in the patch?
Please resend it in a format that I do not have to manually edit the patch.
greg k-h
Thanks your teaching, resend again.
Because the IRQF_DISABLED
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();
Signed-off-by: liu
Hi all,
Could some one give help that removing the local_irq_enable() in function
panic()?
Currently I meet one case that when panic happening at irq disabling state with
spin_lock,
After panic() is called, due to local_irq_enable() is called, it causes some
interrupts come,
and cause more
-Original Message-
From: Liu, Chuansheng
Sent: Friday, September 07, 2012 5:20 PM
To: gre...@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH RESEND] USB/host: Cleanup unneccessary irq disable code
Because the IRQF_DISABLED as the flag is now a NOOP and has
Signed-off-by: liu chuansheng chuansheng@intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/hcd.c | 15 ---
drivers/usb/host/ehci-ls1x.c |2 +-
drivers/usb/host/ohci-xls.c |2 +-
3 files changed, 2 insertions(+), 17
if irq handler and irq thread use the
same spin lock.
-Original Message-
From: anish singh [mailto:anish198519851...@gmail.com]
Sent: Tuesday, September 18, 2012 12:31 PM
To: Liu, Chuansheng
Subject: Re: [PATCH] genirq: Add the IRQS_ONESHOT support for edge interrupt
On Tue, Sep
Are you sure you have not returned from the irq_thread and how do you
know that primary handler is called in between when your irq_thread is
running?
I am sure because the spin recursive locks has been printed with call stack,
further more, with IRQS_ONESHOT, I have printed the value of
This comment might help.
kernel/irq/manage.c
} else if (new-handler == irq_default_primary_handler) {
/*
* The interrupt was requested with handler = NULL, so
* we use the default primary handler for it. But it
* does not have the oneshot flag set.
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] drm: Adding the option IRQ_ONESHOT to support irq oneshot
For some platforms, we want the irq is handled as one shot,
then even when we use the irq thread, with this option, the new
irq will come until the irq thread finished.
So we
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag
This patch is for introducing the irq thread support in drm_irq.
Why we need irq thread in drm_irq code?
In our GPU system, the gpu interrupt handler need some time even 1ms to
finish,
in that case, the whole system will stay in irq disable status. One case is:
when audio is playing, it
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the irq handler need 1ms to handle the irq action.
And it will delay the whole system irq handler.
This patch is adding the irq thread support, it will make the drm_irq
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] x86_dump_trace: avoiding endless IRQ is printed
Found the case that endless IRQ printing in dump_trace,
and no real meaningful stack traces are output, so there should
one rare case that possibly context-previous_esp = context
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] x86/fixup_irq: using the cpu_online_mask instead of
cpu_all_mask
When one CPU is going down, and this CPU is the last one in irq affinity,
current code is setting cpu_all_mask as the new affinity for that irq.
But for some system
The endless IRQ is as below:
...
[ 82.215244,0] IRQ
[ 82.215399,0] IRQ
[ 82.215554,0] IRQ
[ 82.215710,0] IRQ
[ 82.215865,0] IRQ
[ 82.216022,0] IRQ
[ 82.216178,0] IRQ
[ 82.216333,0] IRQ
[ 82.216488,0] IRQ
[ 82.216643,0] IRQ
[ 82.216798,0] IRQ
[
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] x86_dump_trace: avoiding endless IRQ is printed
Found the case that endless IRQ printing in dump_trace,
and no real meaningful stack traces are output, so there should
be one rare case that possibly context-previous_esp = context
.
-Original Message-
From: Gross, Mark
Sent: Monday, August 27, 2012 11:50 PM
To: Liu, Chuansheng; 'linux-kernel@vger.kernel.org'
(linux-kernel@vger.kernel.org)
Cc: h...@linux.intel.com; a...@linux.intel.com; Pan, Jacob jun
Subject: RE: [PATCH RESEND] x86_dump_trace: avoiding endless IRQ
Sorry, I found the latest kernel code has some difference with my analysis.
I need more thoughts, then update this issue.
-Original Message-
From: Wolfram Sang [mailto:w.s...@pengutronix.de]
Sent: Monday, July 09, 2012 9:32 PM
To: Liu, Chuansheng
Cc: linux-kernel@vger.kernel.org
-Original Message-
From: Don Zickus [mailto:dzic...@redhat.com]
Sent: Tuesday, November 27, 2012 4:09 AM
To: Liu, Chuansheng
Cc: a...@linux-foundation.org; mi...@kernel.org; r...@sisk.pl;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] watchdog: optimizing the hrtimer interval
It seems like a better approach would be to adjust the timer somehow when
you change c-states. The whole point of the hard and softlockup is to
detect if scheduled code is either deadlock or hogging the cpu for too long.
If the cpu is in a deep sleep, then nothing is running, right? Which
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: Wednesday, December 19, 2012 5:11 PM
To: Liu, Chuansheng
Cc: l...@ti.com; pe...@perex.cz; ti...@suse.de; alsa-de...@alsa-project.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: dapm
-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
Sent: Thursday, December 20, 2012 9:51 PM
To: Liu, Chuansheng
Cc: l...@ti.com; pe...@perex.cz; ti...@suse.de; alsa-de...@alsa-project.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: dapm
-Original Message-
From: Gustavo Padovan [mailto:gust...@padovan.org]
Sent: Friday, January 04, 2013 6:03 AM
To: Liu, Chuansheng
Cc: mar...@holtmann.org; johan.hedb...@gmail.com;
linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: fix
Hi Thomas and Ingo,
Could you have a look for this patch? It fix the wrong unmask action.
Thanks.
-Original Message-
From: Liu, Chuansheng
Sent: Thursday, November 15, 2012 12:53 AM
To: mi...@redhat.com; t...@linutronix.de
Cc: x...@kernel.org; linux-kernel@vger.kernel.org; Liu
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Saturday, November 17, 2012 3:33 AM
To: Liu, Chuansheng
Cc: Chris Ball; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc,sdio: Fix the panic due to devname NULL when
calling
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Monday, November 19, 2012 3:47 PM
To: Liu, Chuansheng
Cc: Chris Ball; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc,sdio: Fix the panic due to devname NULL when
calling
-Original Message-
From: Colin Cross [mailto:ccr...@android.com]
Sent: Thursday, January 10, 2013 9:58 AM
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton; Don Zickus; Ingo Molnar; Thomas Gleixner; Liu,
Chuansheng; linux-arm-ker...@lists.infradead.org; Colin Cross
Subject
-Original Message-
From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of Colin
Cross
Sent: Friday, January 11, 2013 1:34 PM
To: Liu, Chuansheng
Cc: linux-kernel@vger.kernel.org; Andrew Morton; Don Zickus; Ingo Molnar;
Thomas Gleixner; linux-arm-ker...@lists.infradead.org
-Original Message-
From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of Colin
Cross
Sent: Friday, January 11, 2013 2:18 PM
To: Liu, Chuansheng
Cc: linux-kernel@vger.kernel.org; Andrew Morton; Don Zickus; Ingo Molnar;
Thomas Gleixner; linux-arm-ker...@lists.infradead.org
Hi maintainers,
Could you help to push this patch?
Every time syncing the latest code, always meet this build error.
Sorry to disturb.
-Original Message-
From: Peter Ujfalusi [mailto:peter.ujfal...@ti.com]
Sent: Monday, December 31, 2012 6:04 PM
To: Liu, Chuansheng
Cc: sa
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Monday, January 14, 2013 7:16 PM
To: Liu, Chuansheng
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] genirq: Give warning when setup an already-setup
non-shared irq
On Thu, 10 Jan 2013, Chuansheng
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Monday, January 14, 2013 11:30 PM
To: Rafael J. Wysocki
Cc: Liu, Chuansheng; linux...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PM / Runtime: Fix the twice judgement
Hi Gustavo,
-Original Message-
From: Gustavo Padovan [mailto:gust...@padovan.org]
Sent: Thursday, January 10, 2013 4:35 AM
To: Liu, Chuansheng
Cc: mar...@holtmann.org; johan.hedb...@gmail.com;
linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH
-Original Message-
From: Bi, Chao
Sent: Thursday, January 10, 2013 4:27 PM
To: a...@linux.intel.com; gre...@linuxfoundation.org;
a...@linux-foundation.org; pavan_sa...@ti.com
Cc: Liu, Chuansheng; linux-kernel@vger.kernel.org
Subject: [PATCH] ST_CORE: Error triggered by convert
Hello Al and Eric,
Thanks your comments, please see the below comments.
-Original Message-
From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
Sent: Monday, August 26, 2013 7:30 PM
To: Liu, Chuansheng
Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
Thanks Al.
-Original Message-
From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
Sent: Tuesday, August 27, 2013 8:43 AM
To: Liu, Chuansheng
Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix the race between the fget
-Original Message-
From: Robin Holt [mailto:robinmh...@linux.com]
Sent: Monday, September 09, 2013 11:07 PM
To: Liu, Chuansheng
Cc: mi...@kernel.org; h...@sgi.com; h...@zytor.com;
rmk+ker...@arm.linux.org.uk; r...@sgi.com; a...@linux-foundation.org;
linux-kernel@vger.kernel.org
Hello Rafael,
-Original Message-
From: Rafael J. Wysocki [mailto:r...@sisk.pl]
Sent: Wednesday, September 11, 2013 8:37 PM
To: Liu, Chuansheng
Cc: l...@kernel.org; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
Li, Zhuangzhi; Li, Fei
Subject: Re: [PATCH] ACPI / osl
Hello Greg,
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Wednesday, November 06, 2013 4:59 PM
To: Liu, Chuansheng
Cc: dmitry.torok...@gmail.com; t...@kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] devres: Freeing the drs after all release
-Original Message-
From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of t...@kernel.org
Sent: Thursday, November 07, 2013 8:30 AM
To: Liu, Chuansheng
Cc: Greg KH; dmitry.torok...@gmail.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] devres: Freeing the drs after all
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Thursday, November 07, 2013 8:47 AM
To: Liu, Chuansheng
Cc: t...@kernel.org; Greg KH; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] devres: Freeing the drs after all release() are called
On Thu
Hello,
-Original Message-
From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of t...@kernel.org
Sent: Thursday, November 07, 2013 8:52 AM
To: Liu, Chuansheng
Cc: Greg KH; dmitry.torok...@gmail.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] devres: Freeing the drs after all
-Original Message-
From: Joe Perches [mailto:j...@perches.com]
Sent: Wednesday, September 18, 2013 12:24 AM
To: Liu, Chuansheng
Cc: t...@kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ahci: Changing two module params with static
Hello Steven,
-Original Message-
From: Steven Rostedt [mailto:rost...@goodmis.org]
Sent: Wednesday, October 16, 2013 12:40 AM
To: Liu, Chuansheng
Cc: Ingo Molnar (mi...@kernel.org); h...@zytor.com; fweis...@gmail.com;
a...@linux-foundation.org; paul...@linux.vnet.ibm.com; Peter
Hello Steven,
-Original Message-
From: Steven Rostedt [mailto:rost...@goodmis.org]
Sent: Wednesday, October 16, 2013 10:08 AM
To: Liu, Chuansheng
Cc: Ingo Molnar (mi...@kernel.org); h...@zytor.com; fweis...@gmail.com;
a...@linux-foundation.org; paul...@linux.vnet.ibm.com; Peter
; x...@kernel.org; Wang,
Xiaoming; Li, Zhuangzhi; Liu, Chuansheng
Subject: Re: [PATCH] x86: Remove WARN_ON(in_nmi()) from vmalloc_fault
* Steven Rostedt rost...@goodmis.org wrote:
On Wed, 16 Oct 2013 08:11:18 +0200
Ingo Molnar mi...@kernel.org wrote:
* Steven Rostedt rost
Hit the below warning when enabling the CONFIG_DEBUG_LOCK_ALLOC,
__fuse_request_send ==
request_wait_answer ==
wait_event_freezable ==
try_to_freeze()
But here the inode-i_mutex is hold yet in vfs_readdir().
Could anyone give some help? Thanks.
[ 3148.552435] Freezing user space processes
1 - 100 of 313 matches
Mail list logo
