A quick follow-up note: The stress line that was running during the crash mentioned was: "stress --cpu 8 --io 8 --vm 1 --vm-bytes 150M --hdd 2 --timeout 60". The "--hdd 2" option was a leftover that was not supposed to be there. So that may have created a chunk more disk work for the processor. Regardless, stress did not crash. Ping died with the EMAC error mentioned, but stress was still running fine when I stopped it.
It's been suggested that stress may be eating up too much memory and causing the EMAC driver to do this. That's a fair point, as these "WARNING: at drivers/net/ethernet/ti/davinci_emac.c:997 emac_rx_alloc" errors only appear to show up with stress running. I suspect that could be true, though no other drivers or other applications are throwing similar errors. When I've cranked stress too high memory wise in the past, I've seen it break out the oom-killer. That's what I would expect. Since I'm no longer seeing that, I suspect I'm playing within the bounds. Regardless, should a userspace app sucking up too much memory cause a driver to crash? I bring these questions here, as the crash's call stack shares so many similarities to the "SLAB crash" discussed "http://thread.gmane.org/gmane.linux.ports.arm.omap/78039/";, that I think they're related. At the very least, the EMAC to EMAC performance issues we have always seen are troubling. IMHO, clearly the EMAC driver is doing something a little questionable. Thoughts? Thanks again. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
