On Mon, Apr 25, 2005 at 02:58:31PM -0700, Andrew Morton wrote:
> Alan Stern <[EMAIL PROTECTED]> 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.
This is the main reason the longhaul cpufreq driver is currently busted.
That it ever worked at all is a miracle.
Dave
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
