[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070325085705.GB24225@mellanox.co.il>
Date: Sun, 25 Mar 2007 10:57:05 +0200
From: "Michael S. Tsirkin" <mst@....mellanox.co.il>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: "Michael S. Tsirkin" <mst@....mellanox.co.il>,
Adrian Bunk <bunk@...sta.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Soeren Sonnenburg <kernel@....de>, Ingo Molnar <mingo@...e.hu>,
Tejun Heo <htejun@...il.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
John Stultz <johnstul@...ibm.com>
Subject: Re: [4/5] 2.6.21-rc4: known regressions (v2)
> > - Without CONFIG_NO_HZ
> > I last tested this with cd05a1f818073a623455a58e756c5b419fc98db9.
> > After systems comes out of suspend to ram, I observed the following
> > behaviour (I used s2ram from console):
> > 1. The first disk access takes much longer than with 2.6.20
> > 2. System clock does not advance (date always reports the same time)
> > 3. After an attempt to switch to X, X starts drawing some windows and then hangs
> >
> > All 3 issues are new and did not occur under 2.6.20, so this is a regression.
> > Attached is a full dmesg from boot to resume.
>
> There is not much interesting to see in the log.
>
> Can you please test the following:
>
> Add "clocksource=acpi_pm" to the kernel commandline.
>
> If this does not change anything, then disable CONFIG_HPET and retry.
I have:
$ grep CONFIG_HPET .config
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_HPET is not set
so I think all these tests were done with CONFIG_HPET=n.
Given this, does it still make sense to test clocksource=acpi_pm?
I attach my .config for reference.
--
MST
View attachment ".config" of type "text/plain" (49251 bytes)
Powered by blists - more mailing lists