[ Eric, Ingo, can you double-check the timer initialization after resume? We appear to have several reports of date not advancing, and while this could be some SATA issue, it could easily be a timer tick issue too ] On Thu, 8 Mar 2007, Michael S. Tsirkin wrote: > > Here's the status with -rc3: better, but still does not work as well as 2.6.20. Ok. I think we mostly solved the irq-related stuff, but you might want to check whether you have CONFIG_NOHZ on or off and whether that makes a difference. > 2. First disk access after resume takes a couple of minutes > (seemed instant with 2.6.20) during this time no new messages show on console Yeah, there is some problem with SATA resume. It would be beautiful if the people who actually see this could narrow it down with bisection. "It works for me" is clearly the case for many people, but not all. But before blaming SATA, check if you have NO_HZ enabled and whether disabling that makes it work ok. If timeouts don't work right (or are *extremely* slow) things that should be instant won't be. > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows > after waiting for some 10 min, I rebooted. > no new messages showed up in /var/log/messages I think this is likely just more of the disk being buggered, but it could again be related to NO_HZ (people report time not advancing, and that would make any X timeout taking forever, and you'd see exactly your behaviour). Linus - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
