tis 2005-04-26 klockan 11:11 -0400 skrev Alan Stern: > On Mon, 25 Apr 2005, Andrew Morton wrote: > > > 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. > > Like Pavel said, this won't work. > > > (Ongoing DMA is not a problem actually, because the kdump kernel won't be > > using that memory anyway) > > For PCI devices at least, DMA _can_ be disabled in a uniform way as > devices are discovered. Some platforms might not want to do this for fear > it would kill the initial console display. > > IRQs _cannot_ be disabled in a uniform way. So they remain a problem. > > > For kdump we really don't want to be doing fancy driver shutdown inside a > > crashed kernel. It would be better to just jump to the new kernel and > > to reset the hardware from there. DMA doesn't matter, and maybe IRQs can > > be handled with a sustained local_irq_disable() (hard). > > But at some point you have to enable local IRQs, and then you're in > trouble if a device without a driver is generating requests. Unless the > new kernel can run with interrupts entirely disabled? Seems pretty > unlikely.
At least on x86 & x64 both i8259A and optional IOAPIC are initially fully masked until a driver decides to open up a line. If driver initialization fails then it should never open up the line on the interrupt controller. So this shouldn't be a problem with interrupts or am I missing something? Shared interrupt lines do present a problem however as someone else gets the chance to scream on an open line ultimately killing it, hmmm. > The real problem is that, in general, hardware _can't_ be reset properly > by a new kernel. There are things that can help, like the PCI USB quirks > code. That might be enough to handle the most pressing existing problems; > certainly it would avoid the USB issues we've seen. (But it needs to be > updated to avoid interfering with normal operations during > resume-from-disk.) ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
