On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote: > > > I haven't had the time to check if any special command line arguments > > > help. > > > Will check tomorrow. > > > > Can you please disable the patches, which I sent Linus wards: > > > > timekeeping-access-rtc-outside-xtime-lock.patch > > xtime-supsend-resume-fixup.patch > > acpi-reevaluate-c-p-t-states.patch > > clockevents-enforce-broadcast-on-resume.patch > > clockevents-do-not-shutdown-broadcast-device-in-oneshot-mode.patch > > clockevents-prevent-stale-tick-update-on-offline-cpu.patch > > I have skipped all of them, but the resulting kernel behaves in the same > way (ie. doesn't boot). > > > Without those patches you get the state of rc4-mm1. It would be > > interesting to know which one interferes with the acpi stuff. > > It looks like something else went in between -rc4 and -rc6 that broke your > patch. I wonder what it might be ...
Hmm. Can you please go back in the -hrt project history: http://tglx.de/projects/hrtimers/2.6.23-rc5/patch-2.6.23-rc5-hrt1.patches.tar.bz2 http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2 Also, can you send me your .config file please ? Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2: I'm still fishing in rather dark water. Depending on the added instrumentation points the problem mutates up to the point where it vanishes completely. The hang, which requires key strokes again, happens consistently at the same place: The notifier call in kernel/cpu.c::_cpu_up() ret = __raw_notifier_call_chain(&cpu_chain, CPU_UP_PREPARE | mod, hcpu, -1, &nr_calls); does not return, but _all_ registered notifiers are called and reach their return statement. This reminds me on: http://lkml.org/lkml/2007/5/9/46 Sigh. I have no clue where to dig further. 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/
