Messages in this thread | | | Subject | RE: Fixing MTRR smp breakage and suspending sysdevs. | Date | Thu, 28 Oct 2004 10:40:37 +0800 | From | "Li, Shaohua" <> |
| |
>> >>> >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 >> >>MTRR does not deserve to be sysdev. It is not essential for the >>system, it only makes it slow. >> >>> 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. >> >>I do not see how enabling interrupts before setting up IRQs is good >>idea. >> >>What about this one, instead? >> >>* ACPI Link device should allocate with GFP_ATOMIC >> >>* during suspend, locks can't be taken. (We stop userland, etc). So it >>should be okay to down_trylock() and panic if that does not work. > > >Actually, I am trying another approach for Link Device. > >- Temporarily enable interrupts during Link Device resume. Turn off all the >external interrupts at suspend time. They will remain suspended until >interrupt device resumes. > >Something like the patch below. Only part I don't like is controlling the >resume order by Makefiles and the link order. Probably we can fix that by >sorting the sysdev list at the boottime, depending on our ordering >requirements. I think, the resume order we need to maintain is something >like this: irqrouter, pit/timer, i8259, lapic, ioapic, others
Turn off PIC/IOAPIC in suspend time doesn't mean the PIC/IOAPIC is disabled in resume. BIOS possibly turns them on in resume.
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/
| |