Messages in this thread | | | Date | Tue, 26 Apr 2005 11:39:39 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH] PCI: Add pci shutdown ability |
| |
On Po 25-04-05 18:13:27, Dave Jones wrote: > On Mon, Apr 25, 2005 at 02:58:31PM -0700, Andrew Morton wrote: > > Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > > On Mon, 25 Apr 2005, Alexander Nyberg wrote: > > > > > > > Not sure what you mean by "make kexec work nicer" but if it is because > > > > some devices don't work after a kexec I have some objections. > > > > > > That was indeed the reason, at least in my case. The newly-rebooted > > > kernel doesn't work too well when there are active devices, with no driver > > > loaded, doing DMA and issuing IRQs because they were never shut down. > > > > I have vague memories of this being discussed at some length last year. > > Nothing comprehensive came of it, except that perhaps the kdump code should > > spin with irqs off for a couple of seconds so the DMA and IRQs stop. > > > > (Ongoing DMA is not a problem actually, because the kdump kernel won't be > > using that memory anyway) > > Actually, some cpufreq drivers *should* do their speed transitions with > all PCI mastering disabled. The lack of any infrastructure to quiesce drivers > and prevent new DMA transactions from occuring whilst the transition occurs > means that currently.. we don't. So +1 for any driver model work that > may lead to something we can use here.
Well, you can do "half suspend to ram; change your frequency; half resume" today, and it should work, but I do not think you'll like the speed.
In a ideal world, calling device_suspend(PMSG_FREEZE) gets you exactly that, and we'll do our best to make it fast enough.
OTOH it *needs* to switch consoles to text one (because X may be running DMA, right?); I do not think you'll like that one. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
| |