Messages in this thread | | | Subject | RE: Fixing MTRR smp breakage and suspending sysdevs. | Date | Wed, 27 Oct 2004 10:48:22 +0800 | From | "Li, Shaohua" <> |
| |
> >Hi! > >I've just had a go at fixing the issue with my implementation not >suspending the sysdevs (I believe swsusp does the same). In the process, >I reworked the MTRR support so it's not treated as a sysdev. Instead, >when we're saving cpu state, the mtrr_save function function is called. >When we go to restore CPU state, each CPU calls a function that resets >it's MTRRs and the 'main' cpu then frees the saved data. This is working >well here (did a dozen plus suspends on the trot), but I want to check >that it sounds like the right solution to you. > >Perhaps this method should be made more generic? (Are there likely to be >other per-cpu state savers needed?) > >One thing I have noticed is that by adding the sysdev suspend/resume >calls, I've gained a few seconds delay. I'll see if I can track down the >cause. Is the problem MTRR resume must be with IRQ enabled, right? Could we implement a method sysdev resume with IRQ enabled? MTRR driver isn't the only case. The ACPI Link device is another case, it's a sysdev (it must resume before any PCI device resumed), but its resume (it uses semaphore and non-atomic kmalloc) can't invoked with IRQ enabled. I guess cpufreq driver is another case when suspend/resume SMP is supported.
Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |