On Tue, 2006-06-27 at 10:16 -0500, John Haller wrote: > Brent Cook wrote: > > This patch disable interrupts on all ports during initialization. The > > current > > assumes that the firmware has already disabled all interrupts on all ports. > > We have encountered some boards that do not always disable interrupts (XES > > XPedite 6200 for instance) on a soft reset. This patch prevents a kernel > > panic if a packet is received before the DMA ring buffers are setup for a > > port on which interrupts are left enabled by the firmware. > You probably have bigger problems than the interrupt being left > enabled. If the interrupt is left enabled, the DMA engine > is probably left enabled, and if a packet happens > to come in before the driver can properly configure them, > some random part of memory will get overwritten. > The firmware needs to disable this device before transferring > control to the kernel, both the interrupts and the DMA, > there is no way to fix this in the kernel.
I agree that the patch isn't the best fix for this problem. Brent, for this particular case, I believe there's chip errata for the Discovery bridge preventing it from resetting itself when the board resets itself in non-monarch mode. That's why interrupts are left enabled. This issue should never crop up if the board is monarch on the PCI bus. So the proper workaround would be for our firmware to account for this case and disable interrupts, ethernet, etc. on a soft non-monarch reset. We could also do this in the boot wrapper code as a safety measure. Also, note that the firmware _will_ already explicitly disable ethernet before transferring control over to the OS _if_ you're booting over ethernet instead of flash. - Nate Case <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
