Michael Buesch wrote:
Well, even _if_ mac_suspend takes a few milliseconds (which it does not), it would not trigger the watchdog. I measured the time it takes to execute the various works and based the badness selection on the results. If the 15 or 30 second work is really able to trigger a watchdog timeout, it's a _bug_ that needs to be fixed and not to be papered over. It won't trigger the watchdog, because it is running too long uninterruptible (it won't run 5sec...). If it triggers, it's triggered by something else (like the synchronize_net thingie in the past).
Even the synchronize_net problem wasn't taking 5 seconds to complete, it was messing up the transmit process.
I went back to check my logs again, and the actual error was "BCM43xx_IRQ_XMIT_ERROR", which is always preceded by a MAC suspend failed. These never happened all the time I was running with MAXIMUM_BADNESS of 0.
I think the _bug_ is letting the transmit process run while doing the periodic work, which is why I'm testing with the tx_disable before all periodic work. I'll let you know in 2 or 3 days if it fixes the problem. It takes that long to trigger.
Larry Larry - 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
