Re: [5/6] 2.6.21-rc2: known regressions

[Thomas Gleixner <tglx@linutronix.de>]

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 <mst@mellanox.co.il>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>              Ingo Molnar <mingo@elte.hu>
> Status     : unknown
> 
> Subject    : macbook pro suspend to ram broken  (clockevents)
> References : http://lkml.org/lkml/2007/3/4/110
> Submitter  : Soeren Sonnenburg <kernel@nn7.de>
> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
>              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 <jkarlson@cc.hut.fi>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

Delayed until the above is sorted out.

	tglx