On Thursday, September 06, 2012, Daniel Lezcano wrote:
On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
On Thursday, September 06, 2012, Daniel Lezcano wrote:
On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
On Friday, August 31, 2012, Daniel Lezcano wrote: > On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote: >> On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote: >>> Remove the power field as it is not used. >>> >>> Signed-off-by: Daniel Lezcano daniel.lezcano@linaro.org >>> Cc: Konrad Rzeszutek Wilk konrad.wilk@oracle.com >> Acked. > Hi Rafael, > > I did not see this patch going in. Is it possible to merge it ? I think so. I'll take care of it when I get back from LinuxCon/Plumbers Conf. (early next week).
Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
Thanks Rafael.
Are there any other patches you want me to consider for v3.7?
Yes please, I have the per cpu latencies ready to be submitted but I want to do extra testing before. Unfortunately, the linux-pm-next hangs at boot time on my intel dual core (not related to the patchset).
I am git bisecting right now.
I found the culprit. This is not related to the linux-pm tree but with net-next. The following patch introduced the issue.
commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d Author: Amerigo Wang amwang@redhat.com Date: Fri Aug 10 01:24:50 2012 +0000
netpoll: re-enable irq in poll_napi()
napi->poll() needs IRQ enabled, so we have to re-enable IRQ before calling it. Cc: David Miller davem@davemloft.net Signed-off-by: Cong Wang amwang@redhat.com Signed-off-by: David S. Miller davem@davemloft.net
AFAICS, it has been fixed by commit 072a9c48600409d72aeb0d5b29fbb75861a06631 which is not yet in linux-pm-next.
If it is present in the current Linus' tree, you can just pull this one and merge linux-pm-next into it. It should merge without conflicts.
Ok, thanks.
I fall into this issue because NETCONSOLE is set, disabling it allowed me to go further.
Unfortunately I am facing to some random freeze on the system which seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
Disabling one of them, make the freezes to disappear.
Is it a known issue ?
Well, there are systems having problems with this configuration, but they should be exceptional. What system is that?
It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I believe. Maybe someone got the same issue ?
Is it a regression for you?