Hi. On Sat, Dec 13, 2008 at 5:33 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.27. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12155 > Subject : Regression in 2.6.28-rc and 2.6.27-stable - hibernate related > Submitter : Fabio Comolli <fabio.comolli@xxxxxxxxx> > Date : 2008-11-23 16:17 (21 days old) > References : http://marc.info/?l=linux-kernel&m=122745709926361&w=4 Still present. It has been bisected to: --------------------------------------------------------------------------------------------------------------- commit 5e55aa8db085dad1aabb4574c73c23c7ae571e7b Author: Dave Kleikamp <shaggy@xxxxxxxxxxxxxxxxxx> Date: Sun Oct 26 18:20:14 2008 -0400 sched_clock: prevent scd->clock from moving backwards commit 5b7dba4ff834259a5623e03a565748704a8fe449 upstream sched_clock: prevent scd->clock from moving backwards When sched_clock_cpu() couples the clocks between two cpus, it may increment scd->clock beyond the GTOD tick window that __update_sched_clock() uses to clamp the clock. A later call to __update_sched_clock() may move the clock back to scd->tick_gtod + TICK_NSEC, violating the clock's monotonic property. This patch ensures that scd->clock will not be set backward. Signed-off-by: Dave Kleikamp <shaggy@xxxxxxxxxxxxxxxxxx> Acked-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> Signed-off-by: Ingo Molnar <mingo@xxxxxxx> Cc: Chuck Ebbert <cebbert@xxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx> ------------------------------------------------------------------------------------------------------------ Both 2.6.27.8 and 2.6.28-rc8 with that commit reverted work fine (well, at least they failed to show the bug so far). -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
