https://bugzilla.novell.com/show_bug.cgi?id=305162#c40 --- Comment #40 from Thomas Renninger <trenn@novell.com> 2007-09-25 08:38:19 MST --- Rafael, FYI: I know these Vaios have a broken lapic timer in deeper C-states. I expect the IPI timer broadcast setup which is a workaround for those in 10.2 is messed up in timer suspend functions by Thomas Gleissner's nohz/clocksource/whatever patches that came in some time ago. If I understood that right, they are still thinking about a right fix, which might be a modification where IPI broadcast timers break, I will post to lkml as soon as I find the time. The workaround for those Vaios to use IPI broadcast timer interrupts is located here(formerly AMDs where blacklisted to use IPI, I added Pentium Ms to 10.2 some time ago, but this fell out due to CLOCKSOURCE patches and if I read the code right all machines are now using IPI interrupts): 2.6.22 (drivers/acpi/processor_idle.c): #ifdef CONFIG_GENERIC_CLOCKEVENTS unsigned long reason; reason = pr->power.timer_broadcast_on_state < INT_MAX ? CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF; clockevents_notify(reason, &pr->id); #else This is just a guess, but I could imagine the clocksoure (or whatever) timer suspend functions are messing up the IPI broadcast timer setup somehow. Therefore the Sony Vaios take that long at suspend time (hitting keys should help to be quicker if this is the problem). With 10.2, without blacklisting those machines even booted very slow (nolapic or pressing keys (producing interrupts) helped). I haven't followed up the lkml thread, don't know whether this info is still needed. I will search for the thread if I find the time, but time for me is precious at the moment, maybe this helps a bit fixing up the root cause... Of course this is just a guess, it may be something else :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.