On Mon, 2007-03-05 at 02:50 +0100, Adrian Bunk wrote: > Subject : ThinkPad T60: system doesn't come out of suspend to RAM > (CONFIG_NO_HZ) > References : http://lkml.org/lkml/2007/2/22/391 > Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]> > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Ingo Molnar <[EMAIL PROTECTED]> > Status : unknown > > Subject : macbook pro suspend to ram broken (clockevents) > References : http://lkml.org/lkml/2007/3/4/110 > Submitter : Soeren Sonnenburg <[EMAIL PROTECTED]> > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > commit e9e2cdb412412326c4827fc78ba27f410d837e6e > Status : unknown
I can reproduce this on my dual core VAIO. There are some issues: 1) clockevents code needs probably a resume fix, which I'm working on 2) The BOGOMIPS calibration of CPU#1 after resume is completely hosed. CPU#1 has ~ 200000 Bogomips after resume, which is off by factor 500. BOGOMIPS is calibrated vs. jiffies, This was also observed by Ingo on his T60. This is similar to the LAPIC calibration problems I had seen before the LAPIC rework. IRQ#0 comes in extremly slow (probably caused by SMM crap, e.g. PS/2 keyboard emulation) 3) on suspend we shut down CPU#1 on dual core machines. resume restarts CPU#1. Now one would expect that acpi_processor_power_verify would be called, so that the "LAPIC/TSC stops in C3"-workaround gets applied to CPU#1. Len confirmed that it should be called, when the cpu is brought online. This was not noticed before as the old apic code kept the broadcast bit on cpu shutdown. Len, can you please look into #3 ? > Subject : dynticks makes ksoftirqd1 use unreasonable amount of cpu time > References : http://bugzilla.kernel.org/show_bug.cgi?id=8100 > Submitter : Emil Karlson <[EMAIL PROTECTED]> > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > Status : problem is being debugged Delayed until the above is sorted out. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/