[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20070326141938.GC6661@mellanox.co.il>
Date: Mon, 26 Mar 2007 16:19:52 +0200
From: "Michael S. Tsirkin" <mst@....mellanox.co.il>
To: "Michael S. Tsirkin" <mst@....mellanox.co.il>
Cc: Thomas Gleixner <tglx@...utronix.de>, 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)
Update: I tested 2.6.21-rc5 with the following settings
# CONFIG_NO_HZ is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_HPET is not set
1. Without additional kernel options
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.
2. Setting clocksource=acpi_pm
After resume from RAM
1. The first disk access takes much longer than with 2.6.20
2. System clock seems to advance properly
3. After an attempt to switch to X, X works correctly
So it seems that clocksource=acpi_pm can be used as a work-around.
What does this tell us?
I'm also not happy with how clocksource=acpi_pm performs -
the system seems to be jerky, stalling for fractions of
seconds now and them.
TODO: test without CONFIG_HPET_TIMER.
--
MST
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists